Error Messages In Software Applications


Published on

A PowerPoint presentation about error messages in software applications

Published in: Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Error Messages In Software Applications

  1. 1. Error Messages in Software Applications Raghunath G. Soman
  2. 2. What Are Error Messages… <ul><li>“ Error message” refers to the text or image displayed by a program when it encounters some problem during its execution. </li></ul><ul><li>It can be: </li></ul><ul><ul><li>A Message box </li></ul></ul><ul><ul><li>A Warning </li></ul></ul><ul><ul><li>A Confirmation </li></ul></ul><ul><ul><li>A Question, or </li></ul></ul><ul><ul><li>A Status Report </li></ul></ul>
  3. 3. Most Error Messages are so bad… <ul><li>… because they’re written by people who have an intimate knowledge of the program! </li></ul><ul><li>These people often fail to recognize that the program will be run by other people, who don’t have such knowledge. </li></ul>
  4. 4. An Ideal Error Message … <ul><li>Gives a notification that a problem occurred. </li></ul><ul><li>Gives a brief explanation of why the problem occurred. </li></ul><ul><li>And provides a solution to the user for fixing the problem. </li></ul>
  5. 5. A Good Error Message Should… <ul><li>… be Visible and highly noticeable. </li></ul><ul><li>… identify the program that is posting the error. </li></ul><ul><li>… provide Explicit indication that something has gone wrong and alert the user to the specific problem . </li></ul><ul><li>… provide Precise description of problem, rather than vague generalities such as “ syntax error”. </li></ul>
  6. 6. A Good Error Message Should… <ul><li>… provide specific details as to how the problem may be solved. </li></ul><ul><li>… s uggest where the user can obtain further help. </li></ul><ul><li>… provide all the relevant information to the tech support. </li></ul><ul><li>… have Human-readable language: No obscure codes, abbreviations or jargon. </li></ul>
  7. 7. A Good Error Message Should… <ul><li>… give Constructive advice on how to fix the problem. Instead of just saying &quot;out of stock,&quot; it should either tell users when the product will be available or provide a way for the users to be notified when the product is restocked. </li></ul><ul><li>… Preserve as much of the user's work as possible. Allow the users to correct only errors instead of having to do everything all over again. </li></ul><ul><li>… Reduce the work of correcting the error. </li></ul><ul><li>If possible, guess the correct action and let users pick it from a small list of fixes. </li></ul>
  8. 8. What is a &quot;bad error message?&quot; <ul><li>Simply put, a bad error message is a dialog box or error that doesn't make sense to anyone but the person who programmed it in the first place. </li></ul>
  9. 9. An Error Message Should NOT … <ul><li>… suggest an action that will fail to solve the problem and thus waste the customer’s time. </li></ul><ul><li>… contain information that is unhelpful, redundant, incomplete, or inaccurate. </li></ul><ul><li>… blame users or imply that they are either stupid or doing something wrong, as in &quot;illegal command.&quot; </li></ul>
  10. 10. Error Messages that suck…. <ul><li>Can anyone tell me why the Mac OS team chose a picture of a bomb to put on their error message? </li></ul><ul><li>Not the most friendly thing to see…. Esp. when you have committed an error ! ral: Do Not Scare your users!> </li></ul>
  11. 11. <ul><li>&quot;Valid authentication credentials were not provided.&quot; ... Did it mean to say that my password is wrong? </li></ul><ul><li>al: Know your audience. Speak its language.> </li></ul>
  12. 12. <ul><li>This one states something that is entirely obvious… </li></ul><ul><li>… but fails to state anything that is helpful. </li></ul><ul><li>If more than one error condition posts this dialog, there's no way to tell which one caused the problem. </li></ul><ul><li><Moral: Don’t just report the error, help to solve it.> </li></ul>
  13. 13. <ul><li>Really? Really? Which action? Which action? How do I fix the problem? How do I fix the problem? </li></ul><ul><li>Moral: Use meaningful sentences.> </li></ul>
  14. 14. <ul><li>Lots & Lots of data here… but User has no clue as to what to do. Based on the information presented in this message, why should the user choose Yes ? Why should the user choose No ? </li></ul><ul><li><Moral: Sometimes, too much info can be a bad idea.> </li></ul>
  15. 15. And one that shines… <ul><li>Error messages can't always be expressed in three simple sentences. Being concise is an important goal, but for critical messages it should not be the primary goal. </li></ul>
  16. 16. While writing error messages… <ul><li>Anticipate the possible error conditions. </li></ul><ul><li>Ensure that each condition in the program that has a chance of failure returns a distinct error code. </li></ul><ul><li>Display this code as a part of the error message. </li></ul><ul><li>Remember the program's state at the time when the error occurred, and permit the user to restore that state easily. </li></ul>
  17. 17. While writing error messages… <ul><li>Create error handling classes and functions to supply coherent, well-formatted error messages. Re-use them consistently. </li></ul><ul><li>Provide each and every error message to someone else for review. The reviewer should not be an expert in the program. </li></ul><ul><li>Use code reviews and walk-throughs with other developers and quality assurance to ensure that the program is readable, consistent, maintainable, and free of un-handled errors. </li></ul>
  18. 18. Usability Test For Error Messages <ul><li>Conduct an usability test on the error messages with your target users. Here are some things to check for: </li></ul><ul><li>Did the users understand the context of the message? </li></ul><ul><li>Did they understand the message text? </li></ul><ul><li>Did they obtain all the information required to respond intelligently? </li></ul><ul><li>What decision did they make? Why? </li></ul><ul><li>Are they confident that they made the right decision? </li></ul><ul><li>Did they understand the consequences of the decision? </li></ul><ul><li>Was the decision correct under the circumstances? </li></ul>
  19. 19. To Conclude… <ul><li>The error messages will be read by: </li></ul><ul><ul><li>the customer, </li></ul></ul><ul><ul><li>the tech support person who handles the call, </li></ul></ul><ul><ul><li>the quality assurance analyst who tracks down the problem, and </li></ul></ul><ul><ul><li>the maintenance programmer who is charged with fixing the problem in the code. </li></ul></ul><ul><li>Each person in this process represents a cost to the company. </li></ul><ul><li>While the error-handling routine need be written only once, the support path is typically followed many times--tens, or hundreds, or thousands of times. </li></ul>
  20. 20. To Conclude… <ul><li>Developers, Testers, Technical writers and technical support team must form an alliance and work in tandem. </li></ul><ul><li>Costs required to solve/sandbag a problem after the product has been released should be taken into account. </li></ul><ul><li>If the management wants to rush the product to market without leaving enough time for proper error handling, remind them politely of the cost of such an error ! </li></ul>
  21. 21. References… <ul><li>Michael Bolton@ </li></ul><ul><li>Everett McKay@ </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul>