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.

A video of his entire presentation is unfortunately not available, but Josh Damon-Williams did manage to grab this clip.

After watching this clip it’s easy to understand why the audience became so excited about the possibilities of these tools. At the same time, I wondered what the chances were for something like fourbysix to be developed on a much larger scale. The fact is that we can drool over tools like this all we want, but unless a large group of designers starts supporting the work of people like Björn, we’re going to be stuck with the same tools we’ve been using for the past ten years for the foreseeable future. I wanted to know what it would take to make tools like this accessible to more designers.

When I met with Björn, he explained how he created the fourbysix table while at Microsoft. Not surprisingly, he used a lot of Microsoft technology including the Microsoft Surface SDK and proprietary source code only available within Microsoft’s walls. However, he also used a lot of non-proprietary technology, including tools that have been available since the late 90s. He also explained that, while he did use proprietary technology to build fourbysix, there are more open equivalents that could be used to build something very similar.

So with enough know-how, resources and materials, you could build something like the table in the clip above, but chances are that this is out of reach for most designers. So what’s the next option? According to Björn, the best chance for designers to make use of this technology is to collaborate with a research university on such a project. Fortunately, there may even be opportunities for this in the San Francisco area over the coming year.

If you’re interested in participating in something like this in the future, please get in touch with myself or Björn. In the meantime, I’ll definitely be following his work and helping out where I can.

Update (21/9/09)

Björn just let me know that videos are now available which feature the multitouch table he demonstrated at Interaction ‘09.

This is the fifth and final interview in the Design Inside Yahoo! series. I interviewed Greg Rosenberg, Principal Designer for Yahoo! Mail. I talked to Greg about where web email platforms are heading, the redesign of Yahoo! Mail’s and the recent addition of social features.

Joshua Kaufman: It’s been nearly three years since the launch of the redesigned Yahoo! Mail. How has the web-based email landscape changed in that time?

Greg Rosenberg: ‘04 to ‘06 was the big Web 2.0 Shuffle: “Hey, got AJAX?! FLASH?! Drag-n-Drop?!” That’s certainly leveled off, and rich web mailers are pretty much the norm now. Since then, I’ve seen two big things happen in the web-mail space. As industry leaders we all have this great technology in place in our products (Yahoo!, Google, et al.), but at the same time we continue to tweak our products to make sure they still address core needs, while we add new dynamic interactions and features. It’s a tough sweet spot to find: striking that balance between a cool, new feature and “why can’t I just check my mail?” This dilemma will always be there as long as we have expectations around what email is, and the massive population that’s grown up using it. We’ve continually tweaked the new Yahoo! Mail, and seen some the evolution of other e-mail services. Hey, even Gmail added a “Delete” button.

The second big thing is pretty obvious: the social media and social networking explosion. This has had a big impact on email as for some it has replaced traditional online communications (Email, IM), almost turning them into commodities. In social networking sites, once you and your friends join, you don’t need to remember an email address to contact someone: you only need to remember your username/password for that site. What constitutes “communication” has also evolved: a tweet, just updating your picture, posting a set of pictures, “liking” something, commenting on someone’s Facebook status, etc. In social networking, MySpace was the first to try and venture into e-mail (yes, there were predecessors, but not as mainstream and prevalent.) But, as we have seen, they suffer from a pretty big perception problem of only catering to tweens, a place for creepy stalkers, and bands trying to promote themselves. Facebook really deserves the credit for changing the social networking game here as they’ve zoomed past MySpace with finding a way to appeal to a wider demographic and have had explosive growth. However, an email address is still the starting point here, and hundreds of millions of people still heavily rely upon email. This is where I still think social networking sites still haven’t broken through a key barrier: the communications are so casual, the line between public/private so fine, that it’s not only a bit of an unorganized mess but there also seems to be a lack of etiquette in 1:1 private communications and incentive to engage in these types of communications. At Yahoo!, we recognize what’s happening in the industry and have been working hard to create a best-of-both worlds experience, reversing the flow and infusing social communications into an email environment. Not for the just for the hell of it, but to make email better and use connections (aka “friends”) and social features to power that. In your inbox, you can instantly weed out the noise to see messages from people most important to you. When you sign in, you’ll also see those messages highlighted with their pictures, along with updates about them (a news feed of sorts). The updates stream is not isolated to Yahoo!’s network, it aggregates Yahoo! and non-Yahoo! updates (Twitter, Yelp reviews/ratings, YouTube, etc.) all of which the user can control in their Yahoo! Profile page. We also have a whole new assortment of connection-related features in the pipeline. The core though, is still email, which draws more of a need to take real action, as opposed to social networking casual check-in behavior. This is where email is strong: you can still consume updates, traverse your network of connections, but the emphasis is on email functionality as the primary tool here. So, we retain the important and familiar user behaviors and give our users deeper confidence in knowing that the emails (and IMs) they send and receive are governed by the strongest and most robust security and privacy measures.

JK: After Google innovated with a conversation view, “archiving” and labels in Gmail, why did Yahoo! take a more traditional approach with folders and a standard column-sortable list of messages?

GR: Regarding Yahoo!’s approach, we have folders and not labels for a couple of reasons:. First, unlike Gmail which had no user base to migrate, we have millions of users worldwide of varying ages, experience levels, and usage behaviors, many of which using folders in the Classic version of Yahoo! Mail. Changing both the UI at a high-level and their method of organizing their messages at the same time would’ve been too much change at once. That’s the biggest reason we kept folders. Secondly, and equally important is that the concept of labeling can be confusing to some and thus has a bigger learning curve and ultimately doesn’t address what a lot of our users want to do: clean out their inbox. We know that users of folders use them to keep a tidy inbox, and like to file things away. It’s a natural behavior that’s been part of the digital world, based on the realities of the physical world. I’ve personally seen users in the lab, and during in-home research visits that end their daily mail experience with an empty inbox — as if an inbox that had any messages in it felt like a stack of late/unpaid bills. On the column sortable list: no need to reinvent the wheel here, this is just another example of something Yahoo! Mail users were already accustomed to using.

All that said, three years later, it doesn’t mean we’re not thinking about similar features :)

JK: What’s the story behind the general design approach, including the decision around using tabs?

GR: The early version of the new Yahoo! Mail (prior to the first beta phase) was actually very different from what you see today. The product more closely resembled its predecessor, Oddpost: it appeared as a traditional desktop application with “child” windows, primarily for composing and reading messages. It also launched into a chromeless browser window (that is, there was no toolbar) and hi-jacked the browser’s pull-down menu and shortcut key system. Essentially, it functioned identically to a desktop mail program, but ran inside a browser. For a variety of technical and usability reasons, we recognized that we had to change design direction.

Technical reasons:

• Proliferation of pop-up blockers (which became more extensive and built-in since Oddpost’s design framework was built) increased dramatically. Pushing past a blocked popup when launching the application, or composing a message, would be a difficult hurdle for the user to jump over.
• For security reasons, many browsers require a URL prefix to the title of any window that doesn’t contain an address bar. This means that as long as we opened all our windows into chromeless browser windows, the titlebar would have to be a random confusing mess of symbols, letters and numbers.
• The increase of tabbed browsers with enhanced control over clicked links would create unpredictable results when working within the application.

Usability Testing Feedback/User Perception reasons:

• There’s a growing user perception that a “window” and a “pop-up” are one and the same. If the user is using a web browser, and the page being viewed opens a new window (without the user specifically creating a new window), a significant percentage of the users will associate that window with an annoying ad.
• It felt heavy. We wanted to make the application light. As the earlier product mimicked a desktop application, it brought many of the expectations of such a product (required installation, full-OS specific shortcut keys, etc.)
• An inconsistent experience across all browsers and operating systems. The earlier version worked well on Windows (and Oddpost only worked on Windows), but we now had an odd experience for the Mac, which manages its menu system outside the browser’s application frame. On a Mac, the earlier version showed the Y! Mail native menu system and the browser’s menu system simultaneously - thus creating major confusion.

After the rough first set of usability tests, and peeling me off the observation room floor, our PM (Ethan Diamond) dropped me into a cave to come up with a new interaction model, and seven days later I crawled out with what you see today. We decided to have the product run in a Web-standard fashion: a single page in a chromed browser, without popping up windows for composing and reading. We also wanted to offer our own proprietary shortcut key system. How would we retain the same level of multi-tasking support that a windowed application affords the user, but do it in such a way that it’s dirt simple for the user? Out of the need to support this came the tabbed message system you see in the product today. In essence, native Yahoo! Mail tabs replace windows, but without all the mess of finding all the windows you have open. This is pain we’ve all felt with an OS, desktop program, and is worse with a stack of browser windows that can have confusing/unpredictable titles (that on Windows get grouped under one taskbar entity after a certain threshold has been reached). The tabs do a nice job of serving as an “index” of the user’s current open tasks: a message being written, an inbox to return to without losing the message being composed, to read the newest blurb in an IM tab with a friend, the social dashboard/updates tab, an application, etc.

JK: Calendar seems to be the only office app that hasn’t been fully integrated into Yahoo! Mail. Not to be rude, but what’s taken so long?

GR: Oh, I wish I had a good answer for this. While we have the calendar bar at the bottom of the Mail window supporting basic calendaring functionality available, we don’t have a Mail-integrated version of the rich calendar that’s currently in beta. Nothing new to report here.

JK: I noticed that RSS has been moved from Yahoo! Mail into My Yahoo!. The reasoning behind this is described in Yahoo! Mail help. I’m curious how much this decision was based on customer feedback. Do many people really want to read their RSS feeds from a start page?

GR: The decision wasn’t based on customer feedback. Most people don’t even know what feeds are, and an even smaller percentage know what RSS means. The RSS feature, inherited from Oddpost, was rarely used, took up valuable space in the folder list, and we just couldn’t give it more time & resources due to higher priorities. Given the small number of users of the feature, and that their feeds are mirrored in My Yahoo! (a more popular content consumption environment), it was a good move for us. As My Yahoo! is a popular starting page for many on the web, offers a robust built-in reader, and the content that appears on My Yahoo! is fairly similar, there are likely only a small number of users feeling much pain from this change.

JK: Meanwhile, on the way in are slew of social features based around connections. Is email the new newsfeed?

GR: It’s certainly moved more in this direction than it has in the past. You have to be careful though how far you take the news feed. The news feed is a strong way to passively consume what’s largely public content, see what friends are up to, casual commenting, etc. Blurring that too much with email is tricky business. Personal emails are private between the sender and the recipients, and there’s a different expectation put on the recipient of the message. For example, you’re more likely to hear “Why didn’t you reply to the email I sent to you four days ago?” as opposed to “Why didn’t you comment on my Facebook status from four days ago?”. So, baby steps. With the new social features we’re rolling out, we show updates from your connections, but above that in its own section are the email messages from your connections. In the context of Yahoo! Mail, emails are first and updates are second.

JK: What’s next for Yahoo! Mail?

GR: We’re gradually rolling out the social features and the open features (productivity apps integrated into the Mail environment). Outside of that, we’re always looking at every pixel, and every feature, always asking: does this make sense, does it belong, and does it make Yahoo! Mail better for our users?

Greg Rosenberg was Principal Designer on Yahoo! Mail for over four years and led the design of the new version. Currently, Greg is the Design Director for Community Products at Yahoo!, which includes Yahoo! Groups and Yahoo! Answers.

Readers may also be interested in my 2003 interview with Ethan Diamond, co-founder of Oddpost.

A follower of mine, @iamshimone replied that my tweet was ironic considering a recent article on modal dialogs that he read. I was definitely intrigued so I had a look.

In the article, Dmitry, the publisher of Web Designer Depot, recommended using “modal” windows in order to de-clutter and simplify your interfaces, comparing them to their alternative, popup windows.

So why would you use modal windows and how do they simplify your interface? Well, if you look at the alternative, their purpose becomes much clearer. The alternative to using something like a modal window is usually to load a new page.

I tried to clear up his inaccurate definition of “modal” in my first comment.

You’re using “modal” incorrectly. Modal means “prevent the user from doing anything until they interact with a dialog.” Modal dialogs are almost never necessary on the web, and encouraging them under the guise of simplicity is poor advice.

He appreciated my comment but questioned my reasoning, asking “Wouldn’t it make more sense to focus the user on the form they’ve just opened? I doubt they’ll want to continue working on the stuff below before at least closing the form, and the modal nature would prevent accidental clicks outside of it.”

His intention to focus the user was good, but one shouldn’t assume that people don’t want to click outside dialogs - or more importantly that popup dialogs are one of the best solutions.

It definitely makes sense to focus the user on the task they’re doing, but that doesn’t mean you should restrict them from interacting with things outside of their task - unless those things are destructive to the current task at hand. Notice that I didn’t say “dialog” in that sentence.

Instead of thinking in terms of a dialog, think about ways that you can maintain forward momentum in the application - while still keeping the focus of the user - without any sort of dialog, popup or prompt.

Taking your Action Method example again, consider the “+ Add New” button. When you click it, it show [sic] you a modeless dialog. (At least it’s not modal.) I would personally avoid a dialog completely. Instead, I would probably create a new action step at the top of the list with empty fields that the user can complete. Now this won’t accomplish exactly the same thing as a dialog. What if the user decides they don’t want to create a new action step? Instead of canceling a dialog, they would be deleting a blank action step. But given how rare this would be compared to how common creating a new action step would be, I believe it makes a lot of sense.

I’m not saying that doing it this way is easy or always possible. It requires a considerably more thoughtful interface. But it can be done, and when it creates a better experience for the user, it’s worth it.

There are a lot of web design blogs out there, and many of them explain interaction design principles incorrectly and make broad assumptions about why they should be applied. Designers who know better shouldn’t let this happen, and should at least attempt to enlighten the audience.

So must all modal dialogs on the web die? Probably not. As a fellow designer Dani Malik reminded me after I posted that tweet, “All blanket statements must die.” Nothing like a shot of your own medicine to set you straight.

Radar is currently available for Java, Windows Mobile, Sidekick, and Blackberry, and the Radar mobile site works on any web-enabled phone on any network in the world. And now, Radar is available for the iPhone and iPod Touch.

With the introduction of Radar for iPhone, I believe we’ve created the finest mobile photo sharing app available on any mobile platform. Why “mobile photo sharing” and not just “photo sharing”? Well, Radar isn’t Flickr (it doesn’t try to be either), and once you start using Radar you quickly learn it’s as much about shared experiences and conversation as it is about photo sharing. Curious? Download Radar on the App Store today.

After you’ve played around with the app, be sure to let us know what you think. We’re always looking for ways to improve the experience.

Press Coverage: Mashable, VentureBeat, MacNN, ReadWriteWeb