CHAPTER 3: Choices – User Interface Design for Programmers


When you go into a restaurant and see a sign that says "No Dogs Allowed," you might think that sign is purely proscriptive: Mr. Restaurant doesn't like dogs around, so when he built the restaurant he put up that sign.

If that was all that was going on, there would also be a "No Snakes" sign; after all, nobody likes snakes. And a "No Elephants" sign, because they break the chairs when they sit down.

The real reason that sign is there is historical: it is a historical marker that indicates that people used to try to bring their dogs into the restaurant.

Most prohibitive signs are there because the proprietors of an establishment were sick and tired of people doing x, so they made a sign asking them to please not. If you go into one of those fifty-year-old Ma-and-Pa diners like the Yankee Doodle in New Haven, the walls are covered with signs saying things like "Please don't put your knapsack on the counter"—more anthropological evidence that people used to put their knapsacks on the counter a lot. By the yellowing of the sign, you can figure out when knapsacks were popular among local students.

Sometimes it's a bit tricky to figure out the history behind the sign. "Please do not bring glass bottles into the park" must mean that somebody cut themselves stepping on broken glass while walking barefoot through the grass once. It's a good bet they sued the city, and now the city puts up signs.


Most signs, especially handwritten ones, are historical records.

Legal contracts contain archaeological artifacts, too. The reason legal agreements are so dang complicated and say dumb things like "worker, laborer, operative, roustabout, workhand, workingman, workman, artisan, craftsman, handicraftsman, mechanic, or employee" instead of just "worker" is because there was probably some lawsuit in 1873 where someone got out of a contract because he successfully argued in court that he was a roustabout, not a worker.

Software has a similar archaeological record, too: it's called the Options dialog. Pull up the Tools Options dialog box and you will see a history of the heated arguments that the software designers had about the design of the product. Should we automatically open the last file that the user was working on? Yes! No! There is a two-week debate, nobody wants to hurt anyone's feelings, the programmer puts in an #ifdef in self-defense while the designers fight it out. Eventually they just decide to make it an option. One more thing in Tools Options can't hurt, can it?

It doesn't even have to be a debate between two people: it can be an internal dilemma. "I just can't decide if we should optimize the database for size or optimize for speed." Either way, you wind up with things like what is unequivocally the most moronic "wizard" dialog in the history of the Windows operating system. This dialog is so stupid that it deserves some kind of award. A whole new category of award. It's the dialog that comes up when you try to find something in Help, as shown in Figure 3-3.


Options dialogs often become nothing more than a journal of the designer's indecision.


The most moronic wizard dialog Microsoft has ever shipped

The first problem with this dialog is that it's distracting. You are trying to find help in the help file. You do not, at that particular moment, give a hoot whether the database is small, big, customized, or chocolate-covered. In the meanwhile, this wicked, wicked dialog is giving you pedantic little lectures that it must create a list (or database). There are about three paragraphs there, most of which are completely confusing. There's the painfully awkward phrase "your help file(s)". You see, you may have one or more files. As if you cared at this point that there could be more than one. As if it made the slightest amount of difference. But the programmer who worked on that dialog was obviously distressed beyond belief at the possibility that there might be more than one help file(s) and it would be incorrect to say help file, now, wouldn't it?

Don't even get me started about how most people who want help are not the kinds of people who understand these kinds of arcana. Or that even advanced users, programmers with Ph.D.s in Computer Science who know all about full text indexes, would not be able to figure out just what the heck they are really being asked to choose from.

To add insult to injury, this isn't even a dialog... it's a wizard (the second page of which just says something like "thank you for submitting yourself to this needless waste of your time," to paraphrase). And it's pretty obvious that the designers had some idea as to which choice is best; after all, they've gone to the trouble of recommending one of the choices.

Which brings us to our second major rule of user interface design:

Every time you provide an option, you're
asking the user to make a decision.

Asking the user to make a decision isn't in itself a bad thing. Freedom of choice can be wonderful. People love to order espresso-based beverages at Starbucks because they get to make so many choices. Grande, half-caf, skim Mocha Valencia with whip. Extra hot!

The problem comes when you ask them to make a choice that they don't care about. In the case of help files, people are looking at the help file because they are having trouble accomplishing something they really want to accomplish, like making a birthday invitation. Their birthday invitation task has been unfortunately interrupted because they can't figure out how to print upside-down balloons, or whatever, so they go to the help file. Now, some annoying help-index-engine-programmer at Microsoft with an inflated idea of his own importance in the whole scheme of things has the audacity, the chutzpah, to interrupt this user once again and start teaching them things about making lists (or databases). This second level of interrupting is completely unrelated to birthday invitations, and it's simply guaranteed to perplex and eventually piss off the user.

And believe you me, users care about a lot fewer things than you might think. They are using your software to accomplish a task. They care about the task. If it's a graphics program, they probably want to be able to control every pixel to the finest level of detail. If it's a tool to build a Web site, you can bet that they are obsessive about getting the Web site to look exactly the way they want it to look.

They do not, however, care one whit if the program's own toolbar is on the top or the bottom of the window. They don't care how the help file is indexed. They don't care about a lot of things, and it is the designers' responsibility to make these choices for them so that they don't have to. It is the height of arrogance for a software designer to inflict a choice like this on the user simply because the designer couldn't think hard enough to decide which option is really better. (It's even worse when you try to cover up the fact that you're giving the user a difficult choice by converting it to a wizard, as the WinHelp people did. As if the user is a moron who needs to take a little two-step mini-course in the choice they are being offered so that they can make an educated decision.)

It has been said that design is the art of making choices. When you design a trash can for the corner, you have to make choices between conflicting requirements. It needs to be heavy so it won't blow away. It needs to be light so the trash collector can dump it out. It needs to be large so it can hold a lot of trash. It needs to be small so it doesn't get in peoples' way on the sidewalk. It needs to be open so people can throw trash in it. It needs to be closed so trash doesn't blow out on windy days.

When you are designing and you try to abdicate your responsibility by forcing the user to decide something, you're not doing your job. Someone else will make an easier program that accomplishes the same task with fewer intrusions, and most users will love it.

When Microsoft Excel 3.0 came out in 1990, it was the first Windows application to sport a new feature called a toolbar. It was a sensible feature, people liked it, and everybody copied it—to the point that it's unusual to see an application without one any more.

The toolbar was so successful that the Excel team did field research using a special version of the software which they distributed to a few friends; this version kept statistics on what the most frequently used commands were and reported them back to Microsoft. For the next version, they added a second row of toolbar buttons, this time containing the most frequently used commands. Great.

The trouble was, they never got around to disbanding the toolbar team, who didn't seem to know when to leave good enough alone. They wanted you to be able to customize your toolbar. They wanted you to be able to drag the toolbar anywhere on the screen. Then, they started to think about how the menu bar is really just a glorified toolbar with words instead of icons, so they let you drag the menu bar anywhere you wanted on the screen, too. Customizability on steroids. Problem: nobody cares! I've never met anyone who wants their menu bar anywhere except at the top of the window. But here's the (bad) joke: if you try to pull down the File menu and accidentally grab the menu bar a tiny bit too far to the left, you yank off the whole menu bar, dragging it to the only place you could not possibly want it to be: blocking the document you're working on as shown in Figure 3-4.


Miss the File menu by a couple of pixels and the whole menu bar comes flying off.

How many times have you seen that? And once you've done this by mistake, it's not clear what you did or how to fix it. So, here we have an option (moving the menu bar) that nobody wants (ok, maybe 0.1% of all humans want it) but which gets in the way for almost everybody.

One day a friend called me up. She was having trouble sending email. "Half the screen is grey," she said.

Half the screen is grey?

It took me five minutes over the phone to figure out what had happened. She had accidentally dragged the Windows toolbar to the right side of the screen, then accidentally widened it as shown in Figure 3-5.


Half the screen is grey.

This is the kind of thing that nobody does on purpose. And there are a lot of computer users out there who can't get themselves out of this kind of mess. Almost by definition, when you accidentally reconfigure one of the options in your program, you don't know how to re-reconfigure it. It's sort of shocking to see how many people uninstall and then reinstall their software when things start behaving wrong, because at least they know how to do that. (They've learned to uninstall first, because otherwise all the broken customizations are likely to just come back).

"But wait!" you say. "It's important to have options for advanced users who want to tweak their environments!" In reality, it's not as important as you think. This reminds me of when I tried to switch to a Dvorak keyboard. The trouble was, I don't use one computer. I use all kinds of computers. I use other people's computers. I use three computers fairly regularly at home and three at work. I use computers in the test lab at work. The trouble with customizing your environment is that it just doesn't propagate, so it's not even worth the trouble.

Most advanced users use several computers regularly; they upgrade their computer every couple of years, and they reinstall their operating system every three weeks. It's true that the first time they realized they could completely remap the keyboard in Word, they might have changed everything around to be more to their taste. But as soon as they upgraded to Windows 95, those settings were lost. Besides, they weren't the same at work. So eventually they just stopped reconfiguring things. I've asked a lot of my power user friends about this; hardly any of them do any customization other than the bare minimum necessary to make their system behave reasonably.

Every time you provide an option, you're asking the user to make a decision. This means that they will have to stop and think. That's not necessarily a bad thing, but in general, you should always try to minimize the number of decisions that people have to make.

This doesn't mean eliminate all choice. There are enough choices that users will have to make anyway: the way their document will look, the way their Web site will behave, or anything else that is integral to the work that the user is doing. In these areas, go crazy: it's great to give people choices; by all means, the more the merrier.

There's another category of choice that people seem to like: the ability to change the visual look of things without really changing the behavior. Everybody loves WinAmp skins; everybody sets their desktop background to a picture. Since the choice affects the visual look without affecting the way anything functions, and since users are completely free to ignore the choice and get their work done anyway, this is a good use of options.