1) An error by the user that needs to be corrected.
2) An error unexpected by the developer and announced for debug purposes
3) An error that occurred, but is corrected. Often reported as part of a debugging the capability, and left in the code.
Warnings and errors are usually the same thing, but just a level of severity of an error. So assume we are talking about both.
The problem with most software is that the errors unpredicted by developers often are reported without any information to help isolate the error so that it can be corrected in code. We have all seen it, a confusing error message and usually diminishing functionality because the error makes the application unstable, corrupts data, and makes the application behave like it has gone insane.
The worst thing about the class 1 errors is that if you call support, the first thing they ask is, "What were you doing just before you saw the message?" What a worthless statement. Most people are not memorizing every step prior to an error. It is one of the world's most silliest questions.
I am sorry, but you need debug info. You can't interview customers. You need to build in the ability to report errors in a rich way to allow recreation and/or isolation of the issue.
Data to Report for Errors
What information? How about the log, the user's files, and here is a breath of fresh air: The undo/redo stack. The undo/redo stack is in many applications already. The only job is to serialize the data to allow a developer to understand what the user did 'before' and error.
The commands in the stack may not isolate the exact issue, but it can narrow down the activities. It should be required by all development organizations that the undo/redo stack be serialize-able and even repayable to recreate errors.
Rules for Error Dialogs
1) All errors (and warnings), should have a way for the user to report to developers. That includes errors made by developers. The fact is that even user errors can be a result of bad design. If you get a disproportionate reporting of user errors, your application probably needs a redesign.
2) No generic message dialogs! They just ask for trouble. You should have
a) A reference to the part of the code the error was generated from.
b) A short sentence to describe the error
c) Any related data, like the type and object instance identification where the error occurred.
d) Information on how to correct the error
e) If possible, undo the action that caused the error
f) Ability to report the error to the development team
3) Don't report status with dialogs if you can avoid it. The fact is that dialogs are at least an extra click for users to waste on dismissing a dialog.
4) Reporting an error that you have corrected is also a waste. Often such dialogs remain in code because the developer likes to see the result of hard work. Users don't care, so these dialogs must be forbidden. Even logging this sort of thing may be a waste of resources.
5) If you can, auto report errors back to developers. The simple fact is that developers will successfully ignore user problems unless you have the statistics to prove code is broken. Usually only users see errors as developers don't behave the same way and don't encounter such errors. It is therefore imperative that such data be reported to developers to close the loop. Do it electronically to avoid wasting everyone's time, money, and effort.
All Dialogs are Criminals Until Proven 100% Necessary
The simple rule of thumb is to avoid dialogs in many cases. This is especially true for errors, warnings, and informational dialogs.
No comments:
Post a Comment