Are error messages evil?

A colleague of mine posted a question to us developers for our input.  They had read an article on LinkedIn which stated the following, and asked for our thoughts:

Error messages punish people for not behaving like machines. It is time we let people behave like people. When a problem arises, we should call it machine error, not human error: the machine was designed wrong, demanding that we conform to its peculiar requirements. It is time to design and build machines that conform to our requirements. Stop confronting us: Collaborate with us.

I had a look through the article, and it didn't change my mind, as a developer, as to what error messages are there for.  I don't see them as confrontation (usually) but rather as the collaboration that the author of the article was looking for.  A well created error message will let you know what happened (or didn't happen) and why.  It should also let you know how to solve it.  The error massage in question does, in fact, meet the criteria for a useful error message.  The error is on a Mac and reads "You can't use a name that begins with a dot '.', because these names are reserved for the system.  Please choose another name".

Let's break down that message with the points which make a useful and intuitive error message and work out what's wrong with the error:

• Lets you know what happened
  In this case, the implication is that the file wasn't saved.  Also given that you will return to the save prompt afterwards shows that the file hasn't been saved
• Why the error occurred
  "you can't use a name that begins with a dot '.'".  This shows us why the error happened
• Let you know how to solve the problem
  "Please choose another name".  That couples with the "You can't use a name that begins with a dot" part of the message gives a clear indication of what needs to be done in order to successfully save the file.

What we don't know from the article is what program was being used (the author was just wanting to rename a file), and what type of file was looking to be generated, so I can't judge just how frustrating this would actually be.  For myself, as a web application developer, this would cause intense frustration with me, as some of the files I create do actually begin with a dot (Apache .htaccess files), so if this was coming from a web development IDE, the message would be stupid.  In this instance though, assuming they aren't trying to create a file like that, the file system usage of a file name beginning with a dot is to show the file system that the file is hidden.  This is common on all *nix systems.  There is, however, no reason why there should be a limitation to stop people creating hidden files from software, it should probably just confirm that hiding the file is the intended behaviour.

The author is under the impression that the machine actually has caused the error.  Granted machines are dumb and can't do anything by themselves, but it doesn't mean the machine was wrong.  Somewhere along the line is a human error.  it doesn't matter if it's the user, the software tester, the developer, the system designer, system analyst, business analyst or customer.  Somewhere along the line a human made the decision that if a user wanted to start the file name with a dot, then they should be stopped.  As such, the machine was just following the rules it has been told to apply.  That's all they do.  Get an instruction, follow the instruction, wait for the next instruction and repeat.  With the instructions given, it has to follow the rules that have been given to it to carry out the instruction.  When the instruction conflicts with the rules, it follows the rules will, if it has been thought through, tell the user why it couldn't do as requested; in the form of an error message.

There is the proposal put forward for letting the person know the requirements before they did something, but I feel that he majority of users would find this intrusive or annoying.  It's fine if there are a small number of requirements, but when there are a large number of underlying rules, listing them all out could take up a lot of space.  They would have to be bullet pointed and simple as people won't read a whole wall of text (think licence agreements, very few people actually read them), so the requirements could take up a whole screen in themselves.  And there's also the issue of requirements possibly changing depending where on the system you go.  For instance, if you're creating a new file, you might have the following top level rules:

• Cannot start with a dot "."
• Cannot start with a space " ",
• Cannot contain a slash "/" or "\"
• Cannot contain a colon ":" (more specifically windows, but still)
• Cannot start with a tilde "~" (this is sometimes used for temporary files)
• Cannot contain quotes or apostrophes

Assuming then, that I can have the file name "New Company Quotation (Draft) - Value $12000".  It meets the requirements given, and the default storage location would be the users document's area.  If that user than tries to save the file in a location they are not permitted to, say /sys, then the requirements would change as they tried to navigate to that location.  The user might be able to look at files in that directory, and therefore be able to navigate to the directory, but not have permission to write to that location.  It would be impossible (or certainly highly impractical) for the requirements to know which folders the user has write permissions for, and then tell them that they cannot create a file in locations X, Y and Z.  File systems can be a maze, and listing all of the places they can, or cannot create a file would create a list of requirements so large that people would ignore it anyway and just use trial and error.  Just as they are at the moment.

I'm a firm believer in giving people an informed error message, which will let them know what has been done wrong and how it needs to be corrected.  This can be done in large sentences, or in quick bullet points, but should still meet the outline of a good error message.  The last error message I wrote was simple, and would show if the user tried to enter text into a number field.  It would pop up and say "The Price field must be numeric".  On closing the error message, it would take you back to the field which was incorrect.  It's very basic, but still covers the points.

• Lets you know what happened
  The error was given because of some user input, the field is listed in the error message and when closed will take the user to the offending field
• Lets you know why it occurred
  The input needs to be numeric.  The user entered something which wasn't a number
• Lets you know how to solve the problem
  By stating that the field must be numeric, the user is told what is expected.

Is the one I wrote any better than the one the article is complaining about?  Not at all.  In fact I would say the apple one is better as it gives a little more information, and isn't overly blunt.  However my requirements were to simply let people know that the field needed to be numeric.  I wasn't given any specific wording to use, so I covered the basics with it.  The error message was around some custom work, so the users would be trained by us, and then internally, on what can go in there, so the error is just a fall back, and would rarely be seen.

So, are error messages evil?  Absolutely not.  They are there to inform you that something you tried to do conflicts with some arbitrary rules which someone somewhere dreamed up.  You might not agree with them, appreciate them or even care about them; but they are there and need to be adhered to.  If you get an error message, just be thankful that you got one, and that the system didn't simply crash and cause you to lose a day's work.  And please read what it says, it will help you avoid the problem in future.