Web Bloopers: 60 Common Web Design Mistakes, and How to Avoid Them (Interactive Technologies)

Blooper 57: Unobtrusive Error Messages

The previous bloopers in this chapter are ways in which websites and Web-based applications make text-including error messages-difficult to read. At some websites , the legibility of error messages is overshadowed by a more serious problem: Users don't even notice messages. The most common reason for this is some combination of the following:

• Badly placed: off in a corner where people are not looking

• No error symbol: just text, no stop sign, large exclamation point, red X, or something of this sort

• Font too small and/or plain: message text that looks just like most other text on the page

• No blinking or movement: text that just appears, doing nothing extraordinary to get users' attention

Take, for example, the login page of a client's internal Web application. If the login information is invalid, the Login page reappears, displaying an error message (Figure 8.17). Can you spot the message? It's in the upper left corner of the page. The placement, size , and color of the message make it easy to miss . Users who mistype their PIN probably waste several seconds-or more-wondering why they are still at the login screen.

Figure 8.17: Client Web application (July 2002)-Error message is easy to miss. Can you spot it?

Citibank's online banking service displays error messages that are even easier to miss. For example, if a customer enters invalid data into their online bill-payment form, an error message is displayed (Figure 8.18). Can you find it? Hint: It isn't even on the Web page. It's in the browser's status bar, on the left, in a small, plain font. The message is not very helpful: "Error on page."

Figure 8.18: www.Citibank.com (Jan. 2002)-Error message is very easy to miss. Can you spot it? It's also not very informative.

A few bloopers back, I showed an example from Russell Stover's old website of poor color contrast between text and background. I didn't say where that hard-to-read registration-error message appeared. It appeared at the top of the form, at the left edge of the page. Figure 8.19 shows the registration form with and without the error message. It might seem reasonable to display error messages in that position, but a user looking at the Submit button or the form fields might miss the poorly contrasting message text.

Figure 8.19: www.RussellStover.com (Feb. 2001)- A- Registration form. (b) Form with error message.

If the message appeared in this position in a larger font, a color that contrasted better with the background, or inside a box with a different background color and an error symbol, it probably would be sufficiently noticeable. However, in this position, with such poor contrast, I'm sure many visitors to this site initially overlooked the message and wondered why the Submit button just redisplayed the form.

Avoiding the Blooper

Before I explain how to present error messages that users will notice easily, let's look at a site that does it well. The website of Recreational Equipment has a multipart form for ordering merchandise (Figure 8.20[A]). When customers try to submit the form with invalid data, it is redisplayed with error messages (Figure 8.20[B]), as in the preceding examples. However, the error messages are displayed in red in a separate section that is hard to overlook. Furthermore, the erroneous data fields are highlighted in red and marked with asterisks . No one could miss this.

Figure 8.20: www.REI.com (Nov. 2000)- A- Billing Address specification form. (b) Same form with error messages listed and highlighted.

Let's consider what is wrong with the error messages displayed by Russell Stover (see Figure 8.9) and the internal web application (see Figure 8.17). Both put the message at the upper left of the Web page. That might seem a good place for error messages. There is a fairly well-known design rule for graphical user interfaces (GUIs) that important data and settings should be placed at the upper left of a window (Johnson, 2000).

However, that rule doesn't apply to error messages on Web pages, for the following reasons:

• When a Web browser displays a page, the page content is not the top of the window. It is below the browser controls. Items at the extreme top left of a Web page can be "buried" by the clutter of the browser controls and by elements on the Web page.

• The GUI rule concerns where users usually look first when a window appears. But the error messages we are discussing are displayed on the same page the user has just finished filling out and submitting. By the time users submit the form, they are not looking at the top left; they're looking at the Submit button or the form itself.

When the page redisplays showing the form again, users might not see an error message in the upper left. Instead, they wonder why they didn't move on to the next step.

The aforementioned internal Web application's Login page could be improved by moving the error message closer to where users would be looking and marking the fields that need to be reentered. Even though only the PIN was invalid, the system requires users to reenter both items for security reasons. I therefore put the error message next to the ID field and highlighted both data fields (Figure 8.21).

Figure 8.21: Correction of blooper in Client Web application-Message appears near fields that must be retyped, in large red font, and the fields are highlighted.

To correct the blooper at RussellStover.com, I shortened the error message and put it next to the offending data field (Figure 8.22). I also highlighted the field to be reentered.

Figure 8.22: Correction of blooper at www.RussellStover.com -Message is next to relevant data field and data field is highlighted. Message is also less verbose and has better color contrast.

Guidelines for Attracting Attention to Error Messages

Having seen examples of avoiding and correcting the blooper, we can now consider guidelines for ensuring that users notice error messages on Web pages:

• Put where users are looking. Human peripheral vision is poor and gets poorer with age. Try to put the error message near where users were probably looking when the error was detected .

• Put near the error. If the error is in a specific field or control on the page, place the message near there.

• Use red. Red traditionally indicates something is wrong and so is a good color in which to say, "Error!"

• Use error symbol. If possible, start every error message with a symbol that signifies an error. Common error symbols are a big red X, a stop sign, or a large exclamation point.

Those are the normal techniques for making error messages noticeable. Sometimes however you need the "heavy artillery ": techniques borrowed from desktop software (Johnson, 2000) that can make error messages nearly impossible to ignore:

• Beep. Emit a brief sound to let users know something is amiss. It's obviously best to use the standard "error" sound for the users' platform.

• Flash or wiggle briefly . Human peripheral vision for stationery objects is very poor. However, because humankind evolved in an environment in which we had to avoid predators, peripheral vision is very good at noticing anything that changes or moves. Automatically and quickly, we look directly at whatever drew our attention. Thus, flashing and animation can be used to draw attention to error messages. However, both flashing and animation are distracting and annoying if continuous and so should always be stopped after a half a second or so. If you can't stop them, don't use them.

• Use dialog box. Error messages can be displayed in dialog boxes, which are small windows that pop out of the browser and get "in the users' face." These can be either true dialog boxes or they can be small browser windows displayed without browser controls.

These desktop software techniques are effective but are rarely feasible in websites. They are more common in Web applications, which in many ways resemble desktop applications.