Thursday, March 31st, 2011
The QuickBar is dead. Doug Bowman, writing on the official Twitter blog, had this to say:
The QuickBar was originally conceived to help users discover what’s happening in the broader world beyond people they already follow. The bar was also seen as a potential means of in-app notifications for new @mentions, DMs, and other important activity.
Why didn’t it do this right away? Those sound like useful things that are actual, real problems for real users. Implemented that way, the QuickBar would probably have been lauded as an example of excellent problem solving and user-centered design.
Instead, the first iteration the QuickBar seemed to not be a user focused feature in the slightest. The problem that it solved, not being able to see trending topics in the home timeline, was only a problem for advertisers, not users.
We will frequently experiment by trying new things, adding new features, and being bold in the product decisions we make. After testing a feature and evaluating its merits, if we learn it doesn’t improve the user experience or serve our mission, we’ll remove that feature.
Laudable, but ultimately misguided.
To me, the above smacks of a web-centric design process that disregards the realities of mobile application deployment and development.
With a web application, deployment is entirely within your domain. Trying new things and iterating quickly are easy to do and processes like partial roll outs, A/B testing, and continuous deployment are well documented and battle tested. Users are not shocked if some part of a web application morphs subtly from time to time. For example, I’m willing to bet most people have been in Google Search experimental group at least once.1
Contrast this to mobile application development. Application updates are explicit and user initiated. Review times are long. Partial roll outs, A/B testing, and continuous deployment are impossible or difficult (especially on iOS). Users do not have experience with half baked features popping up and being suddenly removed — they see the application as lacking polish and react negatively.
There is simply no room for half baked features in mobile application development. You need to think carefully about what segments of the feature are released in what order, and you must make sure what you do release is fully baked.
However, iterating and getting feedback from users is still sound in principle — in fact I’m convinced that user testing, in some form, is critical to releasing an excellent product. Most native application developers — both mobile and desktop — have extensive private beta testing programs. It’s my understanding that Twitter ended Tweetie’s private beta program when atebits was acquired. Ludicrous!
We believe there are still significant benefits to increasing awareness of what’s happening outside the home timeline. Evidence of the incredibly high usage metrics for the QuickBar support this.
What about Twitter for iPhone’s existing mechanisms for notifying users about things happening outside the home timeline? Anyone who uses Twitter for iPhone has seen the blue dots underneath the tabs in the tab bar. And they will also be able to tell you Twitter for iPhone can’t keep track of which direct messages you’ve read to save its life — even ones you read in Twitter for iPhone.
Twitter should concentrate on fixing its existing notification mechanisms before adding new ones.
In short, Bowman’s post gives me little confidence that Twitter has learned anything from this entire debacle.
I’d love to see real statistics on that. ↩