When Things Go Bad... - Practices

Next up, error messages, one of the most important components to considerwhen creating interface text, purely because of its potential to unnervethe user.

A well-written error message should cover three bases:

• What happened?
• What is the result?
• What does the user need to do?

You will usually have two kinds of errors - validation errors and exceptions.

Validation errors occur due to incorrect data entry by the user, andtherefore, the error message needs to essentially point out the input fieldwhere the error occurred and how to correct it. In an online expense claimsystem, for example, if a user enters an amount claim that exceeds histotal permissible expenses, a validation error would occur, and thefollowing message would be generated: "Your expense claim cannot be greaterthan your total permissible claim. Please re-enter your expense claim."

An exception, on the other hand, occurs due to a back-end problem - forexample, the database has missing data or a resource cannot be found.Typically, these are internal errors beyond the control of the user, andthe error message should reflect this, essentially asking the user tocontact a more technically-astute administrator to identify and rectify theproblem.

Some things to keep in mind with respect to exception messages:

• The message should specify whether the changes made have been reset andthe user needs to enter them again or simply use the "Submit" or "Save"commands to register the changes.
  
  
• Avoid letting the system code for the errors appear on screen. And alsoavoid using exclamations in error messages - "Oops! You screwed up!!!!" isdefinitely not a good error message to see in an application.
  
  
• The user need not be informed of any back-end processes that are causingthe error. In case there is nothing more the users can do, ask them tocontact the administrator.
  
  

You can be more professional in your design of error messages by creating asingle database of generic error messages, and reusing them in yourapplication - for example, "<field> contains data of incorrect type", where<field> is a variable that is automatically replaced with an actual fieldname by the program. The benefit here is that you have a single database oferror messages, and can immediately enforce a consistent style across theentire application.

Your other option is to write specific messages, like the message for claimexpenses above. You will need to write these for validations that are *not*common across the application. In practice, you will nearly always end upwith a combination of these two approaches. The thing to be sensitive tohere is that you should not have an overlap between the two approaches -that is, you should not be writing a specific message for a situation wherethe generic one will suffice.

>>> More Practices Articles          >>> More By Deepa L, (c) Melonfire

blog comments powered by Disqus