Common error messages
These computer-related error messages can occur in almost any program.
* File not found occurs when the requested file cannot be found. The file may have been damaged, moved, deleted, or a bug may have caused the error.
* The device is not ready most often occurs when there is no floppy disk (or a bad disk) in the disk drive and the system tries to perform tasks involving the floppy disk.
* Access is denied occurs if the user has insufficient privileges to a file, or if it has been locked by some program or user.
* Out of memory occurs when the system has run out of memory or tries to load a file too large to store in RAM. The fix is to close some programs or get more memory.
* Low Disk Space occurs when the hard drive is full. To fix this, close some programs (to free swap file usage) and delete some files (normally temporary files, or other files after they have been backed up), or get a bigger hard drive.
* [program name] has encountered a problem and needs to close. We are sorry for the inconvenience. Windows XP message displayed when a program causes a general protection fault or invalid page fault.
* The blue screen of death.
Error message usability checklist
To be effective, an error message must contain the following information:
* Message ID - For many applications, a reference number for the error is an invaluable piece of information. This number will help network support personnel to easily diagnose the error and possible courses of action. An index also serves as a universally understood indicator of an error in situations where various languages are used.
* Timestamp - The date and time of the onset of an error should be displayed so that the help centre can correlate the event to log files with the same timestamp.
* Message type and severity - Classify the error as either an automatically recoverable error, manually recoverable error, or non-recoverable error, or some other appropriate label. Inform the user about the level of severity, and tell the user about the possible consequences of the exception.
* User and process details - Display information that identifies the user who “triggered” the error in the form of a user ID or whatever system is used to identify users for the specific system. The process or task that the system was trying to perform should also be documented in case users have multiple applications running and are not sure which one caused the error. This information is important in diagnosing errors from a helpdesk perspective.
* Short message with details button - The displayed message should be clear and concise, in "novice user" language. It should contain the reference number and the basic information regarding the type of error, severity, and corrective action. There should also be a details button which shows an advanced user more information about the specifics of the error. The details button can also be used to explain corrective actions to the user.
* Program state and configuration - Show information about the error that is relevant to the user. For example, if the user entered an invalid value in a field, the error message should tell the user which field caused the error and what the invalid values were. Showing current program field values and applicable configuration information in the message will allow the user to deduce the cause of the error and correct it. If a piece of hardware is not configured properly, the current configuration can point the user to the real problem. For example, if you have the wrong printer set as your default, the error message should show which printer is currently set to default so the user can clearly see that there is a problem. i.e. "Printer Epson 123A not ready" instead of "Printer not ready".
Message format
The format for error messages is not static. The format of error messages is dependent on many things, however the three main factors that influence the format design are as follows.
Technical limitations
The strengths and restrictions of the technology you're working with should be among the first things you take into account when planning error messages. You must be careful to ensure that the medium you use to communicate the error supports the size, shape, and style of your error message.
Amount of information presented
The nature of the error message will determine the amount of information required for the error message. If the error message is short –"Sorry, our Web site is currently undergoing maintenance, Please try again later." it may be more effective as a pop-up window than as a separately loaded page. This is because short messages can easily be drowned out if there is other content on the page. If there is no other content on the error message page, then the short error message will look out of place on a big empty page.
User input required
Finally, you should choose an error message format based on the type of input you require from the user to correct a problem. Errors that simply inform the user of a problem that they can’t fix, such as a busy server on a website, are best suited to pop ups. In this situation, all you need to do is inform the user of the problem, as no corrective action aside from trying again later. The only control available to the user should be the “Ok” button. However, controls such as “Retry/OK” and “Cancel” should be used if the user is being prompted to corrective action. For example, “Windows encountered an error and needs to restart. Would you like to restart now?” should include an option to cancel and to restart. The buttons should correspond to the available options, i.e. “Restart now” button vs. “OK”, and “Later” vs. “Cancel”. This makes the options clearer to the user and thereby being conducive to correct decision making.
Presentation guidelines
The presentation and appearance of error messages are critical factors that heavily influence how well a user comprehends and responds to an error message. The following three principles should be adhered to when designing an error message.
Capture the user's attention
The visual attributes of an error message, including its color, size, and location can and should be used to grab the user’s attention and inform them that an error has occurred. Usually, the color red, a bold font, and the location at the top of the page and in front of any other window are good ways to allow the user to know that an error is present. In addition, an exclamation point is often used as an iconographic symbol to express importance.
Explain what went wrong
To effectively communicate with users, the application must speak their language. Messages must explain what the problem is using terminology that even a novice user can understand. The key idea here is to explain what went wrong, not just tell the user an error code. This is not to say to never include error codes in the error message. Instead, explain it in the proper context if it could prove useful. For example, an error message could reference error code 3555 and display the message “Please contact our help desk and reference error code 3555 for assistance”.
Show where error occurred and suggest possible solutions
Pointing users to solutions can be accomplished many ways. The language used is an important factor in getting users to understand what went wrong and consequently, how to fix it. For example, a poor error message might read, "You have entered an invalid string character in Field 123A". A better error message reads, "The zip code field contains an invalid character. Only numbers may be entered". Novice users won’t know what a string character or field 123A is, but they will recognize what the zip code field and “numbers” are.
Additionally, you can show the user exactly where the problem occurred by providing visual cues such as highlighting the field label with color, font treatment, and iconographic images.
Once an error is located, instructions should be given to the user on corrective action, once again explained in the users’ language.
Providing examples of acceptable input is also a powerful technique for suggesting solutions for certain types of errors.
Design heuristics
The following is a general set of guidelines to aid in the effective design of error messages. There are many more that can be found in many different texts and this list is by no means absolute. Those included below are only a few of the commonly accepted heuristics.
* Do provide useful information that helps the user diagnose the problem - i.e. Use “Link target does not exist” instead of “Bad link”.
* Do be precise - i.e. “Missing file name extension” instead of “File not found.”
* Do describe the problem - i.e. “Disk full” instead of “File error.”
* Do use a neutral tone - i.e. Change the tone in “Bad input” to “Command is unrecognizable.” to avoid blaming the user.
* Do use complete sentences - i.e. Use “Binding is too long.” rather than “Binding too long.”
* Do not personify the system, unless you mean to convey a sense of naturalness - i.e. “Node parameter cannot use Windows NT protocols.” is better than “Parameter node does not speak any of our protocols.”
* Avoid displaying an error message at all, if possible, i.e. disable the Paste option if no data is on the clipboard, instead of showing an error like “No data on clipboard” when the user attempts a paste operation.
Different Messagebox symbols:
No comments:
Post a Comment