Archive for December 24th, 2009

Developers often over-develop. A grand example for this are the various twitter widgets available presently for Android. They take a lot of space, and they show new tweets, plus they let you update your status. While this might sound to you like a good minimum functionality being offered, it’s in fact over the top.

Except the fact that they take lots of space on the desktop (usually 1/2 of the allowed desktop), showing new tweets by having to press the “next/previous” buttons to scroll in them, and then pressing two-three more clicks to update the status, it makes the whole thing *redundant*. It only takes a SINGLE click (via bookmark desktop link) to load the brand new (and very functional) mobile page of Twitter, which has full functionality, fits more posts per page, and it provides an input box right on the top of the page.

The HTC Hero widget is a bit better than the rest of the Android Twitter widgets since it allows for flicking through the tweets instead of previous/next buttons (they wrote their own code obviously, since Android doesn’t have flicking widget API support), but it still doesn’t offer @ mentions or DM info, it’s very slow to refresh for some reason after I request it to (it takes up to 1 minute here!), it doesn’t use the whole desktop full screen (so there’s lost real screen estate, limiting the amount of posts you can read on a single view), and besides, it’s only available on HTC Sense phones only.

To make the long story short, all these people who have developed these complicated and convoluted twitter (and facebook) widgets, are on the wrong usability-wise. I’m sure consumers THINK that this is the functionality they want on their desktop, but in reality, it makes their workflow more difficult than it has to be. Android allows to put bookmark links on the desktop, so all they have to do is add the link to the Twitter’s mobile page. This is a way-faster and more efficient workflow than using twitter via a widget!

Make no mistake, I do want a Twitter widget, but this has to act ONLY as a (1×1 icon sized) notification widget, not as a full-featured client. Sure, Android already has a drop-down notification system, but a widget is more visual, and requires fewer clicks/flicks to get to. Here’s a rough idea of what I’m envisioning:

I can pay $100 (via Paypal) to any Android developer who can implement this (which is of course a symbolic amount rather than covering the true cost). It shouldn’t be ultra-difficult to develop it, it’s definitely much simpler than the rest of the Twitter widgets out there. Here are some pointers of how I wish this to be implemented:

1. Make the widget vector-based (or whatever scalable format Android supports). Basically, design the background graphic, the font size, and the font-spacing in a way that scales well from a 2.8″ 320×240 screen to a 4″+ 1280×720 screen.

2. Clicking the widget loads a pre-selected third party client. The settings of the widget should be a separate app appearing in the main Applications list. The UI for the prefs should look like the main settings of Android (various options on a black background). A few other widget developers that I know have taken this approach too rather than loading the prefs from within the widget itself (especially since we’re dealing with a 1×1-sized widget).

4. When you click the widget to load the preferred client, the widget’s timeline/mentions/DMs go down to 0, and the refresh countdown clock restarts.

5. If there’s a Twitter API that tells you when was the last time Twitter was accessed with any client, take that into account when downloading & counting the widget’s new tweets.

6. The widget should be free to download via Market worldwide, and open source (same license as Android itself). The widget should not ask for more system permissions than it actually needs to operate. Host it at Google’s code depot, and make an effort to get it included by default on Android by following their code guidelines (it’s a long shot, but you never know).

7. Keep it lean. You don’t need to download the actual messages for example, only get the unread numbers. Test well for memory leaks, crashes, CPU/battery probs, or breakage with new Android/Twitter API versions. Be responsive to bug reports. No new functionality is needed, except maybe adding new twitter clients in the supported list. Only do that for major & popular apps, so the app might not need updating more than once or twice a year overall after it’s deemed “stable” — which is a pretty good deal maintenance-wise.

So, any takers? Please email me if you’re interested, before you start working on it.

Update: Android developer Stu King will start working on it Jan 1st. Thanks!