MLI Home → Writings → Tech Notes → A Frustrating Error Message

A Frustrating Error Message

As of this writing (April 2002), the Interface Hall of Shame hasn't been updated in almost two years, alas. I've got a candidate for it, although I'm not sure which section to propose it for (either "Error Messages" or "Interface Stupidity"). Perhaps you can help me decide.

Normally, I wouldn't spend an entire page on one error message, but this particular one illustrates an important point about user interface design.

The Problem

Lotus' Word Pro Release 9 is my preferred word processor for documents I plan to print. However, printing can be a headache due to my old and cranky printer, which often misprints pages. This leads to the following scenario:

1. I print the document. Pages 2 and 4 print incorrectly and must be reprinted.

2. In Word Pro's Print dialog box, I tab to Pages from: __ to: __.

3. I enter 2, tab to the next box, enter 2, then press the Print button.

   

4. Page 2 prints correctly.

5. I bring up the Print dialog box again, and again tab to Pages from: __ to: __.

6. In the first box I enter 4.

   

7. I hit the tab key to advance to the next box to enter 4.

8. Up pops a dialog box with an error:

   

Word Pro will not let you progress to the next input box unless the number in the from: box is less than or equal to the number in the to: box. (Never mind that the next thing I was going to do was to change the to: box!) Even though the print range needs to be evaluated for correctness only when the user presses the Print button, the program always check the validity of the from: & to: boxes after either is modified. This technique prevents the program from entering an inconsistent state[1], but it makes using the program needlessly frustrating. Until the number is fixed, clicking on anything other than the Cancel button or the dialog box's cancel box pops up the same annoying message. (Pressing the pop-up message's Help button is unhelpful, as it does... nothing. Pressing the OK button dismisses the pop-up.)

So I end up tabbing first to the to: field, changing it, shift-tabbing backward to the from:, and then changing that value. It's an awkward and frustrating dance called "program appeasement".[2]

(There's another problem with this error: the message. If Word Pro is smart enough to tell me I should enter a number between 1 and 2, why can't it figure out whether 4 is too large or too small? Answer: the programmer was lazy. Also, since the user can't do anything until either field is changed, shouldn't the error have a "warning" icon instead of an "information" icon?)

Solutions

There are two solutions to this problem.

• Postpone validity checking until an action that requires that input data be consistent is taken. In this case, postpone validity checking until the user presses the Print button. If the data isn't consistent, pop up a dialog box that explains the problem and shows the user how to fix it.

• Check validity after each field is modified, but instead of popping up a modal dialog box with an error message, flag inconsistent fields:

  

  If the user fixes either of the fields, both warning flags should disappear (since it is the combination of their values that is inconsistent, not either's value considered alone). If the user presses the Print button while the fields are still inconsistent, or clicks on either warning flag, Word Pro should display a useful message that (a) describes the problem, (b) shows how to fix it, and (c) offers an "about the warning flag" button that leads to more help (i.e., warning flags indicate a problem that can be ignored temporarily, but must be fixed before the current operation can be completed).

The general problem that this particular error illustrates is overzealous data consistency checking. Until the user wants to do something with that data, there's no need to force it to be consistent. For example, if the user decides to not to print the document after all, the consistency of the page range makes no difference. Enforcing consistency at all times makes users less productive, not more. Check consistency only when an action requires it.

Notes

1. At first I wanted to note that leaving data in an inconsistent state, even temporarily, is poor programming practice. A few moments' consideration convinced me that this notion is completely wrong. Users don't care whether data is temporarily inconsistent, as long as they can correct it when they need to, not when it's convenient for the programmer. Users shouldn't be forced to type a single extra keystroke, or click the mouse button even once, to satisfy a constraint that only programmers (and not even good programmers, at that!) care about.

2. You might be asking yourself why I don't reprint pages in descending order. The answer is that the scenario above is actually a simplification of how I print, which is usually a page at a time. I'll often be checking one page for errors while the next prints. If I find an error, my first reaction is to reprint the page. However, at this point I'm on page n, and need to print page n-1 again. When I try to print a later page, the problem occurs.

(For the record, I don't advocate the use of MS Windows' standard exclamation-point-on-yellow-triangle warning icon to flag fields in an inconsistent state. I just needed an icon to demonstrate the concept, and that one happened to convey the intended warning reasonably well.)

---

Previous: Raising the Bar on Email ··· Next: CSS Tip #1: A Navigation Bar that Degrades Gracefully

MLI Home → Writings → Tech Notes → A Frustrating Error Message