Chuck Palahniuk opens his book Fugitives and Refugees: A Walk in Portland, Oregon, with this sentence:
"EVERYONE IN PORTLAND is living a minimum of three lives, says Katherine Dunn, the author of Geek Love."
I think, regardless of location, most people are many things to many contexts. You may be a truck driver who is a writer who also likes to paint. You may be a mother who is a gamer who also likes Renaissance fairs.
This many lives concept inspired my Twitter profile – Artist, Writer, Adventurer. This week, however, I feel like I’m more Technical Writer, Blog Reader, Software User. Within the span of two days, the topic of error messages has crossed my radar while working with a team to improve error messages, while reading Seth Godin’s blog, and while getting an error message as a user. In all three instances, it was apparent that no part of me liked the feedback that software was giving me.
So what do I/we want from our error messages? I want an explanation with a clue to the resolution. Telling me that there is an error is fine, but what am I supposed to do with that information? The error I was getting this week as a user was missing that clue to resolution. The message read, “An error has occurred. Blahbity blah is checking for errors.” Then the program restarted. It was quite apparent that an error had occurred because the program froze and stopped working. The error message served no purpose other than telling me what I already knew. Annoying!
The focus of the developers writing the code isn’t to help the user resolve the issue. They are concerned with ensuring that the application stops whatever process isn’t working and to alert the user that things have halted. To Seth’s point in his blog, an error message should not be cryptic. We’ve all seen errors which only contain numbers. Those numbers must map to something somewhere, but are meaningful only in the development group. So to get away from the cryptic, many developers have opted for the vague. This is as helpful as “Error 641 has occurred.”
How do companies appease the three people living in my head? Get someone outside of Development to review all the error messages in an application and don’t bother telling people things they already know unless you are going to help them resolve their problem.