I think the title conclusion is a bit off mark. This goes back to the simple maxim that you should never say "no" without providing an alternative. Don't say "i can't do this" without saying what you could do instead. Don't say "you can't do this" without saying what they could do instead.
There's also an inaccuracy in the replacement for the "timeout" message. It doesn't only look like the user isn't on the internet. It may also be that their server is down, in which case directing the user to their status page would be a good idea.
Making error messages too vague is not the best of ideas.
Conversely, there's a balance to be struck here. Non-specific error messages can be very annoying, as they are un-Googleable and provide no troubleshooting hints to a technical user.
I think the best approach is to give a user-friendly error message ('you're not connected to the internet: try this ...') as well as an error code, exception message or something similar.
I've long since stopped considering any error message as Googleable. The legions of keyword campers will snatch up any moderately frequent error message and use it to peddle their fix-it programs regardless of whether they can actually fix that particular problem. The only thing worse is trying to search for anything with the word "driver" in it.
Agreed. One of the problems I have with these error messages, is that they often diagnose the wrong problem. If the actual error is a timeout and they say "try restarting your modem", but the problem is really a dns error, restarting the modem won't necessarily fix it.
I think it's good to suggest "restarting your modem might help", as it is likely the problem, but give people the ability to look under the hood to find the real problem.
There's definitely a balance to be struck here. I work at a small company where I routinely get asked by the sales staff as to why the email is broken and their emails are getting rejected. I've explained a few times that when they're sending 10MB+ attachments, the other end of the email system has a rule saying "too big", and there's nothing we can do at our end. Use a link or use smaller attachments. "But it works fine for other recipients!". Yes, those email systems are administered by different groups.
This particular problem is not one that can be solved by hiding the details from the users; if they're not going to trust me when I say "just use sharing links, or if you have to, smaller attachments", then the users have to at least understand that email is a federated sytem, not a centralised system (perhaps not those exact terms, but the concepts).
But on the other hand, half the time when they come to me to have a return email error explained and it's sitting right there in plain sight as to why, it's also surrounded by paragraphs of boilerplate that only an admin can understand. I don't blame them in those cases when they don't successfully parse the only real English sentence in a couple of paragraphs of 'line noise'.
I can understand their argument. As the resident 'technology expert' in my various social and familial circles, I've had to deal with and explain the answers to questions such as "Why did my computer just become illegal?", and "What's a domain timeout?" various times. But things can go too far the other way, as well. When the guy who's job it is to understand the system and make it work is being frustrated by the error message, then you're doing it wrong.
IMO, a workable happy medium is the giving the ability to expand the error message to get the dirty operational details, an error code, or similar. That way, the support tech, power user, engineer, etc, dealing with "Why is the
Internet broken?", can have some data to help him figure out how to unbreak the Internet today.
Yeah, they've clearly gone too far the other way here. Their new error message is friendlier, sure, but it's also much less useful.
Don't force people to understand how the Internet works... but allow them to!
If there was a DNS problem and the app gave me that BS error at the end instead of telling me it's a DNS problem, I'd be a little angry. How am I supposed to troubleshoot that?
By all means, don't put "request timed out" front and center. But please make it available.
You could do it the Microsoft way: Have a generic friendly message with an error code attached. Then you can go online to look up the specific error code (sometimes there is a handy link in the error), and get an empty or broken page which was supposed to explain it.
Not much help if the device giving you the error is also your primary means of looking up error codes.
Would much rather the "more details" pattern where you have a link/button at the bottom of the error which actually explains it or gives access to the original error they were covering up.
> IMO, a workable happy medium is the giving the ability to expand the error message to get the dirty operational details, an error code, or similar. That way, the support tech, power user, engineer, etc, dealing with "Why is the Internet broken?", can have some data to help him figure out how to unbreak the Internet today.
Or write it to a user-accessible log file.
Opaque error messages that fail to accurately describe the problem out of a misguided desire to coddle users drive me bonkers.
They're not making any attempt to diagnose the problem; they're just reporting the error from the networking stack.
Phones need something similar to the Microsoft Network Troubleshooter. That starts testing from the computer outward. Is there a network device? Is it configured usefully? Is it on? Is it talking? is it reporting that it's connected to a transmission medium? Is the transmission medium in a good state? Is there somewhere we can get an IP address? Can we talk to it? Can we get an IP address? Is there a DNS server we can talk to? Can we talk to it? Can we talk to an alternate DNS server? Does it return sane results for a few known addresses? Can we get to some well known IP address? Can we get to the IP address we want? If we can't, how far can we get?
Something like that should be invoked when a program encounters a network error.
I totally understand the argument, but there is a catch: Sometimes the error message is not there to help the person using an application, but to let them pass it on to someone from a technical support.
I often try to educate users: If you come to me with a problem and there is an error message please give me the error message. Make a screenshot, make a picture and mail it to me, write it down. Unfortunately I still have a hard time convincing people that this makes sense.
Yup, all too often it goes like this when you're trying to troubleshoot something:
1.) User does something that causes error.
2.) Error message with instructions on what to do to fix error pops up.
3.) User clicks dismiss button on error message ten milliseconds after the message pops up.
4.) User ignores your request to do it again and FOR CRISSAKES, DON'T DISMISS THE MESSAGE. Instead starts randomly twiddling things and performing voodoo rituals.
5.) Try to get keyboard and mouse control from user through screensharing software. Software doesn't work and/or crashes.
You missed step 7) Finally get access to user's computer, watch them perform action then immediately dismiss error message box.
This is the most frustrating thing to me. I specifically told you what was wrong you just had to read it. THEN when you tell me that "It's broken" you are proving to me that you won't even TRY!
My best version of this was supporting a customer who had decided that the data source files were corrupt, in a part of the application workflow that doesn't access the files (an automatic 'preanalysis').
- Okay, so what does the error say > "The data files are corrupt".
- No, that doesn't sound right, can you please read it out word by word? > "The. Data. Files. Are. Corrupt.".
- I haven't seen that error before, can you please read it out letter by letter so I can ask the programmers > "a-u-t-o-m-a-t-i-c a-n-a-l-y-s-i-s h-a-s n-o-t...".
- Right, go here and tick the box that says 'enable automatic analysis'. Then it will work.
Yes, specifically asking to read word-by-word didn't work, I had to get down to letter-by-letter.
The supposed 95% literacy is a lie. Most people can't really read. They can usually identify individual words, but they can't do this fast enough and reliably enough to actually understand non-trivial sentences.
Someone I know actually did this to me a couple weeks back. They were all mad logging in to Gmail because they "forgot their password" when really it was just the screen that is asking you to confirm your recovery information. I said "No, LOOK at the screen. READ what it says" and they were like "Yeah, I forgot my f*ing password!" I said "NO. REEEAAD." and they got mad at me until I pulled their hand from the mouse that was about to click the x button and read it for them. They were like "oh.." I was like "yeah.. REEEAD..."
[edit] My comment below has nothing to do with error messages.
Personally, I dream of the day when middle school kids laugh when a bank website doesn't require 2 factor authentication and understand how a brute force attack works.
Any child understands if you allow someone to try thousands of door keys to enter your house, eventually one key will work. Why hide that simple concept for computer logins?
Because for many non-technical users, using a computer or anything
computer-related automatically disables thinking. Using a computer boils often
down to waving a magic chicken, performing a ritual, and then the computer
does what it was istructed to. (Or not, and this is where people call support.)
I actually saw this several times on myself with regard to something I knew
I know nothing about, i.e. power tools. I avoided them like a plague, because
I knew I don't know how to use any of them at all. I needed to be taught
a little how to use power tools (mainly: how they cause accidents and harm).
Well you could get the best of both worlds. Just have a friendly message (general) for the non-technical user, but have some kind of error code/hash (specific) that they can pass on to support and make it easily google-able.
I've also found that with an older audience your choice of words can change their entire perception of what happened for the worse.
In one of my apps, my error message had "error" in it. While it was an error, their perception was that the app itself was flawed. I removed the word "error" and re-worked the copy similar to this article and I no longer have the support issues.
>> For everyone else, however, our support load indicated that the errors were completely unintelligible: people didn’t understand what “timed out” meant or why a “hostname might not be verified”. All they saw was a cryptic message and no solution to move forward.
I don't see the problem. They did have a way to move forwards. They called tech support. Faced with something they did not understand, they elevated the problem to someone who did. Dumbing down error messages leads to "engine lights" whereby any number of actionable errors are replaced with a single indicator. This deprives savvy users of the ability to take action, and deprives the less-savvy of the opportunity to learn.
I do think that you should educate people on moral aspects of internet and how they can protect themselves against all aspects of the internet that takes away your privacy.
If my toaster doesn't work, I want the error message to be 'filament 3 is reporting a low resistance'.
Limited by time, I want to know how everything works. In this particular case, I can decide whether to buy a new toaster or whether to try and fix it.
If I'm Donald Trump I'll pay someone else to sort it. (Maybe I'm not even using the toaster to begin with). If I have masses of free time, I've been given the information to sort it out or at least to contact someone who can sort it out.
Will that get me the most sales for my product under capitalism? Possibly not. I do think it's the morally correct thing to do, though.
I don't think users should be molly-coddled.
I just don't really... understand it. Knowledge is a _good thing_. The only reason I wouldn't want to learn something is if I'm limited by time. And I don't really particularly want to surround myself with people who aren't interested in knowledge either.
So really it seems to come down to 'this will help you sell better'. Not interested, sorry.
So what does 'hostname is not verified' mean? Is that a DNSSEC error? An error that that host isn't allowed? A certificate error that doesn't mention certificates? It's a bad error message even for someone that understands how the Internet works.
I am going to echo the sentiment of a lot of other comments here, but, while well-intentioned, trying to interpret errors and present them in a "user friendly" format is extremely situation dependent.
As an example, I had delivered an internal application for a client that interfaced with a third-party system that was also deployed internally and maintained by the client's technical staff. My application was primarily used by other, non-technical staff.
Occationally, my application would get an error message from the other system and we would report an error with content like, "A problem occurred with <other server> while trying to <action>. Please report to <technical staff>. Error: <insert error message>".
The problem is that the non-technical staff complained that the error message was "too hard to understand" and my PM initially asked me to, essentially, reinterpret the errors from the third-party server to make them more understandable.
I pointed out that the errors in the third party system were not documented, had no error code attached to them, and would put us in the position of perpetual maintainance as the long-tail of previously-unseen errors poped up over time. Not to mention the fact that error messages could radically change as the third-party server was updated over time.
Fortunately, my argument was convincing and we avoided stepping into an unbounded tar pit of uncompensated development time, all in the name of making things "easier" for the end user.
30 comments
[ 3.3 ms ] story [ 80.8 ms ] threadThere's also an inaccuracy in the replacement for the "timeout" message. It doesn't only look like the user isn't on the internet. It may also be that their server is down, in which case directing the user to their status page would be a good idea.
Making error messages too vague is not the best of ideas.
I think the best approach is to give a user-friendly error message ('you're not connected to the internet: try this ...') as well as an error code, exception message or something similar.
I think it's good to suggest "restarting your modem might help", as it is likely the problem, but give people the ability to look under the hood to find the real problem.
This particular problem is not one that can be solved by hiding the details from the users; if they're not going to trust me when I say "just use sharing links, or if you have to, smaller attachments", then the users have to at least understand that email is a federated sytem, not a centralised system (perhaps not those exact terms, but the concepts).
But on the other hand, half the time when they come to me to have a return email error explained and it's sitting right there in plain sight as to why, it's also surrounded by paragraphs of boilerplate that only an admin can understand. I don't blame them in those cases when they don't successfully parse the only real English sentence in a couple of paragraphs of 'line noise'.
IMO, a workable happy medium is the giving the ability to expand the error message to get the dirty operational details, an error code, or similar. That way, the support tech, power user, engineer, etc, dealing with "Why is the Internet broken?", can have some data to help him figure out how to unbreak the Internet today.
Don't force people to understand how the Internet works... but allow them to!
If there was a DNS problem and the app gave me that BS error at the end instead of telling me it's a DNS problem, I'd be a little angry. How am I supposed to troubleshoot that?
By all means, don't put "request timed out" front and center. But please make it available.
Would much rather the "more details" pattern where you have a link/button at the bottom of the error which actually explains it or gives access to the original error they were covering up.
Or write it to a user-accessible log file.
Opaque error messages that fail to accurately describe the problem out of a misguided desire to coddle users drive me bonkers.
Phones need something similar to the Microsoft Network Troubleshooter. That starts testing from the computer outward. Is there a network device? Is it configured usefully? Is it on? Is it talking? is it reporting that it's connected to a transmission medium? Is the transmission medium in a good state? Is there somewhere we can get an IP address? Can we talk to it? Can we get an IP address? Is there a DNS server we can talk to? Can we talk to it? Can we talk to an alternate DNS server? Does it return sane results for a few known addresses? Can we get to some well known IP address? Can we get to the IP address we want? If we can't, how far can we get?
Something like that should be invoked when a program encounters a network error.
I often try to educate users: If you come to me with a problem and there is an error message please give me the error message. Make a screenshot, make a picture and mail it to me, write it down. Unfortunately I still have a hard time convincing people that this makes sense.
1.) User does something that causes error.
2.) Error message with instructions on what to do to fix error pops up.
3.) User clicks dismiss button on error message ten milliseconds after the message pops up.
4.) User ignores your request to do it again and FOR CRISSAKES, DON'T DISMISS THE MESSAGE. Instead starts randomly twiddling things and performing voodoo rituals.
5.) Try to get keyboard and mouse control from user through screensharing software. Software doesn't work and/or crashes.
6.) Cry and head-desk.
This is the most frustrating thing to me. I specifically told you what was wrong you just had to read it. THEN when you tell me that "It's broken" you are proving to me that you won't even TRY!
- Okay, so what does the error say > "The data files are corrupt".
- No, that doesn't sound right, can you please read it out word by word? > "The. Data. Files. Are. Corrupt.".
- I haven't seen that error before, can you please read it out letter by letter so I can ask the programmers > "a-u-t-o-m-a-t-i-c a-n-a-l-y-s-i-s h-a-s n-o-t...".
- Right, go here and tick the box that says 'enable automatic analysis'. Then it will work.
Yes, specifically asking to read word-by-word didn't work, I had to get down to letter-by-letter.
Someone I know actually did this to me a couple weeks back. They were all mad logging in to Gmail because they "forgot their password" when really it was just the screen that is asking you to confirm your recovery information. I said "No, LOOK at the screen. READ what it says" and they were like "Yeah, I forgot my f*ing password!" I said "NO. REEEAAD." and they got mad at me until I pulled their hand from the mouse that was about to click the x button and read it for them. They were like "oh.." I was like "yeah.. REEEAD..."
Personally, I dream of the day when middle school kids laugh when a bank website doesn't require 2 factor authentication and understand how a brute force attack works.
Any child understands if you allow someone to try thousands of door keys to enter your house, eventually one key will work. Why hide that simple concept for computer logins?
I actually saw this several times on myself with regard to something I knew I know nothing about, i.e. power tools. I avoided them like a plague, because I knew I don't know how to use any of them at all. I needed to be taught a little how to use power tools (mainly: how they cause accidents and harm).
In one of my apps, my error message had "error" in it. While it was an error, their perception was that the app itself was flawed. I removed the word "error" and re-worked the copy similar to this article and I no longer have the support issues.
I don't see the problem. They did have a way to move forwards. They called tech support. Faced with something they did not understand, they elevated the problem to someone who did. Dumbing down error messages leads to "engine lights" whereby any number of actionable errors are replaced with a single indicator. This deprives savvy users of the ability to take action, and deprives the less-savvy of the opportunity to learn.
Limited by time, I want to know how everything works. In this particular case, I can decide whether to buy a new toaster or whether to try and fix it.
If I'm Donald Trump I'll pay someone else to sort it. (Maybe I'm not even using the toaster to begin with). If I have masses of free time, I've been given the information to sort it out or at least to contact someone who can sort it out.
Will that get me the most sales for my product under capitalism? Possibly not. I do think it's the morally correct thing to do, though.
I don't think users should be molly-coddled.
I just don't really... understand it. Knowledge is a _good thing_. The only reason I wouldn't want to learn something is if I'm limited by time. And I don't really particularly want to surround myself with people who aren't interested in knowledge either.
So really it seems to come down to 'this will help you sell better'. Not interested, sorry.
As an example, I had delivered an internal application for a client that interfaced with a third-party system that was also deployed internally and maintained by the client's technical staff. My application was primarily used by other, non-technical staff.
Occationally, my application would get an error message from the other system and we would report an error with content like, "A problem occurred with <other server> while trying to <action>. Please report to <technical staff>. Error: <insert error message>".
The problem is that the non-technical staff complained that the error message was "too hard to understand" and my PM initially asked me to, essentially, reinterpret the errors from the third-party server to make them more understandable.
I pointed out that the errors in the third party system were not documented, had no error code attached to them, and would put us in the position of perpetual maintainance as the long-tail of previously-unseen errors poped up over time. Not to mention the fact that error messages could radically change as the third-party server was updated over time.
Fortunately, my argument was convincing and we avoided stepping into an unbounded tar pit of uncompensated development time, all in the name of making things "easier" for the end user.