One of usability guru Jakob Nielsen's top ten usability heuristics is "Error Prevention: Even better than a good error message is a careful design which prevents a problem from occurring in the first place." Sure, in Nielsen's perfect world of blue and purple links, I can agree with that. But in the real world, errors happen and they must be dealt with. By understanding the context in which errors frequently occur, developers can best design an application's resulting error interactions and visual feedback to help the user resolve the errors. A coordinated error handling strategy incorporating both client- and server-side solutions can best maintain the integrity of the application processing while most efficiently guiding the user through the error resolution and back to the primary workflow. In this article, we'll look at practical tips that can help you integrate such error handling strategies into your own Web-based applications.
Until a breakthrough is made in artificial intelligence, applications continue to require that the user interact with them in a fairly well defined manner. For each application, the user must communicate within a finite set of valid interactions. Any interaction outside that set results in an error.
Applications should offer as much latitude as possible to the user. For example, the standard date format might be DD/MM/YYYY, but the user should be able to use formats like DD-MM-YYYY or DDMMYYYY. As long as the application can resolve the input to a unique valid value, it should accept the input; you don't need to completely bind the human user to the application's preferred format. Nevertheless, an application's digital processing can only go so far to meet the analog thinking of users.
Unfortunately (well, I guess in the grand scheme, fortunately), human users are not naturally bound to a fixed set of interactions. Offer users three checkboxes to select and they will eventually select all seven possible combinations, regardless of which combinations the system deems valid. Until applications operate more in the way of human thinking, or humans are programmed along the lines in which applications are developed, you are stuck with this fundamental schism in computer-human communication. Users will continue to trigger application errors for the foreseeable future.
Oh, and did I fail to mention that errors can also result from applications that just go up in smoke? Does the dreaded 500 Internal Server Error ring a bell?
Something went wrong, now fix it!
The worst error messages are those that do not exist. Even a bad error message is better than none at all. But an error message needs a few basic components to be effective. When a user's interaction results in an error , a well-designed application conveys three components of error handling:
- Sound the alarm: Capture the user's attention. Something went wrong.
- Here's the skinny: Explain what went wrong.
- Try this: Suggest possible solutions and show the user where the problem is located.
The visual design attributes of an error message -- its color, size, and location -- can clearly distinguish it from the rest of the application's user interface and capture the user's attention. The color red, bold font, and a location at the top of a page are commonly recognized as standard attributes for error messages. In addition, an exclamation point is often used as an iconographic symbol to express importance. The error message in Figure 1 illustrates all of these attributes.
Figure 1. Error Message
Once you've captured the user's attention with these visual cues, the message must clearly and succinctly describe the problem that caused the error. Both what you say and how you say it are also important.
To effectively communicate with users, the application must speak their language. The application and the user are two very different entities; as such, translation must take place to make communication between the two effective. The application knows that something went wrong; it must convey this fact to the user. Unfortunately, error messages that attempt to convey such information are often puzzling, composed of incomplete sentences and a few cryptic codes. As you read such a message, you may find yourself imagining it recited in the voice of a robot. Because the primary audience of an error message is the non-technical end user, translate the message from robo/code/techno/geek talk to plain English.
This is not to say to never include information such as error codes in the error message. Instead, if such information might prove useful for error resolution, explain it in the proper context. (For example, the user might refer to an error code when seeking assistance from a technical manual or help desk.) Rather than simply proclaiming "ERROR 6534," the error message can explain, "Please reference error number 6534 if you address this problem with the help desk at extension 555."
The error message clearly and succinctly explains what went wrong, how to fix it, and not leave the user guessing. Politeness goes a long way in an error message. Do not blame the user. Make the error message objective, stating what the problem is. For example, a poor error message might read, "You have entered an exception alpha character in Field 123A". A better error message reads, "The zip code field contains an invalid character. Only numbers may be entered. An example of a valid zip code is 90210."
By exploiting the interactive nature of an application, you can show exactly where the problem occurred. Highlighting the field label and/or the field in error with visual cues such as color, font treatment, and iconographic images is most effective. Listing 1 shows how to cleanly implement this with CSS. Even more effective is to link the respective error message to a page anchor located at the field in error and set the focus to that field, as shown in Listing 2.
Listing 1. Highlight errors with CSS classes
<!-- CSS classes -->
.errorLabel {
color: red;
font-weight: bold;
}
.errorField {
border: 1px solid red;
}
<!-- Applying the CSS classes to field labels and fields -->
<td class="errorLabel">Zip Code:</td>
<td><input name="zipCode" type="text" class="errorField" /></td>
|
Listing 2. Link an error message to a specific field
<!-- Error Message Text --> The <a href="#zipCode">zip code</a> field contains an invalid character. Only numbers may be entered. An example of a valid zip code is 90210. <!-- Error Field --> <td><a name="zipCode">Zip Code:</a></td> <td><input name="zipCode" type="text" /></td> |
More advanced error messages can offer enhanced functionality by providing additional tiered information, such as direct links to applicable Help system modules and the incorporation of glossary definitions for key terms (such as field names) displayed on mouseover. Mouseover help is illustrated in Listing 3 and Figure 2.
Listing 3. Add additional information displayed on mouseover using the <title> tag
<!-- Error Message Text --> The <a href="#zipCode" title="A zip code is a code of digits added to a postal address to aid in the sorting of mail. Zip code must be entered as 5 digits."> zip code</a> field contains an invalid character. Only numbers may be entered. An example of a valid zip code is 90210. |
Figure 2. Additional information set with <title> tag
Leverage both client- and server-side error handling
Now you know that when an error occurs, the application must clearly and succinctly explain to the user what went wrong, where the error occurred, and how to fix it. But, you can't overlook a key element in an error response strategy -- when an error occurs. With most Web applications, the when often defaults to the moment when the user submits the offending page to the server. Constraining error responses in such a manner can make for a sub-optimal user experience.
Several factors come into play as you consider when to provide error messages. The two primary response periods are: after a page has been submitted, and immediately after user focus leaves a field. Server-side validation normally addresses the former, while client-side validation addresses the latter. A mix of these solutions provides the best of both.
When validation takes places immediately after user focus leaves a field, you save the user time by sparing a round trip to the server. If the user enters an invalid piece of data, the application can immediately prompt the user to correct it before he submits the page. If your application uses server-side error validation alone, an extra server trip is required, with a time cost of three to six seconds. Across many data elements, this delay can add up.
Immediate validation can also help the user address the problem. Because the application immediately throws an error response, the user can more readily fix the problem before his focus moves to another field. For example, if the user just entered a zip code that he read off of a multi-page printed form, but mistakenly entered six digits instead of five, he can quickly look back to the printed form and correct the problem. Because the error is caught immediately, the user does not have to regain his bearings and find the information that needs to be corrected on both the application screen and the printed form.
Client-side validation is least useful in a situation of high-volume data entry. In such a case, client-side validation is disruptive to a highly repetitive, streamlined work mode. In this instance, keep validation strictly on the server side.
Because you can only bring limited logic to the user's computer, client-side validation does have its limitations. Set a reasonable limit on the amount of data that you require the user to download based on your user base's connection metric (for example, dialup, high-speed, and so on). Complex conditional validation usually requires server-side validation because of the amount of code necessary to perform it. For instance, if the validity of entered data depends on previously entered data that is based on specific business rules, that may be too much logic for the client side to handle. As long as you place all of your client side validation code in one external .js file, the user only needs to download this file once. After the initial download, the client machine usually caches the file. Some suitable candidates for client-side validation of basic formatting are date, zip code, social security number, phone, fax, credit card number, and e-mail fields. High-level blanket validations, such those that check for alpha or numeric characters, field length, and invalid symbols, are also common.
Security is another critical consideration. Anything that your application places locally on the client is not secure. If your app needs to do any validation behind closed doors, never do it on the client side. Also, users might hack their own custom page to submit data that bypasses all client-side validation, so you can't necessarily depend on it.
Client-side validation can provide an improved user experience. To provide a complete and secure check, plan for all validation to take place on the server side. Think of it as having a security guard at a gated community along with your own home security system. The security guard (client-side validation) is nice to have, provides a sense of security, and provides some additional help (like giving directions), but you would not want to rely solely on him for your security needs. Your personal home security system (server-side validation) is the actual provider of your ultimate security.
You can enhance the user experience with client-side validation, while server-side validation provides the true maintenance of the application's inputted data integrity. While both validate inputted data, they address two wholly unique issues. Client-side validation provides a more efficient way for users to recover from basic data entry mistakes. Server-side validation is the ultimate check to make sure that the data is valid. Regardless of how your application catches an error, the important thing is to clearly notify the users of the error, explain what went wrong, and help them to fix it. As Confucius said, "Be not ashamed of mistakes and thus make them crimes" -- but build Web applications with which your users can at least easily fix those mistakes."
- Catch some concepts behind data validation on EJB-based systems, and how to avoid unexpected or incomprehensible error messages, in "EJB best practices: The fine points of data validation" by Brett McLaughlin (developerWorks, December 2002).
- Join Jakob Nielsen as he explains how to improve the 404 error message (useit.com, April 1999), in his Alertbox column.
- Browse all of the Ask Eric questions and answers of Dr. Eric Schaffer at Human Factors International.
- For a good laugh (and to learn how not to write error messages), check out the Microsoft Crash Gallery, chock full of screenshots and photos.
- Get a good overview of client-side validation in "Form validation on the client side" by Martin Tsachev (Sitepoint, September 2002).
- Read about JSP page error handling at the WebSphere® Software Information Center.
- Learn about error handling facilities of the graPHIGS API at the IBM® eServer AIX® Information Center.
- Visit the developerWorks Web
Architecture zone for articles and tutorials that specialize various Web-based solutions.
- Browse for books on these and other technical topics.
Padilla is a user experience design director for Web applications in Philadelphia, where he oversees everything from information architecture to branding integration to rich client UI architecture. Mike has led front-end development efforts for such companies as Fleet Credit Cards, Mellon Private Asset Management, the Bank of New York, and Bessemer Trust. Macromedia has featured his usability designs. He received a B.S. in mechanical engineering, focusing on ergonomics, from Cornell University.
