Grumpy Old Man

Computer programmers are supposed to be intelligent. So why do I continually come across illiterate, nonsensical error messages? I don’t know the answer to that, but this post is directed at programmers in an effort to get them to think about what they do and correct the problem. If you aren’t a programmer, feel free to do something else for now, normal service will be resumed soon.

Software companies spend millions on ‘useability’ research, getting their user interfaces as good as they possibly can, but the whole effect can be ruined by one application developer who is too lazy to do his job properly. Here are some things developers should think about when handling errors in their programs.

Who will be using the program?

Obviously error messages aimed at pre-school children will be very different from those aimed at post-graduate computer scientists. This is so obvious it shouldn’t need to be stated, but programmers seem not to be aware of this, or have forgotten it in the heat of the moment. Don’t put a message like this in a game, for example:

Error at mem 0xffff17ba: unphased bypass operation. Reset second pulse generator to continue.

(unless the game actually has something called a second pulse generator which the player could be expected to know how to reset.)

Who will read the message?

This is related to the preceeding question, but is not identical to it because often different error messages are generated for different audiences. I work for a large retailer writing and maintaining database applications that are used by employees in the our distribution centres. It is reasonable to display an error to the user of the system that looks like this:

Error 1234 has occurred. Please contact the support helpline on extension 5678.

The same program could have written a different error to a logfile for the support department:

Error 1234: Country code does not exist on the country table. Please escalate to the IT department.

Instead the following error message is both displayed to the user and written to the logfile:

ERROR!!! CANNOT PROCESS THIS RECORD.PROGRAM ABORTING!!!

Apart from the annoying capitalization and the adolescent abuse of punctuation marks, this error message is useless because it doesn’t tell anyone what the problem actually is, or how to solve it.

The user cannot read your mind.

A lot of error messages are generated because the user has entered data that is in a format that the programmer did not expect. This is entirely the programmer’s fault unless he made it clear in advance what he expects. For example, in the US dates are usually written in mm-dd-yyyy format, whereas in the rest of the civilized world they are written as dd/mm/yyyy. There can be few things as annoying as entering the date and a message pops up telling you that you have used the ‘wrong’ format. Why didn’t you tell the user in advance what the expected format is?

Date (dd/mm/yyyy):

Being proactive in letting the user know what you expect goes a long way towards reducing frustration.

Is the information you request necessary?

Here’s a gem:

You need to supply a fax number in order for your request not to receive fax notifications to be processed.

Why? This user probably doesn’t want fax notifications because he hasn’t got a fax machine. This programmer clearly hasn’t thought about what he is doing at all. Similarly, why should someone have to give his hat size in order to become a blood donor? If you really want to alienate your customers, invading their privacy in this fashion is a good way to go; if you want this information for some or other reason, like marketing perhaps, then by all means ask for it, but don’t insist that it is provided. I’ve ‘walked away’ from many ecommerce sites because of their insistence that I divulge impertinent information.

Don’t only give the error—give the solution

You’ve told the user about the problem, but what must he do to recover the situation? If you don’t tell him you’ve only done half the job.

Error: software patent violation. You cannot continue to run this program. Please write to your MP or Congressman to get software patents banned.

OK, that’s another hobby horse I don’t want to ride right now, perhaps another day, but the frustration level of not being able to do whatever it is you want to do because of an obscure software error without having the faintest idea of how to fix it is high. Inform the user–give him options that will allow him to progress, or at least recover to the state he was in before the error struck.

All these things can be summed up in two words: good manners. Treat your users with the respect they deserve as your customers. Your error messages should be pertinent, detailed, informative and allow your users to do their jobs as efficiently as possible. I leave you with this hilarious quotation from the Microsoft C# programming manual, which perhaps goes some way towards explaining why error messages are as bad as they are:

The ButtonProperty value is a string that represents the property name used by the installer to retrieve the value of the button group. This property can be referenced by custom launch conditions to make decisions concerning application installation. For example, if the ButtonProperty is set to Buttons, you create a launch condition that examines the value of the Buttons property. If the first radio button is selected, Buttons takes the value contained in the Button1Value property. Likewise, if the second radio button is selected, Buttons takes the value contained in the Button2Value property. Many of the customizable dialog boxes have similarly configurable properties, which allow you to create a rich and complex installation experience for your users.

Grumpy Old Man by Mark Widdicombe is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 License