“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It's not about money. It's about the people you have, how you're led, and how much you get it.” - Steve Jobs

Thin App pet peeve: Passing the buck

Through AIR, standard web and WebKit there has been a proliferation of applications whose data almost completely resides on the network and is accessed through a series of APIs. In many cases the elements that make up the GUI itself are also distributed over the network making them even thinner as is the case with Web-based applications.

The reason these application environments exist is to aggregate and add a touch of special sauce to the data that they get from their own as well as from 3rd Party sources. They wrap up the data in usually a much better bow (if they are to be used at all) than before they existed.

I have been paying special attention to a class of thin applications that have been growing ever mightily over the last 2 years–Twitter clients. There are 3 standard varieties of twitter clients that I’m considering here: Adobe AIR, Web-based or WebKit (for iPhone & other mobiles), and platform native clients (iPhone apps, Blackberry apps, Mac, Lin, or Win native).

Regardless of platform or mode of development and distribution most of these applications try to achieve almost the same exact functionality. Here is a list of common functionality:

  • Read your home feed
  • Read your mentions (@you)
  • Read DMs you sent
  • Read DMs you received
  • Read your personal feed
  • Post an update
  • Post a reply
  • Post a DM

Other features that are prevelent but not in all clients:

  • ability to retweet
  • view reply threads
  • Add to favorites
  • see your favorites
  • See user profiles
    • recent posts
    • favorites
    • #’s of followers/following
    • List of followers/following
    • Ability to block
    • report spam
    • mentions of that ID
    • (links to other info like location & links in description tend to go to browser as it is uncontrolled data and not controlled by the API, though I could see location being more controlled, as some apps have done, now that I think about it.)
  • do searches
  • save those searches
  • create user lists/groups
  • Open links from tweets into embedded browser
  • Ability to email links
  • Copy links
  • retweet links (alone)
  • From embed browser save to instapaper or similar service
  • run multiple accounts (or toggle between multiple accounts)
  • Notifications (home, mentions and DMs)
  • Ability to shorten URLs (pick URL shortener)
  • Ability to add a photo (choose twitter photo site)
  • Ability to update your location on your profile
    • include update in a tweet
  • Then there are the host of options for all this stuff as well.
  • Facebook support.
  • display images
  • call out link titles

We have to be realistic. There are many different types of users of Twitter. So it is great that there are so many different clients to choose from. Ya know, we all can’t drive SUVs or MiniVans, right?

But regardless of the collection of features or more importantly how they are arranged, is how they are made available to the user. One of the great things about the Twitter eco-system is that most of what needs to be delivered to an end-user even if not directly part of the Twitter offering can be obtained through the 3rd party’s APIs or otherwise crunched out from structured HTML.

What does this mean? This means that there is almost no reason for a Twitter client to throw you out of their environment for almost any bit of Twitter and other related info. And this is especially egregious when the application you are working in, is not in a web browser itself. But web apps regardless of type are not out of the clear. With use of Prism in most netbook refreshes and Fluid on Mac and maxed out windows in mobile web browsers (w/o easy tabbing) opening links outside the initial primary environment is annoying at best and just a real hardship on the user interaction load, which is completely and utterly unnecessary.

I know that almost all of these apps are sold on the cheap at best or free, but for the ones that use ad support or are charging anything at all, you have to be doing better.

What really kills me is when a company like IconFactory do some amazing work in iPhone in this specific regard, but don’t have the same level of detail or support in their desktop application. Makes me cringe.

But this isn’t about iPhone applications. It is about any thin client. Why leave the primary environment of your application for any of the following:

  • open a map
  • open a calendar
  • view an image or video
  • open an article w/ an RSS feed/address reference
  • etc.

So before you think you can short-cut your app dev time by saying, “but we can just open a browser window and get to the same info that way, ” realize what you are doing to your end users. You are basically telling them, that your services are incomplete.

The equivalent happens when your DSL provider tells you to call your telco. You feel let down and out of control. Imagine what happens when you have consistent and controlled service from the same entity. You feel like a human and not a hot potato.

All of this is further inspiration as I continue working on my Tweet101 project (http://tweet101.pbworks.com) where I’m trying to marry a complete software design course with an open education project with an open source design project. If you are THIS interested in twitter clients, software design, &/or education then feel free to join the project.

Ping me at @daveixd or @tweet101_org if you have any questions or comments (or leave a comment here, or join Tweet101)

Be Sociable, Share!
  • JS

    interesting stuff. i don’t think the ‘your dsl provider tells you to call your telco’ analogy is right, though. i think a better analogy is ‘you visit a primary care physician and complain about a pain in your chest; she refers you to a cardiologist.’ i think shelling out to a browser is (often) an act of delegating a task to the best-suited tool and not a dev time-saver. if your primary concern is keeping a user within a single app, that’s perhaps a little different…more ‘you visit a primary care physician and complain about a pain in your chest; she refers you to a cardiologist that shares office space with her,’ or ‘your primary care physician is also a cardiologist…and a surgeon and a podiatrist and a…’ it’s probably more practical to share space in a thin app than creating a one-stop doctors’ office or being a doctor of everything, but there are still limits. what’s the right number of features to include in a thin app? when does my app become a cluttered mess (and not so thin)?

  • http://davemalouf.com/ Dave Malouf

    Actually, I’m going to stick w/ my way of thinking about it and let me explain.

    yes, *HTML* (& all that goes w/ it) can sometimes be a better technology to use for a given part of the puzzle, but using HTML does NOT! require that you open up a whole new application.

    applications like MS Money & Quicken have done this for years where they use rendering engines inside their own applications. From the end-user’s perspective they don’t even know it is happening.

    Twitteriffic on the iPhone and a few others, do the exact same thing when you open up a URL (something you think you should do straight up in safari), but by NOT passing the buck, they are able to offer more features like add to instapaper, or just maintain the experience for the end user.

    What’s worse are apps that send you back to a generic twitter screen for info that is embedded in the API like viewing a specific tweet, viewing a profile and doing a block or reporting spam.

    Twitter is a horrible interface and so there is no specialization here at all.

    Again, PET PEEVE!

    I would dare anyone to show me an example where moving to a completely different application framework is necessary or better technologically or from a user experience.

    — dave


The archives run deep. Feel free to search older content using topic keywords.