 | Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
12 Jun 2007 Consumer devices like the Nintendo Wii and the Apple
iPod have shown that the simplest interfaces can win over users in record
numbers. This month the cranky user looks at why simplification works and how the drive for innovation ties in with the Principle of least
astonishment.
If you had tried to convince people six or seven years ago that the most
successful MP3 player today would have fewer buttons and less functionality,
not more, you would have been dismissed as a fool. If you had said even a
year ago that the fastest-selling video game console would have a controller
with only a few buttons (but make up for it with motion sensing), few would
have credited your theory.
But the iPod and the Wii would have proved the masses, not you, wrong. Both
devices are runaway successes, largely due to strikingly simple interfaces
that violate the accepted wisdom of product design in their markets. The
Wii remote is not an incremental improvement of the basic handheld
controllers that every game console has used since the first Nintendo
Entertainment System; it's a completely different approach to console design.
Similarly, the click wheel came as a complete surprise to MP3 enthusiasts,
and its simple perfection quickly established the iPod as the top player in
the market.
The best can be the enemy of the good in engineering. Trying to do
something perfectly often leads to doing it badly or not at all. On the
other hand, the conventional wisdom of how-it's-done is sometimes just plain
wrong. In this month's column I'll offer tips for making your applications more
competitive by re-thinking and de-cluttering them. In many cases, the key is to do less, but do it better.
The winding path to wisdom
The big downside of an unfamiliar interface is the learning curve.
Learning to use a new application can be nearly effortless if the interface
is familiar, and conventional wisdom says effortless is good. It takes time
to master new ways of doing things, and not every user will make the
effort. Therefore, a new product or interface must be either easy to pick up
or very rewarding.
No one ever claimed that the early Napster releases were easy to use, but
millions of users decided the reward was worth the effort. One of the
first things you need to decide when considering a design innovation is
payoff. Your innovation should be a reward in itself, like the iPod's
click wheel, or worth the effort, like Napster.
That said, a completely revolutionary interface can be easier to
learn than one that looks familiar but fiddles with the details. If an
interface looks familiar but doesn't act like it is expected to, users
might simply dismiss it as broken. For example, one of the killers of
dynamic Web pages is that they break the back button, which is
surprisingly more significant to users than just about any other aspect of
an interface. Dynamic Web pages are slick and developers love them,
but for most users the broken back button is a sticking point. Even if your site
is doing exactly what you designed it to do, it will look badly made without this essential feature.
|
All roads lead backward
Why is the back button so important to users? From frames to Ajax,
developers keep inventing new ways to break them and users keep resenting
(and resisting) the effort. The browser's back button serves a need similar to the undo
feature in desktop applications: It's a safety net. If you want users to take the time to
learn to use your product or Web site, you have to make it easy to explore safely. Whether you're writing a spreadsheet program or a shopping
cart, consider the user's need for protection. Users shouldn't have to fear
random data loss as a result of hitting the wrong button; so let them
undo, let them go back to the previous page when they need to. |
|
Can I get that in writing?
The thing about software systems is that they tend to gradually become more
complex. Existing features aren't removed, new ones are added, and the
result, over time, is clutter. Once you reach a certain clutter threshold,
it becomes hard to explain what's going on. Software companies used to make
this sort of clutter more palatable by producing detailed, comprehensive
documentation for their products. Early software systems, such as MS-DOS,
came with thick manuals that explained their functionality in detail.
Even the "easiest" computer ever, the early Macintosh, came with a huge
and comprehensive manual. Although the Mac had one mouse button and the
whole system fit on a floppy, its original manual was over a hundred pages.
Nowadays, a several-gigabyte installation comes with a 16-page manual. The Mac has grown more complex over time, but users are familiar enough with its features and interface to make the leap without much instruction -- or at least so the thinking goes.
Many applications have replaced detailed manuals with online help pages. Experienced users can make good use of these, but they're
not much good to a newbie. A well-designed Web page ought to be fairly
simple to use, but just about any process users have to follow should be at
least minimally documented. I suspect some companies avoid
documentation because they fear it will make their product seem harder to use.
As a user, I'd rather contend with excess documentation than an information deficit.
Cleaner, brighter, better
I tend to agree with the conventional wisdom that says an interface
should be as complicated as its tasks. Unless the application is absolutely essential, users will give up on it if the interface is too complicated. (Of course, Napster showed that essential means different things to different people, and many financial software packages prove that the baseline for complexity can be as undemanding as "easier than doing it by hand.")
But what about interfaces that are too simple? They're annoying, too.
Take the widespread hatred that greeted the Mac's single-button mouse as an
example. On the other hand, both Wii and the iPod have thrived with simple
interfaces. The difference is so obvious you almost can't see it: The
designers didn't just simplify the interface, they also simplified
the product. The iPod doesn't need a button to switch radio bands
because it doesn't receive radio. It doesn't have a backlight button
because the backlight is automatic. The Wii's buttons can be labeled "A, B,
1 and 2," because it doesn't have very many buttons. For many users this has
turned out to be a relief compared to controllers that feature as many as
sixteen different buttons.
Google's search page is the world's most overused example of a simple interface that works -- but for a good reason. Google got it right. I
haven't used another search engine since the first time someone said "Hey,
check this out!" Google's search results are good, but the real thing is the clean, white page. I didn't even realize I was tired of search engine clutter --
the predictable collection of links and text and advertisements found on most
"search engine portals" -- until I found Google. It shouldn't take five minutes to navigate a Web page when all you're looking for is a text box; it shouldn't even take five seconds.
Don't be afraid to de-clutter your interface. Strip out
rarely used features. You don't even have to remove them completely -- just
get them off the main page. The iPod offers a wide range of rarely used
functionality through its menu system, but not as part of the core
interface experience. It's a compromise that has paid off.
What do you know?
As someone once said, "It ain't what you don't know that kills you, it's
what you know that ain't so." Conventional wisdom says that people won't
download an application to access a page they could view as HTML. While I
generally agree with this premise, both Flash and PDF seem to have found a
decent installed base despite it. What's more, as Web 2.0 has shown, users
these days won't stop downloading software and running it. The
consequences can be dire, as security mavens know, but that's not stopping
most users. Does that mean you should make users download a client for
everything? No. But if there's a sound technical reason for using a
downloaded client (if what you want to do requires too much computation for
JavaScript, for example), then go for it. For some tasks, a downloaded
client and a Web page can be quite complementary.
When first laying out a product design, check your assumptions. Start
with your planned feature list. Do you need a Web form for comments or would
an email address suffice? Will all those graphics really make your
page look better, or will they just clutter it up? Are the left navbar, the
right navbar, the footer, and the page header all crucial elements, or could
you maybe combine a couple of them? Is the component you're working on a
good fit for a Web application in the first place? Maybe that index of PDF
files would be better off as a large set of searchable, hyperlinked HTML
pages. What about offering shortcuts for common tasks (such as the famous
one-click shopping feature), in addition to longer versions that include
more options?
You should check your assumptions the way you should vote: early and
often. A good sign that something's gone wrong is that it is turning out to
be considerably more work than expected. Too much elbow grease can be an
indicator that you've made a faulty assumption. Try changing your view of the
problem to see if you can make it go away. Lots of Web sites require users to
enter the date. If you tried to enable this feature using a free-form text box, you would have to anticipate every possible way a user could enter the date.
The problem would be practically insoluble. Fortunately, all you need to get around it is three fields, one each for year, month, and day. Users can quickly input the date in your preset format and everyone is happy. Even
specifying a format, as many Web sites do, is more work than providing
preset fields.
Best practices, meet innovation
After all the times I've stressed the importance of best practices and
familiar solutions, it might seem odd that I'm suddenly encouraging
innovation. Recent advances like the Wii and the iPod click wheel have shown
there is a place for innovation in user interface design. After the Wii came
out, many people argued that the new controller would fail once the novelty
wore off. Actually, I don't think interfaces work that way. People don't use an interface
because it's old or new, but because it's comfortable or effective. It is true that most users resist change. It is very hard for a new interface to overcome the lure of the familiar, but when an innovation works it can be revolutionary.
That said, many so-called innovative ideas are not innovative at all:
They're half-baked and stale. The first person to think of making
"opt-in" a default check box guessed badly. Today, Web sites that attempt to
add visitors to a mailing list by default are considered manipulative, or
just gratuitously dumb. We've done the experiment and we know now what
works. So many mailing lists work badly because they are based on the model
of snail mail. This made sense back in the early days of the
Internet (it was all we had to work with), but these days we know that e-mail
is very different from snail mail, and ought to be managed by a different
set of assumptions. Rethinking mailing lists (starting with recognizing that
people are sick and tired of unsolicited e-mail) would be a welcome
innovation.
If there is a methodology to be associated with innovation, it is
experimentation. A friend once said of the C library that printf() was an experiment that worked, and scanf() was one that didn't. When you try something
new, be ready to admit that it failed and move on. Experiments are risky by
definition: You could put in time and effort only to discover that it isn't
viable. If you don't have the time or resources to take a risk, go with the
tried-and-true. If you can afford to put in a bit of time trying something
new, do it!
Just remember: Every best practice started out as a crackpot theory.
In conclusion
The Principle of least astonishment says that Web applications
should not be full of surprises. Best practices usually have some intrinsic
merit, and much of their value lies in convention. Like the side of the
street you drive on, it isn't important whether it's left or right, just
that everyone agrees. Likewise, innovation doesn't require you to reject
everything you've learned about user interface design. It does require that
you check your assumptions, and cast a wide net on what's possible.
Take a few risks. Try to streamline and simplify procedures. Omit
steps that don't match your users' expectations or plans. If you can simplify
an operation with a single base action (like Google's "I'm Feeling Lucky," or Amazon's "1-Click shopping"), do it!
This week's action item: Check out a few programs or Web pages,
or even that electronic device in your pocket. Notice the features you've never
used and the buttons you've never pushed -- do you even know what they do? Imagine the application without those buttons or features. Is there really anything to miss?
Resources Learn
- "The cranky user: Baby duck syndrome" (Peter Seebach, developerWorks, March 2005): How fear of innovation can lock users into systems and interfaces that don't meet their needs.
- "Building Google gadgets, Part 1: Fundamentals of Google gadgets" (John Muchow, developerWorks, April 2007): Speaking of simplicity, get started with the Google Gadgets API!
- "Real Web 2.0: Bookmarks? Tagging? Delicious!" (Uche Ogbuji, developerWorks, October 2006): An in-depth look at the technology and design ideas behind one of the first, and simplest Web 2.0 sites: del.icio.us.
- "Introducing developerWorks spaces" (Rawn Shah and
Jeanette Fuccella, developerWorks, May 2007): An overview of the recently announced community initiative from IBM developerWorks; also a great case study of one familiar Web site streamlining its social networking interfaces.
- "Buyers line up for Nintendo Wii" (BBC News, November 2006): The BBC reports on
the early success of the Wii games console.
- "Applying the Rule of Least Surprise" (The Art of Unix Programming, Eric Raymond, 2003):
A programmer's notes about the Principle of least astonishment, also known as the Rule of least surprise.
-
Usability.gov: Who knew the US government cared about usability? Get information about planning, analyzing, designing, and testing government-issue Web sites.
-
developerWorks Web technology zone: Resources for Web 2.0, Ajax, wikis, PHP, mashups, and other Web projects.
Discuss
About the author | 
| | Peter Seebach thinks the Wii is the best thing since sliced bread, but still uses a command line. His foolish consistency is the hobgoblin of little minds. |
Rate this page
| |
