« Creating a Pleasant User Experience - Part IV: Many ways to do the same thing | Main | Desktop Sync Update »

Creating a Pleasant User Experience - Part V: Trouble Shooting

Every application has bugs. It’s inevitable. So making sure that your program responds in a nice way when it breaks is also part of a good user experience. Look at the error messages that you’re showing users and make sure that they’re friendly. Showing a dialog with “Exception from HRESULT: 0x8000A0259” is not what a user wants to see. In fact, showing any type of cryptic exception message is probably not the best way to go. 

What I do in most of my apps is keep a running log where I can write all this cryptic information that is a goldmine for me, but not friendly enough for a user. Nick Bradbury does something similar by making a user click a “Details” button on his error dialogs. 

The next important step is making sure *you* can get that information from the user. I do this by providing a “Submit Support Request” function that opens your default email client, fills in part of the email body with some more information, and automatically attaches my log files. Nick B provides a “Copy to Clipboard” function so users can easily supply him with the same type of information. 

Doing things like this increases your chances that a user will be able to help you fix whatever bug they run across. 

Of course, not all issues are because of your code. As software becomes more and more integrated, you need to be able to distinguish when it’s your code that broke, or when it’s some other component outside of your control. 

A classic example of this is Firewall and Proxy Server issues. I’ve seen proxy servers that strip SOAP headers from http, proxy servers that add spacing to http header names, and the always wonderful "I’ve uninstalled my firewall but it still blocks newly installed applications" problem. 

One way that Nick B and I came up with to help both ourselves and our users troubleshoot these types of problems was to create a Connection Test suite. Depending on which test fails, we can tell the user where to start to correct the issue. Hopefully NickB will elaborate on this more since he’s had much more experience in dealing with customers with these types of issues (after all, he did his own support for years).

Posted by Nick Harris on February 1, 2007 at 02:19 PM | Permalink

Comments

The comments to this entry are closed.