Computer error messages are the source of much frustration and bitterness toward computers and computer software. One thing that the computer programming education industry often fails to teach is the principle of designing error messages.
From the code I have seen on my NoPaste site, it seems that most novice programmers will display a message in their native language that says something to the effect of "Your input was wrong! Try again!" Years later, when they have a job at a software company, their error messages have progressed to say things like "Error 29923: Invalid resource handle."
The only difference between these error messages is their wording. The problem they share is that of failing to tell the user anything meaningful. In both cases, the error message really is designed to serve the programmer because it tells them something about what is going on behind the scenes.
It is not surprising that many computer users would be greatly annoyed to find their work interrupted by an unhelpful error message such as this. The user does not care what the code is doing internally, they just want their program to run properly, and to be able to fix situations that prevent the program from running properly.
It is for this second case that error messages should be designed. If the user can fix the problem, the error message should be one that clearly indicates what went wrong (and ideally, how to fix it). For example, Microsoft does a good job with their Internet Explorer error message when a non-existent web address is typed into the address bar. It yields a page describing possible reasons that it was unable to find the site, and several things the user can try to fix the problem.
In contrast, if you did the same thing in Opera, you would get a small pop-up dialog box error message that says that it could not connect to the site, and all you can do is press OK. The user is left with no information as to why it was unable to connect. The experienced internet user will know to check the typed-in URL, see if other sites still work, and so on. The novice is just left feeling dumber for causing yet another red error message to pop up on the screen.
A case study involves me trying to install the phpBB bulletin board system. This system relies on a database installed on the server on which it runs, and one of the first things the install script does is try to create the database tables, then populate them with some initial information.
When I tried to do this, a slough of database errors appeared on the screen saying that phpBB was unable to insert into a particular table. That's it. No suggested remedies, no places to look. I had to do the looking myself. It turns out that the database tables never got created. I checked into the install script's code, and discovered that the SQL statements to create the database tables had never been read properly from disk. The code that read the SQL statements from disk had been set up to suppress all file-system error messages. That is, they just assumed it would succeed and silently failed if it didn't. When I modified the code to enable the error messages, I discovered that there was a permissions problem on the directory that contained the SQL statements on disk.
A very easy fix, even for a novice computer user, but the process to find out how to make the fix took several minutes and some PHP programming experience. If they had displayed the file system error to the user, the user would have had more options. "A file permissions error? oh, ok. I can look at the file permissions then. Let's see.. the error message says that they need to be X, and whoops.. they're Y on my disk. I'll fix that and.. neat, it works."
The moral of this story? Don't tell the users things that won't help them fix the problem. Do tell the users things that will help them fix the problem. This is the point of error messages, and the general perception of computer software will improve if people strive to follow these principles.