How would you improve our Unhandled Exception Handler error message?

Question

We are three internal developers with a user count of about twenty. We've implemented unhandled exception handling in our Winforms app. It generates a ticket with the stack trace in our FogBugz (renamed internally to DevTracker) bug tracking system.

The goal is to encourage the user to enter an informative bug rather than simply moving on. When they click the first button we do the work to put them on our project site with a new case started. They simply have to fill in the comment box. I'm debating whether or not the "What are we doing?" section should exist.

What's your opinion?

---

Take two

A little more background... The users are well versed in using FogBugz (Dev Tracker) as it's how they request feature and bug fixes currently. In addition to unhandled error handling, we've added log4net into the mix for the next release. It pushes the stack trace to a log on the users local machine (in case of a down network), an internal database, and a FogBugz case.

After reading Andrew's answer it pushed me towards what I was already thinking... simpler is always better. I've removed the "What we're doing" section all together and paired down the verbiage.

---

Take three

Thanks for all the feedback. This is what we're implementing.

Answer 1

The approach I've taken is to make it as simple as possible for the user. They're already worried about the fact that you're presenting them with a scary looking error message, so you don't want to introduce extra stress by interrogating them. Ask for a brief comment and pick up as much as you possibly can automatically.

It's worth noting that with FogBugz you can store a message against a case once you've diagnosed it. If the same error occurs again you can get that message back from the server to present to users. I've moved away from FogBugz over the last few years so my memory on exactly how that works is a little fuzzy, but I do recall being able to store a corrective action message and present that to users when it made sense.

EDIT: Now that I've seen the image my comments still stand. Simplify and take away any scary language. I'd remove references to "Dev team"; use "us" instead. Remove references to "normal English". You want to ask simple questions: "What were you doing?".

Answer 2

I don't know if you're already doing this behind the scenes, but I like the approach of simply allowing the user to enter their email address and click "Send Error Report".

And then when I get the error details I'll look into the problem, fix it, and then immediately reply to them letting them know the issue is resolved.

This does a couple of things. It makes it extremely easy for the user to submit the error along with a way for them to be notified when it's resolved. And it lights a fire under my butt to get the issues resolved as soon as possible so I don't get the same error report from dozens of users.

Of course, when I've implemented this method its been for websites, not desktop applications. And they're sites that I'm able to make changes to very quickly.

Answer 3

We have something similar (not quite so weird -- kudos to you), but we also have the ability to view the exception (hidden from user by default of course) for developers that may be troubleshooting at a user location or for users that are calling the help desk.

Also, you could tell them that you are going to send the guy to the right in the picture to their desk to help them if they don't submit the report. That should scare them into doing it. :)

Answer 4

Users hate it when they're trying to get something done and you interrupt them. (I know, I'm one of them.) And here, you're not even giving them the chance to pick the default answer. I totally understand why, but tread carefully. Interrupt their train of thought as little as you can possibly get away with.

(By the way, after this, does the app terminate, or do you recover and let them continue with what they were doing?)

So you're giving the user two options: "tell us what you were doing" and "get on with it" (but with way more words than that on the button, even in Take Two). You really want them to pick "tell us what you were doing", but as I understand it, you implement it by opening a Web browser. Huge interruption. Once the user is done, they'll have totally forgotten where they left off. They'll also hate you and won't give you useful comments. (Heck, by the time the browser finishes loading, they're likely to have gotten distracted by another app (or by restarting your app), and leave the Web page "for later", by which time they've forgotten any useful context.)

Instead, why not put a text box right there in the dialog? Might be a little more work for you to wire up initially, but I think you'd get better feedback.

I'm thinking something like this:

• Excuse courtesy of the "The Bastard Operator From Hell"-style excuse server. They have more.
• Start with the cursor in the "Tell us what you were just doing" text box, so it's easy for them to give you feedback: just a matter of typing something and hitting Enter (or clicking the button with only three words on it).
• Make "Finish crashing already" a hyperlink, so it's there but de-emphasized. Left-justify it so people don't immediately associate it with the Cancel button it really is.
• If someone does fill in the box and submit a bug report, your "hey, thanks!" dialog could mention "by the way, if you get this again, you can click the 'I've reported this before' hyperlink", and show a screenshot with a red circle and arrow so they maybe notice.
• Any other text you want can go in a sidebar with a different background color. Banner-ad blindness will keep people from even seeing it unless they're in a curious (and patient) mood.