Stopping the Proceedings

There is a particular form of excise that is so prevalent that it deserves special attention. In Chapter 9, we introduced the concept of flow, where the user enters a highly productive mental state by working in harmony with his tools. Flow is a natural state, and people will enter it without much prodding. It takes some effort to break into flow after someone has achieved it. Interruptions like a ringing telephone will do it, as will an error message box. Some interruptions are unavoidable, but most others are easily dispensable. But interrupting a user's flow for no good reason is stopping the proceedings with idiocy and is one of the most disruptive forms of excise.

AXIOM 

Don't stop the proceedings with idiocy.

Poorly designed software will make assertions that no self-respecting individual would ever make. It states unequivocally, for example, that a file doesn't exist merely because it is too stupid to look for it in the right place, and then it implicitly blame you for losing it! A program cheerfully executes an impossible query that hangs up your system until you decide to reboot. Users view such software behavior as idiocy, and with just cause.

Errors, notifiers, and confirmation messages

There are probably no more prevalent excise elements than error message and confirmation message dialogs. These are so ubiquitous that eradicating them takes a lot of work. In Part VII, we discuss these issues at length, but for now, suffice it to say that they are high in excise and should be eliminated from your applications whenever possible.

The typical error message box is unnecessary. It either tells the user something that he doesn't care about or demands that he fix some situation that the program can and should usually fix just as well. Figure 10-1 shows an error message box displayed by Adobe Illustrator 6 while the user is trying to save a document. We're not exactly sure what it's trying to tell us, but it sounds dire.

Figure 10-1: This is an ugly, useless error message box that stops the proceedings with idiocy. We can't verify or identify what it tells us, and it gives us no options for responding other than to admit our own culpability with the OK button. This message only comes up when the program is saving; that is, when we have entrusted it to do something simple and straightforward for us. The program can't even save a file without help, and it won't even tell us what help it needs.

The message stops an already annoying and time-consuming procedure, making it take even longer. The user cannot reliably fetch a cup of coffee after telling the program to save his artwork, because he might return only to see the function incomplete and the program mindlessly holding up the process. We'll discuss how to eliminate these sorts of error messages in Chapter 33.

Another frustrating example, this time from Microsoft Outlook, is shown in Figure 10-2. This dialog is asking us to make an irreversible and potentially costly decision based on no information whatsoever! If the dialog occurs just after you changed some rules, doesn't it stand to reason that you want to keep them? And if you don't, wouldn't you like a bit more information, like exactly what rules are in conflict and which of them are the more recently created? We also don't have a clear idea what happens when we press Cancel …. Are we canceling the dialog and leaving the rules mismatched? Are we discarding recent changes that led to the mismatch? The kind of fear and uncertainty that this poorly designed interaction arouses in users is completely unnecessary. We discuss how to improve this kind of situation in Chapter 34.

Figure 10-2: Here is a horrible confirmation box that stops the proceedings with idiocy. If the program is smart enough to detect the difference, why can't it correct the problem itself? The options the dialog gives us are scary. It is telling us that we can explode one of two boxes: one contains garbage, and the other contains the family dog — but the program won't say which is which. And if we click Cancel, what does that mean? Will it still go ahead and explode our dog?

Making the user ask permission

Back in the days of command lines and character-based menus, interfaces often offered services to the user indirectly. If you wanted to change an item, such as your address, you had to first ask the program permission to change it. The program would then display a screen where your address could be changed. Asking permission is pure excise. If you want to change a displayed value, you should be able to change it right there. You shouldn't have to ask permission or go to a different room.

AXIOM 

Never make the user ask permission.

Many file selection dialogs do this. They show you the proposed directory, but if you don't like the choice shown, you can't just change it in place. You instead click a button that says Browse, and then get another dialog box in which to change it. This is unnecessary. The dialog could easily track those changes, verify their validity, and assure that things get installed correctly without forcing the user to ask permission.

AXIOM 

Allow input wherever you have output.

As in the last example, many programs have one place where the values (such as filenames, numeric values, and selected options) are displayed for output and another place where input to them is accepted from the user. This follows the implementation model, which treats input and output as different processes. The user's mental model, however, doesn't recognize a difference. He thinks, "There is the number. I'll just click on it and enter a new value." If the program can't accommodate this impulse, it is needlessly inserting excise into the interface. If options are modifiable by the user, he should be able to do so right where the program displays them.

The opposite of asking permission can be useful in certain circumstances. Rather than asking the program to launch a dialog, the user tells a dialog to go away and not come back again. In this way, a user can make an unhelpful dialog box stop badgering him, even though the program mistakenly thinks it is helping. Microsoft now makes heavy use of this idiom. (If a beginner inadvertently dismisses a dialog box and can't figure out how to get it back, he may benefit from another easy-to-identify safety-net idiom in a prominent place: a Help menu item saying, "Bring back all dismissed dialogs," for example.)

Protecting us from ourselves

Another place where the proceedings are regularly stopped with idiocy is in password protection systems. Security is an important issue in a professional environment, but it doesn't mean much to Grandma and the PC she uses for Web surfing. Passwords aren't appropriate for everyone or in all contexts, and there should be ways to turn them off when they simply get in the way.

Unresponsiveness

A program can become slow or unresponsive when it talks to remote devices like servers, printers, networks, and modems, or when it performs a large amount of local processing on large data structures. Every program that executes potentially time-consuming tasks must make sure that it occasionally checks to see if the user is still out there, banging away on the keyboard or madly clicking on the mouse, whimpering "No, no, I didn't mean to reorganize the entire database. That will take 4.3 million years!"