A more formal definition is that a heuristic is a rule that's probably right, but not guaranteed to be right: English speakers intend to type "the" much more often than they intend to
Trang 1Then usability testing reveals that some people like their marshmallows almost raw, while
others want them virtually charred with liquefied middles (mmmm) It's not just a matter of
how long they cook: it's a matter of how quickly you turn them over the heat, whether the
heat is radiant or from a flame, and so on Eventually your little marshmallow-grilling device
has six different adjustment knobs and two kinds of heating elements
"This is for the workplace," your head UI designer tells you "It will be used by many different
people Those people aren't going to want to remember all their personal settings." So you
add a Save Settings button with a little LCD panel, and a Load Settings button Now,
you can file your personal marshmallow-grilling settings under your own name
"Privacy!" scream the privacy advocates "What if we want to be able to save our settings
without every gossip in the office knowing how we like our s'mores?!" Fine A password
feature is added
"What if someone forgets their password?" Now it's getting ridiculous OK The password
feature is enhanced with one of those silly challenge-response questions like "What's your
mother's maiden name?" and, if hooked up to the LAN, it can email you your password when
you forget it
By now, the tiny LCD panel has grown into a 15″ color screen, the control panel looks like
the cockpit of the space shuttle, and it costs $1275 to manufacture But after two years in
development, the thing finally ships!
Your very first customer buys one and takes it home, excited But when she gets it out of the
box, there's a two-hundred-page manual, a software license agreement, a control panel with
dozens of buttons, a programming handbook for the scripting language, and the screen is
asking her if she wants to sign up for AOL
The "Months = Minutes" rule is a corollary to the "Days = Seconds" rule When you create a
new software package, even a fairly simple one, it typically takes between six months and
two years from the initial conception to shipping the final bits During those months or years,
you have an awful lot of time to learn about your own program and how it works When you
invent a new concept every month or so for two years, the learning curve is not very steep—
for you For your user, it means there are twelve things to learn right out of the box in the first
five minutes of using the dang thing
The products that we recognize as being the best designs always seem to have the fewest
buttons While those products were being created, it's pretty obvious that the designers kept
thinking of ways to simplify the interface, not complicate it Eventually VCR designers
realized that when you stick a videotape in the slot, they should switch from TV to VCR
mode and start, um, playing the tape And then they figured out that when it's done playing
the tape, it might as well rewind and eject it For watching movies, at least, you don't need to
press a single button
As you design and build your product, try to notice if you are adding complications or
removing complications If you're adding complications, remember that something that
seems easy when you have months to design it is not going to seem so easy when your
user has only minutes to learn about it
Seconds Are Hours
The third time warp rule is that it doesn't take very long before somebody gets bored and
decides that your program is slow If your program feels slow, your users won't feel in
control, and they'll be less happy "Seconds = Hours" refers to the fact that if you make
Trang 2somebody wait, say, nine seconds, they will whine and cry about how it took hours People
are not very fair You can give them a Web site where they can find over thirty-four thousand
recipes for tuna casserole in seconds, something that used to take a trip to Washington,
D.C and months of research in the Ladies Home Journal archives of the Library of
Congress, but if a recipe takes thirty seconds to appear on the screen, your ingrate users will
moan about the "World Wide Wait" and how slow their modem is
How long is too long? This has been the subject of years of debate among usability experts
and Human Boredom Research scientists I am happy to announce that after an exhaustive
survey of over twenty thousand college sophomores, I have the final answer Boredom kicks
in after 2.73 seconds, precisely So let's all keep our latency to 2.72 seconds or less, OK?
Just kidding!
The real answer is that it's not the passage of time that's boring, it's boredom that's boring I
can walk three miles down Fifth Avenue in Manhattan without getting bored, but walking a
thousand feet past featureless cow pasture in Kansas feels like it takes an eternity Boredom
is a function of the rate at which stimulating things happen to your brain
When someone clicks on a link on a Web site, they are probably not doing anything but
waiting for that page to appear So if it takes ten seconds to show up instead of five seconds,
it seems like a really long time On the other hand, when they start to download the latest
Ricky Martin MP3 over a modem, it's going to take twenty minutes, so they find something
else to do while they wait And if it takes twenty-one minutes instead of twenty minutes, it's
no big deal
To fight boredom, create the illusion of low latency Good UI designers use three tricks to do
this
Trick One Always respond immediately to the user's request, even if you don't have a final
answer There's nothing more annoying than a program that appears as if it's not responding
to mouse clicks simply because it's performing a long operation You should always give an
immediate response, even if it's nothing more than changing the cursor to an hourglass or
displaying a progress indicator (Among other things, this lets the user know that the
program received their click A program that doesn't respond immediately to mouse and
keyboard input appears dead to the user At the very least, they will click again.)
Trick Two Find creative ways to break up long operations The best example I've seen of
this is in Microsoft Visual Basic The designers of the Basic compiler realized that almost all
of the time spent compiling is actually spent parsing the program text (that is, breaking down
a line of code into its constituent parts) If it takes, say, half a second to parse a single line of
code, and one one-hundredth of a second for everything else, then a hundred-line program
will take fifty-one seconds to compile But the Visual Basic designers put the parser into the
editor When you hit Enter after typing a line of text into the editor, that line is immediately
parsed and stored in parsed form So now, hitting Enter takes half a second, barely
perceptible, and compiling a hundred-line program takes one second, also barely
perceptible
Trick Three is the exact opposite of Trick Two When all else fails, bunch together all the
slow operations The classic example is your extremely slow setup program It's slow
because it has to download files, uncompress them, and install them There's nothing you
can do about that But what you can do is make sure that all the slow bits are done at the
end, after gathering any required input from the user Have you ever started a long
installation procedure and gone to watch TV, only to come back an hour later to find that the
setup program has stopped and is waiting for you to OK the license agreement before it
starts downloading? When you have a really long operation, always get all the input you
Trang 3need from the user first, then tell them explicitly that "this will take a while Go get some
M&Ms."
Trang 4Chapter 15: But …How Do It Know?"
Remember the old advertising slogan for Thermoses? They "Keep Hot Drinks Hot and Cold
Drinks Cold!" To which your slightly brighter-than-average five-year-old asks: "But…how do
it know?"
That's what we in the software design field call a heuristic Here are a few well-known
examples of heuristics:
If you type the word "teh" in Microsoft Word, Word will decide you probably meant "the"
and change it for you
If you enter "Monday" into a cell in Microsoft Excel and then drag down, you get the
days of the week (see Figure 15-1)
Figure 15-1: Excel has heuristically decided that you must want the days of the
week because you happened to type Monday (But… how do it know?)
When you search for text that looks like an address using the Google search engine, it
will offer to show you a map of that location
If you buy a lot of Danielle Steel books on Amazon.com, and a new one comes out, the
next time you visit Amazon.com they will try to sell it to you
As a rule of thumb, the way you know something is a heuristic is that it makes you wonder,
"how do it know?" The term heuristic itself comes from the field of artificial intelligence,
where it's used when the fuzziness of real life doesn't line up properly with the sharp
true/false world of computers A more formal definition is that a heuristic is a rule that's
probably right, but not guaranteed to be right:
English speakers intend to type "the" much more often than they intend to type "teh." If
they typed "teh," it's probably a mistake
When you type "Monday," you are probably referring to the day of the week If you
expand out the series, you probably want to see days of the week
When you type something that looks like a number followed by a name followed by the
word "Street," it's probably an address
If you buy a lot of Danielle Steel books on Amazon.com, you'll probably want to buy the
new one
The operative word here is always probably We're not sure That's why it's just a heuristic,
not a hard and fast rule
In the olden days of programming, heuristics were very, very uncommon, because
programmers are very logical creatures and they don't like rules that are "98% right." In the
logical world of programmers, "teh" and "the" are equally valid sequences of three ASCII
characters, and there is no logical reason to give one of them special treatment But as soon
as the designers of Microsoft Word broke through this mental logjam, they realized that there
were zillions of interesting assumptions you could make about what people wanted If you
typed a paragraph starting with an asterisk, you probably want a bullet! If you type a bunch
of hyphens, you probably want a horizontal line! If you start out a document with "Dear
Mom," you're probably writing her a letter!
Trang 5In their zeal for heuristics, the designers of Microsoft Office came up with more and more
clever features, which they marketed as IntelliSense As a marketing pitch, these features
sound really neat Word figures out what you want and does it "automatically!"
Unfortunately, somewhere, something went wrong Woody Leonhard wrote a whole book
called Word 97 Annoyances, mostly about how to turn off the various heuristics, and people
were so thankful they gave the book five-star ratings on Amazon.com Somehow, heuristics
crossed the line from "doing what you want automatically" to "annoyances."
Nobody sets out to write annoying software So where is the line? When does a heuristic
stop being a really cool, helpful feature that saves time and start being an annoyance?
Here's the thought process that goes into developing a typical heuristic:
1 If the user types "teh," there's a 99% chance they meant "the."
2 So we'll just change it to "the" for them Then there's a 1% chance that we're wrong
3 If we're wrong, the user will have to undo the change we made
4 Ninety-nine out of one hundred times, we improved the user's life One time out of one
hundred, we made it worse Net value to user: 98% improvement
This tends to get generalized as:
1 If the user does x, there's an n% chance they meant y
2 So we'll just do y for them Then there's a (100 – n) chance that we're wrong
3 If we're wrong, the user will have to correct us
4 Net value to user: (100 – 2n)%, which is better than doing nothing for n>50
Aha! I think I've found the bug It's in step 4, which does not logically follow Happiness is not
linear It doesn't really make a user that happy when they type "teh" and get "the." And
happiness is not cumulative The bottom line is that every single time you apply a heuristic
incorrectly, you are making the user a lot more unhappy than you made them happy by
applying the heuristic correctly all the other times Annoyances are annoyances, and people
don't weigh annoyances against joy when deciding how happy to be They just get annoyed
How annoyed? That depends on step 3: how hard it is to undo the heuristic if the program
guessed wrong In Word, it's supposed to be pretty easy: you can just hit Ctrl+Z, which
means Undo But a lot of people, even people who know about the Undo command, don't
realize that Undo undoes the computer's actions as well as their own And if you watch
them, they usually try to undo the error themselves by backspacing and retyping, and of
course, Word blindly applies the wrong heuristic again, and now they're getting really
frustrated and they don't know how to fix it By now the annoyance factor is deep into the
triple digits, which has more than wiped out the minor satisfaction that the heuristic was
intended to cause in the first place
In general, I don't like heuristics because of the principle from Chapter 2:
If your program model is nontrivial, it's probably not the same as the user
model
This gets back to the "How Do It Know" factor If users can't figure out why the program is
applying a heuristic, they will certainly be surprised by it, producing a classic example of "the
user model doesn't correspond to the (inscrutable) program model," and therefore, the
program will be hard to use To judge a heuristic, you have to decide if the rule for the
heuristic is obvious enough, or if users are going to stare blankly at the screen and say,
"how do it know?" Turning "teh" into "the" may be obvious, but changing three dashes into a
horizontal line is probably not what people expected, and they probably won't know why it's
happening This makes it a bad heuristic because it leads people to say, "how do it know?"
Trang 6The second way to judge a heuristic is by the difficulty of undoing it, and how obvious the
undo procedure is When you write a check in Intuit's Quicken program, and you start typing
the name of the payee, Quicken looks for other payees that start with the same letters as the
payee you're typing and pretypes that for you So if you've paid someone named "Lucian the
Meatball" in the past, and you type "Lu," Quicken will propose the full name "Lucian the
Meatball." That's the heuristic part, and it's pretty obvious why it's happening—nobody's
going to ask "how do it know?" But the brilliant part of Quicken is that the "cian the Meatball"
part will be selected, so that if the heuristic was wrong, all you have to do was keep typing
and it will effectively undo the heuristic right away (This invention spread from Intuit's
Quicken to Microsoft Excel and eventually to Microsoft Windows) When a heuristic is really
easy to undo, and it's obvious how to undo it, people won't be so annoyed
The third way to judge a heuristic is, of course, by how likely it is to be correct Changing
"teh" to "the" is pretty likely to be correct (although it was wrong about ten times while I was
typing this chapter) But a lot of other heuristics are less likely to be correct (such as Word's
morbid insistence that I want help writing a letter)
A good heuristic is obvious, easily undone, and extremely likely to be
correct Other heuristics are annoying
Trang 7Chapter 16: Tricks of the Trade
Overview
Here we are, almost at the end of the book, and I still have a whole bunch of important
factoids to tell you that don't fit neatly into chapters But they're pretty important factoids:
Know how to use color
Know how to use icons
Know the rules of internationalization
Let's go through these one at a time
Know How to Use Color
When I set up my office files, I bought a big box of file folders The box came with four
different color folders: red, yellow, manila, and blue I decided to use one color for clients,
one color for employees, one color for receipts, and the fourth color for everything else
Outrageously sensible, right?
No The truth is that when I'm not looking at the files, I can't remember the color scheme,
and in fact, the color scheme doesn't seem to help at all As it turns out, using different
colors is good for distinguishing things, but not for coding things If you have a bunch of red
folders and a bunch of blue folders, it's easy to tell that they are different, but it's harder to
remember which color means which
The general rule for how to use color was best stated by Web designer Diane Wilson:
"Design in black and white Add color for emphasis, when your design is
complete."
Strange as it may seem, creating a color code doesn't really work People have trouble
remembering the association of colors to meanings In fact, if you make a pie chart using five
different colors, with a little legend showing the meaning of the colors, it's surprising how
hard it is cognitively for people to figure out which wedge belongs to which label It's not
impossible, of course, it's just not super easy Putting labels next to the wedges is a million
times easier (see Figure 16-1)
Trang 8Figure 16-1: People have trouble remembering color codes Don't rely on color to
convey meaning
There's another important reason you can't rely on color to convey meaning: many people
can't see it No, I don't mean the old timers who still have green-on-green screens But about
5% of all males (and a much smaller number of females) have some degree of color
blindness and simply cannot distinguish colors (particularly red and green, which is why
stoplights are vertical)
Color can be used successfully for a few things:
1 As decoration—in pictures, icons, and text, where the effect is solely decorative
2 To separate things—as long as you do not rely on the color as the only indicator, you
can use color as one distinguishing factor, for example, by using a different color and
a larger font for headings
3 To indicate availability—by using grey to indicate an option that isn't available Even
most colorblind users can distinguish greys from blacks Similarly you can use lightly
shaded backgrounds to indicate areas where the user can't edit, and white
backgrounds to indicate areas where the user can edit This has been a GUI
convention for so long that most people understand it subconsciously
Always honor the system color settings, that is, the colors that the user chose in the control
panel Users have deliberately chosen those colors to give their computer the color scheme
they like Also, many of your vision-impaired users have deliberately set up schemes that
they can see more clearly (For that matter, always honor the system fonts so that your text
is readable by people who prefer larger fonts.)
Know How to Use Icons
A picture is worth a thousand words, you think? Well, not if you're trying to make a picture of
the "schedule meeting" command and you've only got 256 pixels total to do it in (I know, I
know, now you're all going to email me your clever icon renditions of "schedule meeting" in
…) Here's the trick with icons As a rule of thumb, they work pretty well for nouns,
Trang 9especially real-world objects, where you can create an icon by making a picture of the thing
But they don't work so well for verbs, because 16 × 16 is not a lot of space to show an
action In a typical word processor, the icon for numbered lists (Figure 16-2) is amazingly
obvious Hey, it looks like a numbered list! But the icon for "Paste" (Figure 16-3) is not so
obvious Even after you've learned it, it requires too much cognitive effort to recall
Figure 16-2: The icon for numbered lists is just a picture of what it does, so it's easy to
recognize
Figure 16-3: The icon for Paste is attempting to depict a verb, so it's not very easy to
recognize
Know the Rules of Internationalization
You may not be internationalizing your product now, but chances are, you will The cost of
translating a software product is far less than the cost of writing it in the first place, and you
can often sell as many copies in a second language as you can in the original (especially if
the original language is Icelandic, and you're translating it to English.) There are a lot of rules
about how to write good international software, which are beyond the scope of this book In
fact, there are whole books on the topic But for user interface design, there are three crucial
things you should try to keep in mind
Rule One: the translated text is almost always longer than the original Sometimes it's
because some languages like to use forty-seven-letter words for the simplest concepts
(Ahem! You know who you are!) Sometimes it's just because when you translate something,
you need more words to convey the exact meaning of the word in the original language In
any case, if your user interface relies on certain important words fitting into a certain number
of pixels, you're almost always going to have trouble when you go to translate it
Rule Two: think about cultural variables Americans should realize that phone numbers are
not always seven digits long with a dash after the third digit If somebody's name is X Y,
don't assume that they are Mr Y; they could just as well be Mrs X Non-Americans should
remember that Americans don't have the foggiest idea what a centimeter is (they think it's a
multilegged creepy-crawly) Microsoft Excel uses a U.S dollar sign icon ($) to format cells as
currency, but in non-U.S versions of Excel, they use an icon showing coins instead And
don't get me started about lexical sort orders or the odd way the Swedes sort things—you
Trang 10could never find yourself in the phone book in Stockholm, even if you lived there and had a
Swedish telephone, and so forth
Rule Three: be culturally sensitive If your software shows maps, even for something
innocuous like time-zone selection, be real careful about where the borders go, because
somewhere, someone is going to get offended (Microsoft now has a full-time employee who
worries about this, after Windows 95 was banned in India for failing to reflect India's claim on
Kashmir—a matter of a few pixels in the time-zone control panel.)
Don't use a little pig for your "Save" icon (get it? Piggy banks? Savings?) because piggy
banks aren't universal In fact, don't use puns anywhere in your user interface (or in your
speeches, or books, or even in your private journal; they are not funny) Don't use a hand
palm-up to mean "stop," because it's offensive in some cultures
In general, don't release software in another language without doing a little bit of cultural
testing on native speakers I had a scanner once that displayed a dialog box saying, and I
quote: "The Scanner begins to warm up!" The upper case ‘S’ in "scanner" was proof, but the
whole sentence just sounds like it was written in German and translated to English (as,
indeed, it was) Weird, huh? There's nothing grammatically wrong with it, but it doesn't sound
like something a native English speaker would say One famous program from Australia,
Trumpet Winsock, made Americans think that it was written by an illiterate moron, mainly
because it used the word "Dialler" all over the user interface, which Americans spell,
"Dialer." To an American, using two ‘L's looks like the kind of mistake a young child might
make (Other Australian spellings, like "neighbour," look merely British to the average
American, not illiterate)
The best way to become culturally sensitive, I think, is to live in another country for a year or
two, and travel extensively It's especially helpful if that country has nice warm beaches, or
wonderful cultural institutions, or spectacularly beautiful people Great restaurants also help
You should ask your boss to pay for this as a part of your UI training And when you've
figured out where the best beaches and restaurants are, you should top off your training with
a course in UI design from someone like, ahem, myself