home purpose join itg itg publication job bank itg listserv hf/Web conferences library

WORKSHOP Managing Errors in Transaction-based Web Applications Pawan Vora , pawan@nextag.com NexTag.com Following types of user-interaction errors are inevitable in transaction-based Web applications: Formatting Errors. e.g., numerical input when alphabetical input is required (and vice versa), length errors (either shorter or longer input than desired), date format errors, decimal errors, and so forth Missing information errors, where user misses to provide one or more items of required information Invalid information. e.g., incorrect user id and password match, missing "@" in e-mail, incorrect top-level domain names (.com, .org, .net) in e-mail, incorrect state code, and so forth. I do not want to suggest that the errors are result of "incorrect" user interaction only. Errors are often caused by the application itself -- because of "buggy" code, for example. In this workshop, I am not addressing those errors. I am focusing mainly on the errors caused by the user interaction with the Web-based application. Specifically, I will discuss: guidelines for preventing and/or minimizing some of the errors listed above; client- and server-side approaches of capturing errors; and design guidelines for communicating error messages to users. I. Guidelines for Preventing and/or Minimizing Errors To enhance user experience, it is important that the errors be prevented from occurring in the first place. There are some very simple ways you can minimize and/or prevent some of the errors listed above. Following the design guidelines below is the first step in that direction: 1. Clearly mark required information. Do not make users guess which information on your form is required and which is optional. It is quite common to identify the required information by an asterisk (*)-- usually in a salient color such as "red"; of course, it would also depend on the background color of the page. In addition, at the top of the form, indicate that the items marked with "*" are required. I have seen Web pages where either the label is marked as required (Figure 1a) or the field (or the control) is marked as required (Figure 1b). First Name:* Figure 1a. Labels are marked as "required" First Name: * Figure 1b. Fields are marked as "required" My recommendation is for 1a, because unless you have a page in which all the required fields are text fields, putting the * after a series of radio buttons or check boxes can be quite confusing. Also, because the user is likely to read the text first before entering the information, it is important that the user know whether the information is required or optional. 2. Clearly show any formatting requirements If you require date in mm/dd/yyyy format, let the user know that's what you want. No doubt, some users will miss this information, but you'd have prevented this error from happening for a majority of users. Here is one example: Birth Date: (mm/dd/yyyy) (Enter 10/06/1954 above, if your birth date is October 6, 1954) Alternatively, you can break-up the date field into multiple fields so that the users don't need to enter "/", like in the examples below. Birth Date: / / (mm/dd/yyyy) Birth Date: - Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec - 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 (e.g., 1967) Although I am tempted to give my opinion on which of the above is better, I'd like to take this opportunity to find out which design approach you believe is better and why. Send me an e-mail at pvora@mindspring.com to cast your vote including the rationale for your recommendation. I'll publish it in the next issue of Internetworking. 3. Use MAXLENGTH attribute for single-line fields If you wish to restrict the user to enter information beyond a certain length -- perhaps because of the length restrictions in the database -- the easiest way to prevent such errors is to use the MAXLENGTH attribute as follows: <INPUT TYPE="TEXT" NAME="FirstName" MAXLENGTH="35"> MAXLENGTH attribute restricts users to enter information any longer than specified. II. Client- and server-side approaches of capturing errors Essentially, there are two basic approaches to capture errors: on the client (browser) side and and on the server side. Client (or browser) side errors are identified on the Web page itself and no requests are made to the Web server. Whereas, for server side errors the processing necessary to identify the error is done on the server Most of the formatting errors and missing information errors on a Web page can be captured by scripting languages. Some of these errors are: Alphabetical information where numerical information is desired and vice versa Missing information in "required" fields Missing "@" in e-mail addresses Inputs exceeding the maximum length for memo (i.e. TEXTAREA) fields Extraneous information in user input such as "$" or "-" or spaces. The "extraneous information" errors often don't need to be communicated to the users, but such errors need to be corrected and the input "cleaned" before passing the information to the server. There are so many resources on the Web that offer both explanation and JavaScripts for doing one or more of the above that it doesn't make any sense for me to go into the details here. But, for those who are interested, please refer to the following sites: Data Validation Tips and Techniques, ZDNet DevHead column Using JavaScript Regular Expressions for Data Validation, ZDNet DevHead column JavaScript.com The JavaScript Source Clairvoyant JavaScript forms, Charity Kahn at C|Net Builder.com The errors captured using JavaScript are usually communicated using pop-up dialog boxes (using alert() function). So there's not much guidance that I can offer you except to emphasize the importance of clearly worded error message. Make sure that the error message you give to the user indicates both the error and action to be taken by the user to correct the error. Don't use a message that simply says: "Invalid Data." In general, capturing errors on the client side is advantageous from the user experience point of view because of quicker response time. If the Web server is involved in processing the page for identifying errors, response delays are inevitable. The delays are caused by the following: submitting the page to the server processing of the page by the server to capture the error(s) returning the "error" page back to the browser Although capturing errors on the client-side seem advantageous, you should be aware of two potential downsides: Need to use scripting languages (e.g., JavaScript), which may be either not supported or inadequately supported by some of the older browsers. Pop-up error dialog boxes are modal and have to be dismissed before correcting the errors. Users may forget what caused the error and may repeat the error. As I mentioned before, capturing errors on the server side is a little more expensive in terms of time delays. However, the main advantage is that you don't have to worry whether a browser supports the scripting language or not. III. Communicating error messages to the users Given the advantage of capturing errors on the server side, let's assume that you've decided to capture errors on the server-side. The design question that you'll face is how you'll communicate the errors to the users. Some of the common ways that I've seen errors being communicated to the users are: Showing a separate error page to the user and asking them to "go back" to correct error and "re-submit" the page. For example, Showing the error message at the top of the page identifying the errors and asking the users to correct them. For example, Showing the error message at the top of the page identifying the errors as in (2) above, but also "marking" the problem areas on the page with an icon or color or both. See the example below from Microsoft Expedia's Flight Price Matcher. My preference is for #3. Approach #1 requires users not only to click on the back button, but also to remember what caused the error. Consequently they're likely to repeat the error. Approach #2 overcomes the problem of requiring the user to "go back" and having the user remember the error situation. This works very well for shorter forms; on longer forms, users may have to search for the "error" areas. Approach #3 takes care of the problem with clearly identifying the problem areas. However, with icons and messaging, sometimes, they tend to clutter the page. One design solution is to identify the problem fields with a different font color, weight (bold), or font size. Finally, in addition to showing the error messages, for some "esoteric" errors that may leave the user confused (especially for logging in to the system), make sure that you include the e-mail or contact phone # where they can reach you. This is particularly important if you're running an eCommerce site. For example, Some message... If you're not sure what to do next, please send us an e-mail at myName@myCompany.com or call us at 1-800-xxx-xxxx. See the following example at Mindspring.com's login error page. The last two lines provide both the e-mail address and the customer service contact phone number: Do you have any comments on this workshop? Please let me know at pvora@mindspring.com. Also, in future issues of internetworking, I'd like to offer more guidelines for designing Web-based applications, especially for eCommerce applications. So, let me know the design issues you struggle with and depending on the interest, I'll try to compile a set of guidelines or best practices and share them with all the ITG readers. I am looking forward to hearing from you. © Internet Technical Group Last update: December 12, 1999 URL: http://www.sandia.gov/itg/newsletter/dec99/review_net_worth.html hosted by Sandia National Labs Disclaimer: Neither Sandia Corporation, the United States Government, nor any agency thereof, nor any of their employees makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately-owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by Sandia Corporation, the United States Government, or any agency thereof. The views and opinions expressed herein do not necessarily state or reflect those of Sandia Corporation, the United States Government or any agency thereof.