Chapter 1: Who're You Calling a Dummy?

Addison Wesley Professional

1 2 3 4 Page 2
Page 2 of 4

Notepad asking the user whether to save changes

What exactly is this box asking us? It seems to be saying that some file changed, but I haven't seen any file anywhere. What the hell does "save the changes" mean?

The answer is that Notepad usually edits documents (called files by computer geeks) which live on your computer's hard drive. When you open a document, Notepad copies it from the disk into the computer's memory. As you add or remove text by typing, the program changes the contents of this memory copy. (In this example, we didn't open an existing document, but the program created a new one in memory, giving it the name "Untitled".) When you're finished working on the document, the program has to write the memory copy back to the disk, an operation called saving the file. Otherwise, the work you've done will disappear, and you'll get very angry.

The programmer wrote the program this way (copy the document from disk to memory, make changes on the memory copy, and write it back to disk) because that was easiest for her. And it's not a bad way to write a program. Reading or writing characters from the disk (spinning iron platters with moveable parts) is roughly a thousand times slower than doing it in memory (electrons moving at the speed of light), so this probably is the best way for this simple program to work internally.

But the programmer's user interface exposes these workings directly. How can that be bad? She's forcing you to understand that she's written the program this way. You shouldn't have to know or care about her program's internal workings to use it successfully, as you shouldn't have to know or care whether your car's engine uses fuel injection or a carburetor in order to drive it.

You don't normally think in the way that this program works. Most people think of editing a computer document as analogous to the paper-and-pencil (remember those?) method. You make marks with the pencil and there they are on the paper. You erase the ones you don't want. If you don't want any of them, you crumple up the paper and throw it away. The work you've done is permanent, unless you expend energy to get rid of it. But that's not the choice Notepad gives you. Every single new user of computers gets caught on this—selecting No, in which case Notepad discards the work you've done, which hopefully isn't much. Eventually, the user learns to think like a computer program, or more precisely, like the programmer who wrote this mess. User interface design guru Alan Cooper defines a "computer-literate user" as one who has been hurt so many times that the scar tissue is thick enough so he no longer feels the pain.

The question and its answer would be much clearer if the message box asked "Throw away everything you've just done?" It's exactly the same question, just asked from the user's point of view rather than the programmer's. But the programmer is thinking only of her program's operation, writing to the disk, and asks you whether to do that. She's requiring you to wear her shoes; she hasn't even tried to put herself in yours. If she had, she'd ask the question a different way. She might then see the ridiculousness of asking it at all, and design a better user interface, even if the underlying program worked the same way.

Microsoft Money, the personal finance program, does a better job. Its designers understand that the user's mental model is a checkbook, and his screen looks like a checkbook register (Figure 1–2). It feels familiar and comfortable (well, relatively) to a new user. The check that you're currently working on is shown in a different color. You enter the check's details and press Enter. The check moves up, changes color to look like the rest of them, and a new empty check appears in the work area. If you have sound turned on, you hear a "ka-ching" cash-register type of sound.5 The program doesn't ask you whether to save the check. The act of pressing Enter tells the program that you want to keep that information. If you later change your mind and want to change the data on a check or delete one entirely, you click on that check in the register and type in the new information. When does the program read its data from the disk to memory, and when does it write it back again? I don't know and I don't care. And I don't want to and neither do you. The program's user interface follows your mental model, instead of forcing you to learn and deal with the internal design choices of its programmers.

Figure 1.2

Figure 1-2

Microsoft Money user interface, looking like a checkbook

That's a much better way of designing a user interface. As a user, I don't want to think about the program itself. I want to think about the job the program is doing for me—for example, do I have enough money to pay this bill? Another user interface design guru, Donald Norman, expressed this feeling very well in the title of one of his books: The Invisible Computer (MIT Press, 1999). Ideally, I wouldn't think about the program at all.

That's one major reason programs are hard to use and make you feel dumb. You're being forced to think like a programmer, even though you're not one and you don't want to be one. You shouldn't have to. You don't have to think like a mechanic to drive a car, you don't have to think like a doctor to take an aspirin, and you don't have to think like a butcher to grill a hamburger. You're paying your hard-earned money for this product. It's the programmer's job to adjust to you, not the other way around.

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 Amazon.com 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.

Related:
1 2 3 4 Page 2
Page 2 of 4
IT Salary Survey: The results are in