A friend of mine recently commented that native Twitter applications are the new flashlights. It’s true, but it shouldn’t come as a surprise: consider the number of web apps that proliferated before the advent of the native SDK.
Personally, I welcome this competition. Seeing the work of other developers whose work I respect and admire acts as an inspiration. Looking at how other developers tackle a problem domain often adds insight into solving similar issues with my own code. In other cases, it shows me how I don’t want to implement a feature (without the need to prototype.) In short, competition will make Twitterrific better.
(I’m particularly disappointed that Ed Voas has decided to go back to work at Apple. I’ve been an admirer of his work since the days of Aaron and the Appearance Manager. From what I’ve seen with Tweetsville and his blog entries about its development, it’s clear that his decision is a loss for everyone working on the iPhone platform.)
Of course, this competition is also good for users. The most obvious benefit is that applications will evolve and improve more quickly as developers learn from each other and try to outdo the other guy.
But there is a more subtle benefit. There will always be more than one way to solve a problem: a developer’s personal preferences will inevitably seep into the implementation. Having many choices for a Twitter client means that developers don’t need to create a “one size fits all” solution. In essence, users get to choose a developer whose preferences match their own.
(And please do all developers a favor: tweets like “twitterific sux, twhatever rocks” do absolutely nothing besides make our skin even thicker than it already is.)
Making Choices
One of the most fascinating things about these native Twitter applications is the variety of user interfaces. In spite of all these apps using exactly the same API at Twitter, there are many different user experiences. It’s all about developers making choices.
I’ve wanted to write about what led to the user experience in Twitterrific for quite awhile. It’s been only recently that where we’ve been and where we’re going have gelled to a point where I can express these thoughts in an essay. So while tryptophan was coursing through my veins, I started to look back on our past choices and think about where I see things going in the future.
John Gruber’s recent essay on iPhone-Likeness is a definitive manifesto for iPhone development. If you haven’t read it, go do it now. If you have read it, go read it again. And again: you can’t call yourself an iPhone developer until you’re read that fireball at least three times.
If you’re still to fricken’ lazy to read that link, here’s what I like to call Gruber’s First Law of iPhone Development:
Figure out the absolute least you need to do to implement the idea, do just that, and then polish the hell out of the experience.
In a word, strive for one thing in your iPhone application: simplicity. Both in terms of functionality and beauty.
From the very first day, we tried to do this. And it turns out that “doing as little as possible” was one of our greatest challenges. (I’m using the plural pronoun here because the interface design was a team effort.)
To achieve this goal, you have to find the “nut” of your application. The thing that defines what you’re working on. Even more targeted than John Geleynse’s “application definition statement.” Something that you think of each time you start up Xcode, or every time you answer a customer email, or when you’re planning features for a new release.
(As an aside, if you haven’t seen John’s talk at WWDC 2008 yet, do yourself a favor and download “Session 351 – iPhone Application User Interface Design.” I guarantee you’ll get something out of it, even if you’re an experienced iPhone developer.)
For Twitterrific, our core function is reading.
The core function is not managing your Twitter account. Nor is it being a general purpose tool to exercise every nook and cranny of the API. It’s primary function is not to acting as a surrogate for SMS messaging.
Twitterrific is all about reading what other people are doing, thinking, or experiencing. Even its secondary function, posting tweets, is related to reading. The posting interface functions as a way for you to give your followers something interesting to read.
Good Choices
Reading as a core function manifests itself in several aspects of the application:
- The list of tweets is designed to be as compact as possilble. The stream of information is much easier to read when there is more of it visible. This meant keeping navigational elements to a minimum.
- The detailed view, with larger text and less surrounding information, was designed to be read while in motion. Small fonts and compact presentation is problematic when your trying to read on a train or other moving vehicle. Navigational elements in this context are also larger and therefore easier to hit.
- Simple navigation: it’s very easy for these elements to get in the way of reading. From the beginning, Twitterrific was designed to work with one hand using the thumb as the primary input. Pulling the device out of your pocket and checking your tweets should be quick and not require two hands.
- Tweets often contain links to other items you want to read. The mini-browser allows these links to be opened and read as quickly as possible.
- Making it easy to read things later. Links in tweets sometimes point to things that you’ll want to read or watch outside of the confines of a mobile device. To this end, we used Favorites as a way to pass information between the mobile and desktop platforms.
- The main problem we found with pure web interfaces to Twitter was the inability to persist data. The cellular data network isn’t always available and reading tweets should not be impacted by network outages.
- We go to great lengths to maintain a reading position between launches of the application. Since we’ve found that reading Twitter on a mobile device is done in “fits and starts”, keeping the reader’s location in a consistent state is very important. It’s not an easy feature to get right which could explain why Twitterrific is currently the only app that tries to do this (and our own implementation could even use improvement.)
Imperfect Choices
Of course, we didn’t get everything right. At one point, my partner Talos Tsui suggested that we add the ability to follow and unfollow users from the iPhone UI. I argued that this felt too much like “account management” so we decided to not implement the feature. In retrospect, Talos was right: following is how you control what you read and needs to be a part of the application. We’re going to fix this in an upcoming release.
Other design choices were based on the current state of Twitter. At the time Twitterrific was being developed, Twitter was having some major scaling issues. Availability was sporadic and users were only allowed to access the Twitter API a total of 30 times per hour (regardless of which application they were using.)
This limitation played a factor in many of our design choices. Our concern was that users on the desktop would consume all the available API calls and then not be able to view tweets on their iPhone. We could have implemented a more readable view of the user’s archive (after you click on the @screen_name.) Instead, we display a web page—and don’t use any API requests. The latest round of native applications benefit from Twitter’s success in dealing with load. They don’t have to be so stingy with the API and they’re better off for it.
One of the best features of Tweetie is the ability to follow “in reply to” links. At the time we were developing our client, these links were notoriously inaccurate. I had made a suggestion to the Twitter developers on how to improve this, but it hadn’t been implemented yet so we decided to defer the feature. Now that the API supports setting reply IDs, Twitterrific (both iPhone and desktop) and other clients are making the links more reliable and threading features are much more attractive.
Future Choices
And that leads into what I see happening in future versions of Twitterrific for the iPhone. If you’ve been paying attention to this essay, you won’t be surprised to learn that these features will benefit the reader.
As I just mentioned, threading features that allow a reader to catch up on conversations are now possible. Tweetie has the right idea here, but we think the user interaction model is wrong. I’m all for competition, but I’m not going to tell how we plan to make it better. Loren Brichter and others will have to wait :-)
Search and trends are also recent additions to the Twitter API that weren’t available at the time we did our initial development. (Summize was available as a third-party API, but hadn’t been purchased by Twitter yet.) We often use these features to see what people are saying about our products: Frenzic, xScope, IconBuilder, Twitterrific. It makes sense to use search as another way to provide entertaining and informative content for us to read.
Another area where we see room for improvement is filtering tweets. There is literally a flood of information coming from the people we follow, so making it easy to extract things like replies, direct messages and favorites from the main timeline will be helpful for the reader.
Finally, we see a need to keep the “reading point” synchronized between the desktop and the mobile device. We currently find it cumbersome to switch between clients because they have no way to let each other know where the reader is in the timeline. We’ve requested that the developers at Twitter provide a way to exchange metadata between clients. iPhone applications usually work best when they are an adjunct to the desktop application. Treating the device as a satellite and providing it with metadata will improve the user experience for all Twitter clients.
Finally, I’d like to point out some things that we don’t plan on implementing.
I’ve been very impressed with Tweetsville’s implementation for direct messages. It’s a very creative solution to the problem, but I think it falls outside our core functionality: it turns Twitter into a conversation, not reading.
It could be argued that conversations are a type of reading. Unfortunately both users must follow each other for the exchange to be meaningful. And mobile use of Twitter tends to be asynchronous (unlike the desktop, it’s not “always on”.) These things, combined with the limitations of text entry on the iPhone, indicate that other media are better suited for two people having a chat.
Another thing we’re consciously avoiding: adding features just because “the other guy is doing it.” We think long and hard before adding anything to Twitterrific. Then we prototype a user interface and adjust it accordingly. Then we make the feature the best it can be.
And if you wonder why we go to all this trouble, just remember Gruber’s First Law of iPhone Development. It takes more time, but we’re in this for the long haul. There will certainly be a period of attrition for Twitter applications, much like there was for the web applications, and having the best user experience is the only way we’ll thrive.
Addendum December 4th, 2008
Fraser Speirs has some very interesting thoughts on contexts for mobile computing.
Our application clearly falls into the “Type 1” and “Type 2” categories: and that’s a conscious choice we’ve made. You should make the same choice. It’s OK to go for a different context than we did, remember what I said earlier about applications taking on the personality of their developer?
Fraser also wonders why there aren’t a lot of “Type 3” applications in the store right now. I think there are a couple of reasons for this:
- Everyone is still working on their first version. Catering to power users who need more extensive capabilities comes as applications mature. iPhone applications haven’t had enough time to evolve.
- The rush to a $0.99 price point doesn’t provide enough of a budget to fund additional feature development. Without a healthy revenue flow to pay back costs that have been incurred, it’s hard to justify new features (and additional costs.)
In my opinion, both of these reasons will dissolve over time. In the meantime, consider if/how your application fits into “Type 3”. Plan ahead.
