(This is part of a series about the UI design issues in the free Versabanq AmSchedule Express. This is not an advertisement, because if you're reading this, you have no use for my program. But download it yourself if you want to follow along. Absolutely no registration or signup is required.)

AMSE Part 4: Reporting crashes back to the developer

Why would I tell Microsoft about someone else's crashy program?

During the development of AMSE, I distributed a few early versions to various people (including my sister) around the Internet. Predictably, they did some things I wasn't expecting, and the program crashed or gave weird errors.

Weird errors are a problem for three reasons:

1. People don't read error dialogs, but it still gives them an unsettled feeling (= less user enjoyment);
2. Even if people notice the error, they never quote it back to you accurately (if at all);
3. Even if they quote it back to you accurately, the error message itself isn't usually that helpful because programmers are idiots (including me, apparently). This is particularly true in case your program segfaults.

Some of my testers (hi, Jana) were especially helpful and successfully bypassed the first two problems, but even the most helpful tester will be confounded by #3. One error message I got, "12/29/2029 is not a valid date," is pretty unhelpful for several reasons: first, I didn't write that error message; it doesn't show up in my program code anywhere. And second, 12/29/2029 is a valid date! A stack trace would have been nice.

Of course, developers have long ago figured out what to do about this problem. Most "serious" apps nowadays include a "quality feedback agent" that catches problems and offers to report them back to the vendor to have them fixed. Ah, yes. Quality feedback agents. QFAs.

Why quality feedback agents suck

1. The user has no idea what's going on. Most QFAs ask a series of confusing questions like, "What were you doing when I died?" and "Can you give us reproducible steps to make the problem recur?" and "What do you think the priority of this bug should be?" and (the nerve!) "What component of our software do you think this bug is in?" Normal people don't know the answers to *most* of these questions, and even if they did, most users would answer them incompetently. Why bother asking at all?
2. The user doesn't care enough to put in any effort. Again with the wizards: asking too many questions will discourage people from submitting the bug at all. As a developer, I'd rather be inundated with vague bug reports (that at least include stack traces) than miss most of my reports because people cancel the wizard; so why have a wizard at all? Some crash reporting systems actually make me *log in* to the bug tracking site before they can finish their submission; less awful ones still demand my email address; still others make it optional. Why even ask? The first thing *all* these systems ever say is a variant of, "We get way too many bug reports to actually go through them all. Nobody will contact you unless we need you for something." In other words, as a user, giving you my address has no upside and only a possible downside (you might bother me about it later).
3. It's the 21st century, you can send data in the background. This is one of the most insulting things in most QFAs: after I've gone through the idiotic wizard and agreed in triplicate to submit the bug report, it pops up a modal progress dialog and refuses to do anything else until the upload is complete. Yow! First of all, how does it take an observable amount of time to submit a simple stack trace? Web browsers do HTTP POST requests instantly all the time - but QFAs seem to take at least 10 seconds to report bugs, sometimes much longer. I'm talking to you, Microsoft and Borland. And secondly, why can't I do anything else at the same time? Multitasking was invented some time ago now, guys; I think we should consider using it for stuff.

AMSE's bug reporter

AMSE's error reporting system barely even qualifies as a QFA; it has basically no user interface:

I faked this error, just for you.

Whenever an unexpected error happens, we pop up an error dialog. (Delphi is kind enough to let you define a "default exception handler" at the top level, and null/invalid pointer references get turned into exceptions too - clever. Then we use the awesome JclDebug to get the Delphi stack trace.) The error dialog has a checkbox for "Report this problem to Versabanq." The default is on. If you toggle it on or off, we remember the setting globally for all Versabanq applications in the registry for all future errors.

When you click OK, if the checkbox is checked, we silently go off into the background and submit an HTTP POST with your error message and stack trace. Yes, it's anonymous, because yes, it's true, we really don't expect to have time to reply to every possible submission, so there's no point quizzing you about your address. There's no completion bar, because you, the user, don't care if the submission has started, finished, or failed; you have no emotional investment in it whatsoever, other than annoyance.

Best of all, because the user interface is so lightweight, you won't even think twice about leaving the checkbox checked (unless you're a developer or you have privacy concerns). That means every time you get the error, you'll probably submit it to us. GREAT! - that means we'll easily find out which problems are frequent problems for you (and others) and which are a one-time thing. The statistics about crash reports are extremely important.

Just like playing with the AMSE installer, I find reporting crashes with AMSE fun. It's actually enjoyable to push the OK button on the error dialog, knowing that the dialog will go away instantly and I can get on with my work, and I'm helping out (okay, in this case, I'm spamming myself, but you get the idea). Instant gratification is a powerful thing.

Next time: popup hints, online help, and the long-lost art of the status bar.