Chapter 1: Who're You Calling a Dummy?

Addison Wesley Professional

1 2 3 4 Page 3
Page 3 of 4

A Bad Feature and a Good One

Here's another way programmers screw up user interfaces and make their users feel dumb. On your Windows desktop, select a document, any document. Then press the Delete key. Unless you've figured out how to disable that feature, you'll see a confirmation dialog box like the one in Figure 1–3, asking whether you really want to delete the file.

Figure 1.3

Figure 1-3

Useless confirmation box from Windows Recycle Bin

Have you ever, even once, said, "Whoa! I didn't want to do that. Thanks for asking me," and clicked No? Have you seen anyone do that, or even heard of that happening? I haven't. Confirmation has been so vastly overused that it has, ironically, become completely useless. Because this box is constantly "crying wolf," like the shepherd boy in Aesop's fable, no one pays attention to it, even when it's warning you of a file you really don't want to delete. You've seen it so often that it doesn't register. You cruise through it on autopilot, clicking Yes unconsciously. It provides you with no safety whatsoever. None. Fortunately, you can turn off this particular confirmation dialog.6 Many others exist that you can't get rid of, and none of them should exist. At all. Anywhere. Ever.

Other operations in life don't require confirmation. Your car does not ask, "Do you really want to start the engine?" when you turn the key. The supermarket clerk does not ask, "Do you really want to buy these?" when you place your groceries on the register belt. Think how many more books you've bought from since you discovered their patented 1-Click ordering capability.7

Why do programmers constantly ask for confirmation? They do it because they think their users are confused and don't understand the consequences of what they've just told the program to do. That may well be true, given the awful quality of the rest of the user interface. But confirmation doesn't solve this problem. If the user was confused when he first gave whatever command triggered the confirmation box, he'll be even more confused when he sees it. Since the program seems reluctant to do what he told it to do, he thinks he's made some kind of mistake. The use of a confirmation box keeps programmers from having to a) clearly explain to the user what he's doing, so he doesn't try to do stuff he doesn't want to, and b) provide a way to recover in the event the user really does do something that he later regrets.

But what if the user really is making a mistake? If you put, say, a flashlight on the register belt with a package of the wrong size batteries, wouldn't an attentive clerk ask, "Are you sure you want these?" Shouldn't a good user interface save us from mistakes like that? It certainly should, and one of the beauties of computer programs is that it can. But that won't happen by blindly asking, every single time, "Are you sure you really want to do whatever the hell it is that you just told me to do?" Instead, a good user interface would prevent the problem from ever occurring in the first place. Perhaps the Web page selling flashlights would contain a checkbox saying, "Include batteries." It'd be checked by default, because the flashlight won't work without batteries. A buyer who already has lots of batteries in that size could uncheck it. Or better still, the flashlight would be shrink-wrapped with batteries already inside it, so it would work the instant you unwrapped it and no one would ever have to think about it. A smart user interface designer would have thought of that before programming even started. If a programmer thinks he needs a confirmation box, I guarantee you that he's screwed up some other part of the user interface that would prevent the need for it. He probably hasn't even tried, and it probably never occurred to him that he should. Confirmation is a crutch for the lazy or ignorant programmer, paid for by every user. And it's one that doesn't work.

But wouldn't you want to confirm destructive acts, such as deleting the file? No, not really. Another reason you aren't asked to confirm starting your car or buying those groceries is that these operations are easy and cheap to undo if you suddenly realize you've made a mistake. You just turn off the ignition or return the unwanted item. Computer programs can very quickly and easily make copies of documents and pieces of memory. This allows programmers to provide users with the ability of reversing actions they've performed. This Undo capability is one of the very best in the user interface designer's arsenal. To my mind, it's the single biggest advance in user interface design since the mouse.

If you click Yes on the confirmation box in Figure 1–3 (or if you've turned off the box completely), Windows doesn't actually wipe the document off your computer. Instead, it moves it to another area of the disk, called the Recycle Bin, which is analogous to the famous trash can on the Macintosh. If you change your mind after doing this and want the document back again, you can retrieve it from the Recycle Bin as long as you haven't emptied the bin. You really do want to move the file almost all of the time. It's much more efficient to fix the relatively small number of errors that actually do occur (for example, a slip of the mouse that caused you to select the wrong file for deletion; I did that yesterday) than attempt to prevent them by annoying every user with a confirmation box at every deletion, especially since the latter doesn't work because of its overuse. An ounce of cure is not worth five pounds of prevention.

The Undo feature can work not only with file operations, but also within applications. It's usually found on the Edit menu, along with its companion, Redo (which undoes the undo, of course). I can't write for five minutes without undoing something; typing a foolish sentence, perhaps, or moving text to the wrong place. The programmers who implement this feature are any user's best friends. I buy them beer whenever I meet with them, and so should you. It takes an enormous amount of effort to make this feature work so that users don't have to think about it ("Easy is hard," the saying goes); just Ctrl-Z (little and ring fingers of the left hand) and back it all comes. A program should confirm only the operations that it can't undo. And it should be able to undo everything.

The real beauty of Undo is that it allows users to explore a program. It's not always easy to understand a new program's operation from the short labels on menu items and the tiny pictures on toolbar buttons. But because Undo exists, a user can experiment by trying different things, knowing that he won't damage something that can't be repaired with a few keystrokes. I can move a paragraph around to see how I like it somewhere else, and quickly undo the operation if I don't. Programmers often regard incorrect user input as the act of an idoit who should have sat down and read the manual. It isn't. It is the primary mechanism by which the human species learns. An application with Undo capability becomes explorable, not frightening. It recognizes and enhances the user's humanity. Failure to implement it properly is a mortal sin.

If Undo is implemented correctly, there is only one destructive operation in the entire system, and that's emptying the Recycle Bin. Some would say that this operation should have a confirmation dialog box, as it currently does. But even here, the confirmation dialog exists only to guard against another bad design, placing the Explore context menu item right next to Empty Recycle Bin. One slip of the mouse, sliding down three spaces on the context menu rather than two, and you get the latter rather than the former. Bad. Since it's the only destructive action in the system, emptying the Recycle Bin should have a special action used for no other purpose, maybe clicking both mouse buttons on it at once (an operation called chording), or clicking on it while holding down some key. Better still the Recycle Bin should empty itself automatically, deleting files after they've been inside it for some configurable amount of time, maybe starting at a month, so that you rarely have to empty it manually. Don't you wish your home garbage cans would do that? You should never see a confirmation dialog anywhere, under any circumstances. A programmer who shows one has abdicated responsibility and should not be in the user interface business.

Stopping the Proceedings with Idiocy

Programmer-designed user interfaces are at their absolute worst when communicating error messages to the user. Just today while goofing off from writing this chapter, I read's home page and wanted to save a copy of it to my disk. I selected File, Save from my Web browser's menu. A dialog box appeared showing the progress of the saving operation—5% complete, 15% complete, and so on, up to 99% complete. Then that box went away and up popped the one in Figure 1–4.

Figure 1.4

Figure 1-4

Really stupid dialog box

This box is the creation of a true idoit. Why couldn't the Web page be saved, and is there anything I can do to fix it? Was the page copy protected somehow, as professional artist sites sometimes try? Was the server unavailable? Why did the progress bar get up to 99 percent if the operation was failing? Where's the 99 percent of the page that it told me it saved? That's not as good as 100 percent, but I'd much rather have it than nothing. Why has it disappeared? The box says the page couldn't be saved to the selected location; does that mean it could be saved to some other location? If so, where, and how would I know? If not, why is it mentioning location? The browser has already successfully shown me the page, that's why I said to save it; why doesn't it just save the data it's actually showing? The box doesn't tell me how to figure out exactly what the problem is, or where to go for more information. And for a response, it offers only the OK button. No, it is not OK with me that this operation didn't work and the program can't explain why. Even the title of the box, "Error Saving Web Page," is erroneous. I didn't make an error. I did what the program allowed me to do. The program made an error when it wouldn't save my page and then made another when it couldn't explain why. To cause all this confusion with only 15 words, two of which are the, is the greatest accomplishment of idoicy I've ever seen.

Alan Cooper, the user interface design guru I mentioned previously, refers to situations of this type as "stopping the proceedings with idiocy," an excellent phrase even if he doesn't use my spelling of the last word. If I really can't save that page, my browser should know that, prevent me from trying, and somehow explain it to me, ideally without popping another stupid box into my face. Perhaps the Save menu should be grayed out when I go to that page, maybe changed to read "Can't Save–Protected" so that I'd know what and why. If it can't save the entire page, it should save what it can and inform me about what it missed—again, without making me click on another stupid dialog box. Perhaps the saved page would include placeholders in the areas it couldn't save, showing the little red X graphic used in the browser display when a requested page element can't be found.

By rooting around behind the scenes, I was able to piece together what happened. I had set my browser to block certain types of annoying content. The browser displays them as blank areas on the screen, which I vastly prefer to the stupid dancing advertisements that usually appear there. (I'll discuss the idoicy of dancing advertisements in another chapter.) When the saving portion of the program encountered these portions of the page and found them blocked, it didn't ignore them as the display portion of the program did. Instead, it choked on them, aborted the entire process instead of keeping what it could, and stopped the proceedings with the idiocy I just described.

How can anyone not feel like a dummy when someone pops up an incomprehensible box like that? By knowing that it's not your fault at all, but rather that the programmer is failing in his duty. By realizing that no user should have to understand such a stupid communication. By imagining your hands around that programmer's throat and your knee slamming into his crotch like a pile driver. By following the suggestions at the end of this chapter and in the last chapter of this book.

Testing on Live Animals

A programmer would never ship a product without testing its internal operation (OK, she shouldn't). Why would she think she could get away without testing a user interface, to find out whether users really can use it? Because she knows she likes it and finds it usable, so how could anyone else fail to do so? As we've already seen, this unconscious assumption is almost always wrong. Computers that users can't figure out how to use are very expensive paperweights. Testing the user interface, called usability testing, is difficult and expensive, but necessary.

She can't just give users her program and ask them afterward how they liked it. They often won't remember what they did, or they won't want to tell her about a problem they had because they feel stupid that they couldn't figure it out, or they won't want to insult her by telling her what a complete pile of crap the product of her last two years of professional life has turned out to be. (This is a problem that I do not have, as you've probably guessed by now.) To find out what works, programmers have to observe exactly what users do in the act of dealing with the user interface. What do they try to do first? Where do they go next? How many times do they try something before they actually figure it out? How long does it take them to notice such-and-such a feature?

And they have to observe in a manner that doesn't affect the users' behavior. This means the users have to be in an isolated room, having access to only whatever support materials (e.g., online documentation, or maybe Google) they will have in real life. You have to watch them through one-way glass, videotaping their reactions, and have logging software so that you can see exactly which keystrokes and mouse clicks they used to try to deal with your application. Some usability labs even have tracking headsets that report which part of the screen the user is looking at.

When you do this, the light bulb goes on. As Alan Cooper wrote in his classic book, About Face: The Essentials of User Interface Design (IDG Books, 1995): "[Usability professionals] drag programmers into dark rooms, where they watch through one-way mirrors as hapless users struggle with their software. At first, the programmers suspect that the test subject has brain damage. Finally, after much painful observation, the programmers are forced to bow to empirical evidence. They admit that their user interface design needs work, and they vow to fix it."

Unfortunately, usability testing often gets left until late in the development process, just before the product ships. Schedules invariably slip,8 so usability testing is often omitted completely. When it actually does turn up useful information, the schedule often doesn't allow time for changing the program in response. Usability testing needs to be done early, ideally before any programming takes place.

Some companies think that vast amounts of testing just before release will result in a more usable product. For example, Microsoft does what it calls "dog-fooding," which is short for "eating our own dog food." Just before the company releases a product to the public, it'll give it to real users inside the company—for example, switching the secretaries over to the next edition of Word for Windows. This does catch some bugs, by which I mean programmer logic errors, where they forgot to carry the two or something, causing the program to break. But that's too late for catching design errors, particularly in the area of usability. Eating your own dog food before releasing it to users helps your dog food taste slightly better than it otherwise would. But it won't change it into cat food, and the dog food stage is too late to discover that your users really are cats, or giraffes.

Here's an example of doing it right. I once consulted at an insurance company that was writing a Windows program to replace some expensive IBM terminals. Unusually for an insurance company, they actually did the usability testing that I just told you about. And they did it properly, too, with videotape and programmers watching through one-way glass. They found that the users basically liked the application and found it usable. But the users had the habit of pressing the Enter key to move from one input field to the next, as their IBM terminals did, rather than the Tab key, as Windows applications do. Couldn't the developers change that, they asked? After thinking it through carefully, the developers decided that, although it would be quite easy technically, it wouldn't make the users happy, even though the users thought it would. Sure, they could make this application work the old way. But all the new commercial Windows applications the users were soon going to have wouldn't work that way, and the users would soon go schizoid switching back and forth many times per day. So the developers convinced the users to bite the bullet and make the change. And after the requisite period of squawking, the users calmed down and swallowed it, helped by the abysmal job market in the area at that time. My point is not that programmers should cram down users' throats the features they think would be good for them. You usually can't get away with that; this was a special case. I'm relating the story to show you how a client of mine did a good job of usability testing. They did the testing they needed to do. They found what there was to find. And then they made the right decision based on what they found. I wish more companies would do that.

Where We Are and What You Can Do

Where does that leave us poor users? To summarize my points so far:

  1. You are not dumb. User interfaces really do suck, and they shouldn't.

  2. They suck because they're designed by programmers, who don't realize that their users aren't like themselves.

  3. Because of point 2, their interfaces are intentionally complex, and they expect you to like dealing with that, which you don't (see point 1).

User interfaces could be made much better by involving usability specialists from the beginning of every software project. General programmers are worse than useless in this regard. Someone has to speak for the silent majority of users who don't give a flying fish about the technology for its own sake, who just want to get their work done so that they can get back to living their lives. I try to fill this role at every design review I attend. "You're like the guys who design the drills that they sell at Home Depot," I tell the programmers. "Here you are, arguing over this or that internal detail of drills, ball bearings versus roller bearings versus air bearings, each of you claiming that's what your customer wants more than anything in the world. Wrong. The customer doesn't care about your drill for its own sake, not one tiny bit. Never has, never will. He doesn't go to Home Depot because he wants a drill. He goes to Home Depot because he wants holes. If he could just buy a box of holes to put on his wall, without having to touch a drill, he'd be much happier. (Remember Ringo in the movie Yellow Submarine? "I've got a hole in my pocket...".) Your drill is a necessary evil in your user's quest for holes. Now ask yourself, and answer truthfully: "What kind of hole does your user really want, and how is your program going to get him better holes, faster, for less money?"

Now that you've finished this chapter, you're as qualified as anyone to tell software vendors what you like and what you don't like. The structure of a program's user interface was not handed down as a commandment on Mount Sinai. It's created by the design decisions of programmers and other developers, who could just as easily make other ones. Send them e-mail, lots of it. Tell them what you like and what you don't like. Tell them to get that confirmation thing out of your face and provide better Undo capability.

More than anything else in the world, programmers hate looking dumb. Ugly, impotent, unkind to children and small animals, they don't care, but dumb? May the Good Lord have mercy on us. Their view of themselves prizes intelligence far above everything else. If you need to make a programmer do something, ensure that he'll look stupid in public if he doesn't do it.

So the next time you see a badly designed user interface, stop and look at it. Play for a while; figure out exactly and specifically why you don't like it, and what would make you happier. Post a notice about the bad design on a "Hall of Shame" Web site that exists for this purpose. This book's Web site,, would be a good place to start. Then send e-mail to the application company, showing them your public exposé. The more stupid you've caught them being, the more it'll gall them to see it publicized. Then they might, might finally get it through their heads that their users aren't themselves.

1 2 3 4 Page 3
Page 3 of 4
The 10 most powerful companies in enterprise networking 2022