…Continued from part 1
In part 1, I scolded you for showing error messages to users. I suppose I should ‘fess up though and just admit that I’ve shown my share of error messages over the years! The more I consider the problem though, the more I think that error messages are a bit of a lazy way out.
In this part, let’s get to a more practical level and talk about when it might seem important to show messages. Hopefully we can find ways to avoid most of them. There may well be other classes of messages that seem to require message boxes, but I’ll start with these.
Reasons to show a dialog:
- Fatal error such as an unhandled exception
- Environment problem like file missing, bad permissions, hardware disconnected
- Transient outage (network, file server, database)
- The user must take action (user mistake, conflict with existing record)
- Warning/info message like update available
Fatal errors
On the surface this might seem like a no-brainer. If you catch an unhandled exception in your Application object, then there just isn’t much that you can do about it. Clearly, the ideal would be to avoid it, but it’s too late. On the other hand, this is very valuable information. This is definitely when you want your users to let you know so you can prevent it from happening again. Remember though, that your user clicked OK, the dialog disappeared, and then the whole app went away. Totally unexpected!
If the user can restart the app and keep going, then you probably won’t ever hear about it. Sometime, over lunch, you might hear people make a mention of “that one” problem that happens a few times each week. Don’t bother getting annoyed that no one reported it. Code defensively!
If you can send that exception, the current record, any temp files, or anything else that would be useful, then you’ll be in much better shape. Write the data to a tracker database, open a help desk ticket, whatever you need to do. Rather than trying to reproduce an error that might happen once in a thousand times, this give you hard data from the time that it did happen.
Environment problems
These can be tricky. If a file is missing or has the wrong permissions then something important just isn’t going to happen. If hardware is disconnected, then your bar code scanner will be useless. The good thing about most of these errors is that you can check for the condition before anything goes wrong.
If hardware is missing, display a message (I never said dialogs are completely forbidden!). The trick is to do the work on the user’s behalf as much as possible. The user will need to reconnect the device, but your code can check periodically and “unlock” the application when it appears. After all, if it’s required, then clicking OK doesn’t serve any purpose unless the device is back anyway.
You can check for files to exist or even read-write permissions before writing. Instead of a generic unhandled exception since “that file won’t ever be set to read-only” just expect it. Log and send the error, then let the user know that the application isn’t useable without help desk intervention. The worst thing is for the user to get through four screens of data entry just to lose everything due to an “impossible error.” Make it work every time for your users. You’ll have a better reputation and better information about what needs attention.
Outage
Databases stop responding. Network links go down. File servers get rebooted during production hours. There isn’t much that you can do about them, but you pretty much know that the issue won’t last forever. Let the user know that there is an outage, and make it clear that retrying is happening automatically. Users hate “please retry.” They already attempted it and it failed. They are starting out annoyed and this won’t help.
Required action
Clearly there are situations where you can’t do anything for the user. Is a required field missing? Did another user update the same record and cause a conflict? I hate to admit it, but here’s a situation that can’t be avoided. At the same time though, you can do a better job with it. Is a field blank or formatted wrong? Jump to the field and flash a bright red outline around it. Did the update cause a conflict? Create a region above or below your contents that only appears with critical information. Just like a web application will often have an error message area, there’s no reason why a desktop application can’t do the same thing. A dialog gets dismissed and forgotten. Show the message until the update is successful so the user can actually benefit from the information.
Warning/Info messages
Now these are definitely the bane of any user. A message that says “record saved” is just a stupid impediment to the work flow. Flash an indicator somewhere, show a non-modal notification (balloon dialog), or use a status bar in the application. Just don’t interrupt for something that has no business interrupting. The user only cares when something goes wrong – otherwise stay out of the way!
Continued in part 3…
Posted Friday, March 19th, 2010 at 3:38 pm by Arian Kulp
921 views