Error Messages and Providing Information

The most interesting error message I ever saw read something like “Unexpected error – installation dying in disgrace” It was the “dying in disgrace” that I found really amusing. It wasn’t all that helpful but it did provide some humor in an otherwise very serious situation. At the time I was doing application installation testing for the final build of an operating system so this was a really big deal. Someone got called into work on a weekend to deal with that let me tell you. It would have been better for all of us if there had been more detail in the message of course. This is just one example of how important messages can be though.

Earlier today Doug Peterson posted (Tweeted on Twitter actually Follow Doug @DougPete) a link to the image below and called it a good discussion point for computer science classes. I agree. (Doug later blogged about this as well – check out Error Messages for Learning)

Just what does that message indicate? Is it success or is it an error? Or is it some success handling an error? Is it bad or good? Who did what to cause it? And what is going to happen when the user hits the OK button? This message promotes more questions than it answers. I wondered if a student created this message but apparently it came from Family Feud on Facebook. Not what I typically expect in a professionally developed piece of software.

I’ve had students write programs with some obscure (lazy) messages as well as some fairly nasty error messages over the years. Error messages that call the user names or berate them as stupid and the like. This results in a discussion about the term “user friendly” of course. The other issue is messages that do not provide the user with enough information on how to handle the situation. There is a real knack to helpful error messages and it takes some thought. A message that says “bad things happened” is not enough by itself.

Error messages are not the only sort of messages though. There are also messages that ask questions, give instructions, or a combination of both. We work hard to emphasize that the computer can’t handle ambiguity but forget to remind students that users need clear easy to understand instructions and information as well. Teachers often don’t cover this in courses like the Advanced Placement Computer Science exam course where the focus is almost completely on programing concepts. Teachers often neglect related concepts like user interface design, error handling, and other human computer interaction (HCI) concepts that we tend to include under the heading of software engineering. Some of this is because of a feeling of necessity – there is limited time in the school year and many things that must be covered for the exam. So anything not tested is given a lower priority. This is both unfortunate and a reality. Trade offs have to be made.

I think though that these concepts have to at least be raised and discussed though. Sooner or later most programmers write code that someone other than the programmer is going to use or a grader is going to evaluate for correctness. So we should talk to students about how messages should be clear, helpful and ideally polite. Right?