Tweetie reloaded: an interview with Loren Brichter
Tweetie 1 for iPhone set the standard for a simple yet powerful Twitter client, garnering the attention of both A-list tweeters and Apple, winning an Apple Design Award at the Worldwide Developers Conference. Tweetie 2 raised the bar once again, providing a slew of new features wrapped inside an elegant interface.
One feature common to all Twitter clients is “reload,” allowing users to load the latest tweets. Tweetie handled this particular feature differently from the beginning. I talked to Tweetie’s creator, Loren Brichter, about how this feature evolved and his perspectives on designing gestural interfaces.
Joshua Kaufman: Tapping a button to reload was generally accepted as a standard within the iPhone interface. What made you explore the refresh interaction in Tweetie 1?
Loren Brichter: Necessity is the mother of all invention. Looking back to Tweetie 1, I was in this position where my navigation bar was already filled up. On the left side was the “Accounts” back button which would take you back to the accounts list (Tweetie 1 was the first app with a sensible multiple accounts implementation). On the right side was the compose button.
So where did the reload button go? Other apps of the day simply put the reload button in the upper right corner. This was acceptable for single-account apps, but for apps that handled multiple accounts, those apps had to go through some nasty contortions and shove the account switcher UI into some other non-optimal place. So I thought about it, and asked: what was “reload”… really? In the context of Twitter, it really meant “load newer”. And when you loaded newer tweets in your tweet stream, where did they go? At the top of your list.
So I put the reload button at the top of the list. As you scrolled up, reading newer tweets, eventually you’d get to the top of the list and bam… there’s a reload button, it just slid into view exactly when you needed it. You tap it and it’s replaced by the newer tweets. It’s intuitive and doesn’t waste prime screen real estate (corners of the screen) until you actually need it.
JK: How did you arrive at the pull down and release to refresh interaction in Tweetie 2?
LB: Tweetie 2 simply took this idea from Tweetie 1, that reloading was simply “loading newer”, and “loading newer” put new messages at the top of the list… and activated the action based on a finger motion that you were already doing. Why make the user stop scrolling, lift their finger, then tap a button? Why not have them continue the gesture that they are already in the process of making? When I want to see newer stuff, I scroll up. So I made scrolling itself the gesture.
The gesture is only half the battle though, you need appropriate feedback. Once the reload is activated, the scrollable area of the list actually changes to leave the feedback UI in-place (rather than bouncing offscreen). Without this part, the UI is unintuitive. And once the loading is complete, the UI makes itself disappear.
JK: Using this interaction in Tweetie 2 reminded me that gestural UI is still young and full of possibilities. Are there other common interactions that you see being improved by new gestures?
LB: Of course. But you need to be careful. The reason that I think the pull-down-to-refresh works so well in Tweetie 2 is because it’s discoverable and explanatory. It’s discoverable because you already know how to scroll a list, and as you scroll up, when you get to the top — bam — the UI reveals itself and you go “whoa, what’s that?”. It explanatory because once you start tugging down there is some great UI feedback, actual text that provides instructions as you interact. It’s not like it pops up some modal dialog with instructions on how to use it, the UI itself is the instruction. Once you learn it you simply ignore the text and can look at the graphical arrow which gives appropriate feedback on what you need to do.
Now, I think you can split gestures into two categories. One is of the pull-down-to-refresh kind. These are gestures that are discoverable and explanatory. The other kind of gestures are like tapping-the-status-bar-to-scroll-to-the-top, or swipe-to-delete (or swipe-to-reply in Tweetie). These gestures you won’t discover on your own except by accident. These are not discoverable, and they are not explanatory.
This second class of gestures can exist (in my opinion) because they are not the only way to accomplish a goal. In the case of tapping the status bar, users already know how to scroll to the top manually. It’s slower, but it’s possible. In the case of swipe to delete, users already know they can tap on a message and then tap the trash button. So knowing the gesture isn’t necessary.
So when you’re inventing new gestures, it’s important to think about whether the gesture is required to use the app. If it’s the only way to accomplish a goal, you better be sure it’s discoverable and explanatory without needing to read a manual. If it’s the other kind of gesture, go nuts!
Loren Brichter runs atebits — a devious scheme designed to take your money $2.99 at a time. Previously he worked for Apple on the original iPhone. Now he mostly answers email, and occasionally finds time to actually program.