One of the early principles of GUI interfaces was that you shouldn't ask people to remember things that the computer could remember. In the really, really old days of command-line interfaces, if you wanted to open a file, you had to type its name (see Figure 11-1).
|Opening a file the command-line way. You have to remember that "xv" is the command that displays a picture, and you have to remember the file name.|
The classic example of not relying on people's memory is the Open File dialog box, which shows people a list of files rather than asking them to recall and type the exact file name. People remember things a lot better when they are given some clues, and they'd always rather choose something from a list than recall it from memory. See Figure 11-2.
|Opening a file the Windows way. You can choose the picture from a list of files.|
Things got even better when Windows 98 introduced thumbnails. Now you can see small versions of your pictures, which make it even easier to find the one you want, as shown in Figure 11-3.
Another example is the menus themselves. Historically, providing a complete menu of available commands replaced the old command-line interfaces where you had to memorize the commands you wanted to use. This is, fundamentally, the reason why command-line interfaces are simply not better than GUI interfaces, no matter what your UNIX friends tell you. Using a command-line interface is like having to learn the complete Korean language just to order food in the Seoul branch of McDonalds. Using a menu-based interface is like being able to point to the food you want and grunt and nod your head: it conveys the same information with no learning curve.
|Opening a file with thumbnails. This is a lot easier than remembering the names you gave to all of your files.|
You can also see the minimum-memory principle at work in features like autocompletion. When you need to type something, some programs make educated guesses about what you're about to type, as shown in Figure 11-4. In this example, as soon as you type
M, Excel guesses that you are likely to be typing
Male, because you've typed
Male before in this column and proposes that word as the autocompletion. But the
ale is preselected so that if you didn't mean to type
Male, you can continue typing (perhaps
ystery) and overwrite Excel's guess with no lost effort.
Microsoft Word gets a bit carried away in guessing what you are about to type, as anybody that has ever used this product during the merry month of May has discovered (see Figure 11-5).
One good way to test the usability of a program or dialog you've never seen before is to act a little stupid. Don't read the words on the dialog. Make random assumptions about what things do without verifying. Try to use the mouse with just one finger. (No, not that finger). Make lots of mistakes and generally thrash around. See if the program does what you want, or at least, gently guides you instead of blowing up. Be impatient. If you can't do what you want right away, give up. If the UI can't withstand your acting immature and stupid, it could use some work.
In the preceding chapters, I've brought up three principles:
- Users don't read stuff (Chapter 9).
- Users can't use the mouse (Chapter 10).
- Users can't remember anything (this chapter).
|Autocompletion taken too far|
"Joel," you say, "admit it. You just think that users are dolts. Why don't you just tell us to design programs for dolts and get on with our lives?"
But it's not true! Disrespecting users is how arrogant software like Microsoft Bob gets created (and dumped in the trash bin), and nobody is very happy.
Still, there is a much worse kind of arrogance in software design: the assumption that "my software is so damn cool, people are just going to have to warp their brains around it." This kind of chutzpah is pretty common in the free software world. Hey, Linux is free! If you're not smart enough to decipher it, you don't deserve to be using it!
Human aptitude tends towards the bell curve. Maybe 98% of your customers are smart enough to use a television set. About 70% of them can use Windows. 15% can use Linux. 1% can program. But only 0.1% of them can program in a language like C++. And only 0.01% of them can figure out Microsoft ATL programming.
The effect of this sharp drop-off is that whenever you "lower the bar" by even a small amount, making your program, say, 10% easier to use, you dramatically increase the number of people who can use it by, say, 50%.
I don't really believe that people are dolts, but I think that if you constantly try to design your program so that it's easy enough for dolts to use, you are going to make a popular, easy to use program that everybody likes. And you will be surprised by how seemingly small usability improvements translate into a lot more customers.