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
- #’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
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)