why do error messages go like “install failure error 0001” instead of telling the user what’s wrong
In: 1812
Because most users won’t be able to understand the technical reason for failure. It would be meaningless and unhelpful. They can remember or write down short numbers, to look online or to ask support.
Telling someone exactly what went wrong will be a very lengthy explanation, one that the user might not be able to fix.
Usually the tech support people have a web page or something where they can look up what went wrong and how to fix it.
When they can’t fix it, they pass on the number to the programmer who can look into the code and figure out exactly where the whole thing went wrong, and then reprogram the thing and fix it that way.
Usually when it gets to that point the tech support people will pass even more detailed logs of how it went wrong.
Source: am a programmer.
So, a lot of the other answers are indeed correct but I’m going mention one thing.
tl;dr if the developers could write such a message they can probably just prevent the issue from ever happening in the first place.
I work in software and when fixing an issue almost alwas 90% of the time is just figuring out the *cause* of the problem. As soon as the cause is understood it’s, generally, trivial to fix it.
So why would I have an error message that’s super easy to understand in plain English? If I understand what’s gone wrong so well that I could write that error message I could just make the software fix it automatically.
Those error codes are for when something that I didn’t even think of went wrong, in which case the language that’s used needs to be understood by engineers and technicians. Because oftentimes for us “plain English” is fluff. I consider an error log that’s a call stack and error code to be infinitely more helpful because it’s precise and exact.
There are multiple parts in your question:
(1) “Why doesn’t the error simply explain what’s the problem?”. Because most users don’t want a full page of “error in function ‘various_update_ter’ when called in function ‘supervision_step_phantom’ when called in function […] : Segmentation Fault.”. This error report can be used to patch the bug in a future release (so some software will ask you permission to send an error report), but is not much use to the average user.
(2) “Why doesn’t the error simply explain to me what to do to fix the problem?” Because if the developer knew the solution in advance, there wouldn’t be an error displayed in the first place. Outside of errors like “wrong password”, if there was a solution known the program would use it instead printing an error messages. Modern softwares are full of error catching mechanisms, meaning that errors occurs but the developer knows why so also programmed the solution instead of printing a message to ask the user to do it.
An error number is something you can google or quote to tech support rather than “some error with those drivers or something”. It also abstracts from all the language issues. You can just print out “0005” instead of error messages in a couple of dozen languages.
[removed]
Sometimes errors are the user’s fault and we can clearly tell them what to do EX: The user tries to open an Excel spreadsheet in Photoshop. We can tell the user “we don’t know what that file is, please make sure you’re opening only .PSD files” and the user can fix it.
Other errors are more to do with the internals of the program breaking. A lot of the times this info is just jargon and completely useless to a user, and is a lot more likely to get lost in translation when actually seeking technical help.
EX: A user tries to open a Photoshop file in Photoshop and gets an “ERROR: Missing ID in Layer Manifest[0].” Wtf does this even mean? You’re guess is as good as mine, and it’s not like you could even fix it even if you knew since there are no options in Photoshop to modify that data. On top of that, there’s a high likelihood that the user will report it as “Layer issue,” or “How to fix missing ID in Photoshop,” which only complicates troubleshooting. However, the user saying “Hey I got ‘Error: 0001′” means tech support can easily look it up and find the exact error message along with some troubleshooting steps to help resolve it.
It’s like the crab in the bearing sea dissappearing. You write code that assumes the crab are there because they have always been there. When they disappear you need an in depth analysis to figure out what the hell happened. Also writing ‘the crab aren’t there anymore’ isn’t useful to the user because crab is substituted for some deep technical issue that they won’t understand anyway.
Note, this isn’t always true. Sometimes you can just say, ‘your hard drive is full’ or ‘you need permission.’ sometimes bad developers don’t even handle those edge cases because it takes time and might not affect how much they earn for the project.
I have a UX answer. All of these developer answers are correct, minus a few minor details.
For example, a good error message does exactly what you suggest. It needs to–in plain language–say what’s wrong AND how to fix it.
The error code (0001) simply helps with diagnostics when troubleshooting and narrows down an error to a general theme. (Ie; Disk, DLL, etc).
Where errors get off the rails and become useless is that people in development environments might understand the technical jargon, OR, they assume the technical details matter to people “like them”, however, the majority of users aren’t technically inclined at all. That means technical professionals write messages that make sense to *themselves* since they are usually the ones programming the messages.
However, the “correct” way to write an error message is this: <What’s wrong><Why it happened.><What to do to fix it.>
So, this could be: “Installation failed: disk space full. Clear space on the drive and try again”.
In the event that we “don’t know what’s wrong”, then it could be “An Unexpected error occurred. Please try again. If the problem persists, contact support/the manual/etc.” Then there’s some details underneath an accordion, where you get “Error 738292-20472”. That second part is for when you finish doing the recommendation from part 1. The **important** aspect is that something went wrong and we aren’t sure what. The extra information (738292-20472) is only valuable if I’m looking for it, not glancing at it. So it can either be tucked away out of sight (but reachable) or reduced in visual hierarchy. This is a principle of balancing information that’s “meant to be discovered” versus “meant to be looked for.” Everything can’t be important all at once.
Errors should NEVER be sent to the user that A) Are purely jargon. B) Have no information nor C) have no action. But they often do, because the sheer number of errors that can possibly happen means they probably get written in a non-handmade way (you get errors grouped by numerical values or something like that) rather than having a UX person or team do the copy writing and experience design.
[removed]
Latest Answers