Back in 2006 while on a trip to HQ, I sat in a meeting with some folks from the User Experience (UX) team. I don’t remember exactly what the purpose of the meeting was, but we wandered off topic and were just bouncing ideas off each other.
I threw out the idea of a zero interface, erm very little interface (VLI), which understandably did not go over well. Not the best audience in hindsight. Looking at Twitter’s astounding growth, I wonder how much can be attributed to their laissez faire attitude and very functional API, which has created an ecosystem of apps around them.
Granted, Twitter has a pretty limited feature set, which makes it much easier for them to implement a VLI, but that combined with their openness has bread success. This is a repeatable formula.
I’m a big believer in simplicity in UI, frequently preferring a command line interface (CLI) to a UI. Obviously, zero interface is an impossibility, which is why I’m using the term VLI. Using Twitter as an analog again, Twitter.com is very simplistic. In fact, they haven’t integrated twitter.search.com (formerly Summize), nor do they track all @ replies.
However, their API is very functional, allowing client apps like TweetDeck to replace (and augment) the twitter.com feature set. The only piece they’ve kept closed is account creation and management, and now that OAuth integration is in public beta, who knows if they’ll open pieces of profile management as well.
Twitter.com remains the most popular way to tweet, although its share has fallen from 55% in April 2008 to 32% in February 2009. Granted, it’s difficult to track traffic accurately, so this is an unscientific measure. As an aside, I wonder which client benefited the most from the loss of IM as a client?
And all bets are off, if Twitter decides to monetize the pageviews. That would be interesting.
So, what have we learned? VLI isn’t about interface at all. It’s about data.
Data make your app valuable. Interface is a byproduct of data.
If you’ve ever built UI, you know how tough it is to balance usability with functionality. Throw users into the mix, and you have a whole lot of must-have requirements that don’t play nicely with each other.
Enter the second tenant of VLI, open APIs.
You must give your users (specifically, their developers) that ability to remix the data.
This has been our goal for Connect. We haven’t been able to keep the UI as simple as Twitter’s because as a new app, we needed a more functional UI so our new users could get what Connect was.
However, as our user base has grown, we’ve added REST APIs for the user data, which has spawned integrations with a few other apps, e.g. OraTweet. Noel has followed the same principles too, producing APIs for OraTweet that we consume.
As Connect’s user base grows, more people have asked about using the APIs we produce because they have specific uses and don’t expect (or want) us to extend Connect to support them.
We do benefit from the security blanket of being behind the firewall, and if Twitter’s growth is an indication, I expect to see lots more demand for Connect data in the next year-ish.
So, what do you about VLI? Are you a more traditional UI person? If so, call me out in comments.
Update: As Andy C points out in comments, Twitter isn’t as open when compared to open source projects like Laconica, although that’s not really the point of the post. My goal is to examine a for-profit (an assumption in Twitter’s case) service and its approach to APIs and interface. The model is interesting to me, similar to one that I’ve proposed in the past and one we’ve tried to model with our work on Connect.