However, a more pressing issue I think is the ability to copy and paste errors. Too many times am I presented with a message box that I can’t select the text for and copy, and find myself manualy copying the error message (or the shorted possible uniquely identifiable substring of it) into google manualy.
Actually, pressing CTRL+C when you see the message box should copy its contents into the clipboard in most cases…
Here’s a list of the DNAS error codes from Playstation 2’s online connectivity
http://www.broadbandreports.com/faq/dnas?text=1
examples:
-101 sceDNAS2_SS_SERVER_BUSY
DNAS server is busy. “DNAS Error (-101) The network authentication server is busy. Please try again later.”
-102 sceDNAS2_SS_BEFORE_SERVICE
DNAS authentication service period has not started for this title. “DNAS Error (-102) This software title is not in service.”
-103 sceDNAS2_SS_OUT_OF_SERVICE
DNAS authentication service period has ended for this title. “DNAS Error (-103) This software title is not in service.”
I think error codes are a very valid and useful way to describe errors. Often, the user IS not very tech-savvy and a useful error message like “your raid partition has just lost its connection to the PCI bus” means just as little to them as saying Error: 2615. However, when they call tech support if they have an error code, they will say, “Hey, i have error 2615, what should i do” whereas the longer message will most likely come out as, “HELP, my PCI raid missed the bus” or something equally as nonsensical.
Also, the presence of an error message implies that there is a text somewhere with a full text of what that message implies. Usually in the back of the manual. If you can’t go look up an error message, you have no reason to be trying the problem yourself anyway.
Having just hit the ole TFS 26105, I’m in no mood to sing the praises of error codes. Let me add one thing: if the user cannot do anything about the exception, don’t bother them with the information. If the program can continue, log it and go. If it can’t explain to the user that the program has encountered a problem, it has already reported the problem to whatever entity must know about it, and that the help desk will contact the user if additional info is needed. These days, in the time it takes the users to do anything, the error can be logged, an email alert sent to a tier 1 helpdesk, and the issue resolved, with the support team contacting the user back and telling them they’re ok to proceed.
I certainly try to follow Alan Cooper’s guidelines whenever I need to present information to the user about an error but unfortunately as long as my software relies upon other systems that still use error codes there will always be cases that can be very difficult to deal with.
Just as annoying as error codes are error boxes that don’t know what went wrong and give you three or more possible reasons why the error occurred: “Either your Internet connection is down, the server is offline, or the server cannot accept any more connections”. Some more code in the error handling could probably pinpoint the problem before informing the user.
I agree with the principle, but error codes often hold valuable information for actually fixing the problem. An error message which just presents a cryptic error message is bad, but not as worthless as a pretty but totally generic error message. I can google “0x8024402c”, but a smiley faced “Sorry, I just deleted your files, have a nice day” message is worthless. (c.f. Sad Mac image). Also, error codes are a lot more efficient for communicating with tech support or in online help forums than long error messages.
Error codes are a functional counterpoint to knowledgebase ID’s, since they allow us to solve problems in an organized and repeatable manner. A good error code is really an error ID, which is valuable.
I propose that error messages be made available via an “advanced” button or tab, or in parenthetical information at the end of a nicely written, human-centric error message:
18 years later, error codes are still used, and are somewhat annoying depending on the system using them, but for the most part generally useful.
Ok, but why not “yes, and…”
Why not provide an error code and some helpful diagnostic steps?