theme selector

light blue screenshot grey screenshot navy screenshot dark green screenshot red and black screenshot
 

by Tony Chang
tony@ponderer.org

All opinions on this site are my own and do not represent those of my employer.

Creative Commons Attribution License

innovative interfaces

Sep 30, 2005, 02:29am EDT

 

 

pie menu One of the main points in User Interface Design For Programmers or any other book on user interface design is that you should design interfaces based on user expectations. I agree with this for the most part, but it makes me sad. It makes me sad because it means that innovative interfaces are likely to fail even though they’re “better.” For example, there are plenty of studies that show that pie menus are superior to traditional linear menus, but they’ll never take the place of context menus. Why not? Because they’re too different from what people have come to expect when they right click.

So to make the most immediately usable product, all you can do is make incremental improvements. But to make a really innovative interface, we need to stop listening (literally) to users. We need to look past what the user says she or he wants and look to what goal the user is trying to actually accomplish. There is always a lot of risk in doing this because lots of people simply won’t get it. They won’t want to take the time to learn a new interface even if it will save more time in the long run and they’ll return to an interface that is familiar.

I see this happen a lot with Gmail. Walt Mossberg recently had an article in the Wall Street Journal comparing Yahoo mail (beta) to Gmail. He concluded that Yahoo mail was better because it more closely replicated the desktop experience (i.e., Outlook). He complains that Gmail doesn’t provide folders, which he has come to expect. It doesn’t matter that most people only have one level of folders [1] making them identical to labels. It breaks his expectations of how to organize email.

So when people say they want folders, what do they really want? In most cases, the goal is actually to find messages quickly; folders are used to aid in the search process. So when users say they want folders, what they really want is a fast way to find email. When I’m trying to find a message, I don’t really care how my email is organized, so long as I understand the structure and can quickly find my email. But labels (and search) provide this functionality, so why do users still complain about the lack of folders?

The other reason people want folders, is because they like to be in control. People understand folders and thus using folders provides control. Labels feel slippery to new users (there’s no structure! there’s no hierarchy! oh no!). It’s not that folders are better, it just makes some (anal retentive) people feel better.

So what does that mean? It means that some people will love the new Yahoo mail and hate Gmail. But that’s ok, that’s just the physics of passion.

[1] In the current Yahoo mail, you can’t nest folders anyway making them identical to labels. Is this the case in Yahoo mail beta?

Pat Bergschneider at Oct 02, 2005, 12:06pm EDT

Some of my friends have made interesting comments after I’ve invited them into Gmail… “you can’t put anything in folders” and the like. It seems to me that people are just really lazy and need things explained to them. After a few minutes of chatting they see the benefits of keeping a single copy of an item (email) and using labels to organize. Do we need a gmail handholding introduction page? I mean there is this: http://mail.google.com/mail/help/why_gmail.html , but it doesn’t really explain why labels make so much sense.

Anyhow, on the pie-menu related field… after using Maya for a few years, I really can’t see why people aren’t moving toward the pie menu. A few weeks of using it and I became much quicker and I could actually create what I wanted to create rather than fighting a 10/20/30?-year-old menu structure. How old is File-Edit-Etc anyway?

allowed HTML: a, blockquote, ul, ol, li, dl, dt, dd, b, i, strong, em, code, abbr, acronym, sub, sup, span, pre

allowed HTML: a, blockquote, ul, ol, li, dl, dt, dd, b, i, strong, em, code, abbr, acronym, sub, sup, span, pre