Errors- they’re everywhere. No matter how well you coded your app, there will be problems you just can’t foresee. But in some cases you’re bound to realize in advance that there could be a problem. Here are the ways, in order of helpfulness, in which you can handle errors in your app and make it kinder to users:
- Absolutely Nothing. Don’t even tell the user something happened. After all, if there’s nothing they can do, why worry them about it? Please don’t do this.
- Hidden Error Console. This makes sense in a web browser for all the messy JavaScript or browser specific code out there that won’t validate. But in just about every other case a hidden console that the user can discover and activate is the coward’s way out.
- Dialog Window. Pop up a little window that says ‘Sorry, had some trouble.’ This is unhelpful, although at least the user knows not to trust your app anymore.
- Suggest an Action. In addition to mentioning the error, your app suggests a specific course of action. An example might be that your app expects an image but can only accept one up to a certain size. Someday you plan to add a way to do that within the app, but this is 1.0! So your dialog says ‘Can you try that again with an image that’s only 32 x 32 pixels?’ It’s not perfect but the user knows exactly how to get around the problem.
- Launch their Next Action. You can see that the Gimp is installed on their computer. Ask them if they want to launch it to resize their image. Even better, give them instructions on resizing it in the Gimp.
- Ask If You Can Help. You ask them in the dialog if they want you to attempt to resize it for them. If they click yes, use ImageMagick or similar to resize and show them the results to see if they accept the changes. Now obviously them not ever knowing there was a problem because you handled it so smoothly is ideal most of the time. But in some cases, you may be stepping on the user’s creative toes if you assume too much. The other benefit to asking them if you can help is that the user recognizes you’ve helped. So they pay attention to how you do and if it’s done well, they’ll be grateful and trust your app a bit more. If they don’t know you helped, you just don’t get credit.
I recently experienced a few of these in Ubuntu. I had gotten used to MySQL Workbench’s specific error messages without realizing I had. Since installing the Oneiric Ocelot release candidate, Workbench loads so slowly that I fired up the aging (yet generally more usable) MySQL Query Browser. I noticed right away that about the only feedback it gave was that I had run a query. It didn’t mention that it failed and ideas about why, which Workbench does.
An even better example: a few weeks ago, after downloading a compressed file I tried to extract the files and got a little warning dialog. But instead of jut saying ‘Invalid’ or ‘Unsupported File Type’ it asked if I’d like to install the needed files in the Ubuntu Software Center. Yes please! Problem solved.
Where are the problem points in your app? Anything you can do to make it a little kinder?