Auditing versus Editing

Many programmers believe that it is their duty to inform the user when he has made an error in entering data. It is certainly the program's duty to inform other programs when they make an error, but this rule shouldn't extend to users. The customer is always right, so the program must accept whatever the user tells it, regardless of what the program does or doesn't know. This is similar to the concept of data immunity because whatever the user enters should be acceptable, regardless of how incorrect the program believes it to be.

This doesn't mean that the program can wipe its hands and say, "All right, he doesn't want a life preserver, so I'll just let him drown." Just because the program must act as though the user is always right, this doesn't mean that the user actually is always right. Humans are always making mistakes, and your users are no exception. Users' errors may not be your program's fault, but they are its responsibility. How are you going to fix it?

AXIOM 

An error may not be your fault, but it's your responsibility.

The program can provide warnings—as long as they don't stop the proceedings with idiocy—but if the user chooses to do something suspect, the program can do nothing but accept the fact and work to protect the user from harm. Like a faithful guide, it must follow its master into the jungle, making sure to bring along an elephant gun and plenty of ammunition.

Warnings should use modeless techniques on the surface of the active window to inform the user of what he has done, much like the way the speedometer silently reports our speed violations. It is not reasonable, however, for the program to stop the proceedings with modal idiocy, just like it is not right for the speedometer to cut the gas when we edge above 65 miles per hour. Instead of an error message box, for example, edit fields can highlight any user input it evaluates as suspect.

When the user does something that the program is sure is wrong, there is only one way to protect him. If we edit his work without telling him, he will be proceeding into the jungle on false pretenses, so we cannot do that. If we edit his work and ensure that he knows about it, we will have to use an error message or a confirmation dialog box. This is also not acceptable. The only choice we have is to run along behind our brave user, making sure that he doesn't come to harm. We keep track of his path into the jungle; we remember each of his actions; we ensure that each action can be cleanly reversed; we ensure that no collateral information is lost and that the user can figure out where we think the problems might be. Essentially, we maintain a clear audit trail of his actions. Thus, the axiom: Audit, don't edit.

AXIOM 

Audit, don't edit.

If you can't manage entered data by using bounded controls, you must accept whatever the user gives you. Then keep track of what you did and didn't get, and if anybody demands that things get straightened out, you will have full records that will enable you to do so. You could, for example, make an internal note that the data wasn't quite right yet and make that information available to the user. The user can then judge whether the absence of the data will cause the planets to halt in their orbits. This means that the software should keep track of who, what, where, how, and when the user is doing things, so the situation can be modified, rectified, or just plain understood at some later date. This is much more human than merely forcing the data into some arbitrary format whose correctness is judged mostly on its compliance to a file schema rather than to a human need.

Microsoft Word has an excellent example of auditing, as well as a nasty counter-example. The excellent example is the way it handles spell checking: Little wavy underlines appear in the text as you type, identifying words that its spelling and grammar dictionaries don't recognize (see Figure 17-2). Right-clicking on these words pops up a menu of alternatives you can choose from—but you don't have to change anything, and you are not interrupted by dialogs or other modal idiocy.

Figure 17-2: Microsoft Word's automatic spelling checker audits misspelled words with a wavy red underline, providing modeless feedback to users. Right-clicking on an underlined word pops open a menu of possible alternatives to choose from.

Word's AutoCorrect feature, on the other hand, is a little bit disturbing at first. As you type, it silently changes words it thinks are misspelled. It turns out, however, that this feature is incredibly useful for fixing minor typos as you go. However, the corrections leave no audit trail, so the user has no idea that what he typed has been changed. It would be better if Word could provide some kind of mark that indicates it has made a correction on the off chance that it has miscorrected something (which becomes much more likely if you are, for instance, writing a technical paper heavy in specialized terminology and acronyms).

More frightening, however, is Microsoft's AutoFormat feature, which tries to interpret user behaviors like use of asterisks and numbers in text to automatically format numbered lists and other paragraph formats. When this works, it seems magical; but frequently the program does the wrong thing, and once it does so, the action is difficult to undo. The problem with AutoFormat is that the software is trying to be just a bit too smart; it should leave the thinking to the human. Luckily, this feature can be turned off.

In the real world, humans accept partially and incorrectly filled-in documents all the time. We make a mental (or otherwise) note to fix it later, and we usually do. If we forget, we fix it when we eventually discover the omission. Even if we never fix it, we somehow muddle through. Who said that these behaviors should be different for computer software than it is for humans? Programmers, that's who. They say they reject incomplete or inaccurate data for our own good, but actually they do so for their own good—so they don't have to write the more difficult code that deals with the unexpected. Humans don't die if they try to divide by zero, but computer programs do.