Error Messages In Software Applications
Download as PPT, PDF3 likes2,726 views
The document discusses best practices for writing effective error messages in software applications. It recommends that error messages should briefly explain the problem, provide a solution, use clear language, and give constructive advice without scaring or blaming users. Developers are advised to design error handling carefully, test messages with users, and work with other teams to address errors properly.
Error Messages In Software Applications
- 1. Error Messages in Software Applications Raghunath G. Soman
- 2. What Are Error Messages… “ Error message” refers to the text or image displayed by a program when it encounters some problem during its execution. It can be: A Message box A Warning A Confirmation A Question, or A Status Report
- 3. Most Error Messages are so bad… … because they’re written by people who have an intimate knowledge of the program! These people often fail to recognize that the program will be run by other people, who don’t have such knowledge.
- 4. An Ideal Error Message … Gives a notification that a problem occurred. Gives a brief explanation of why the problem occurred. And provides a solution to the user for fixing the problem.
- 5. A Good Error Message Should… … be Visible and highly noticeable. … identify the program that is posting the error. … provide Explicit indication that something has gone wrong and alert the user to the specific problem . … provide Precise description of problem, rather than vague generalities such as “ syntax error”.
- 6. A Good Error Message Should… … provide specific details as to how the problem may be solved. … s uggest where the user can obtain further help. … provide all the relevant information to the tech support. … have Human-readable language: No obscure codes, abbreviations or jargon.
- 7. A Good Error Message Should… … give Constructive advice on how to fix the problem. Instead of just saying "out of stock," 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. … 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. … Reduce the work of correcting the error. If possible, guess the correct action and let users pick it from a small list of fixes.
- 8. What is a "bad error message?" 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.
- 9. An Error Message Should NOT … … suggest an action that will fail to solve the problem and thus waste the customer’s time. … contain information that is unhelpful, redundant, incomplete, or inaccurate. … blame users or imply that they are either stupid or doing something wrong, as in "illegal command."
- 10. Error Messages that suck…. Can anyone tell me why the Mac OS team chose a picture of a bomb to put on their error message? Not the most friendly thing to see…. Esp. when you have committed an error ! ral: Do Not Scare your users!>
- 11. "Valid authentication credentials were not provided." ... Did it mean to say that my password is wrong? al: Know your audience. Speak its language.>
- 12. This one states something that is entirely obvious… … but fails to state anything that is helpful. If more than one error condition posts this dialog, there's no way to tell which one caused the problem. <Moral: Don’t just report the error, help to solve it.>
- 13. Really? Really? Which action? Which action? How do I fix the problem? How do I fix the problem? Moral: Use meaningful sentences.>
- 14. 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 ? <Moral: Sometimes, too much info can be a bad idea.>
- 15. And one that shines… 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.
- 16. While writing error messages… Anticipate the possible error conditions. Ensure that each condition in the program that has a chance of failure returns a distinct error code. Display this code as a part of the error message. Remember the program's state at the time when the error occurred, and permit the user to restore that state easily.
- 17. While writing error messages… Create error handling classes and functions to supply coherent, well-formatted error messages. Re-use them consistently. Provide each and every error message to someone else for review. The reviewer should not be an expert in the program. 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.
- 18. Usability Test For Error Messages Conduct an usability test on the error messages with your target users. Here are some things to check for: Did the users understand the context of the message? Did they understand the message text? Did they obtain all the information required to respond intelligently? What decision did they make? Why? Are they confident that they made the right decision? Did they understand the consequences of the decision? Was the decision correct under the circumstances?
- 19. To Conclude… The error messages will be read by: the customer, the tech support person who handles the call, the quality assurance analyst who tracks down the problem, and the maintenance programmer who is charged with fixing the problem in the code. Each person in this process represents a cost to the company. 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.
- 20. To Conclude… Developers, Testers, Technical writers and technical support team must form an alliance and work in tandem. Costs required to solve/sandbag a problem after the product has been released should be taken into account. 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 !
- 21. References… Michael Bolton@ developsense.com Everett McKay@ msdn.microsoft.com http://www.klariti.com http://www.useit.com http://www.wideopendoors.net