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.<p>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.
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.<p>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.
They're not making any attempt to diagnose the problem; they're just reporting the error from the networking stack.<p>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?<p>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.<p>I often try to educate users: If you come to me with a problem and there is an error message <i>please</i> 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.
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.<p>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.<p>Making error messages too vague is not the best of ideas.
If my toaster doesn't work, I want the error message to be 'filament 3 is reporting a low resistance'.<p>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.<p>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.<p>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.<p>I don't think users should be molly-coddled.<p>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.<p>So really it seems to come down to 'this will help you sell better'. Not interested, sorry.
I've also found that with an older audience your choice of words can change their entire perception of what happened for the worse.<p>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.<p>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.
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 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 <i>extremely</i> situation dependent.<p>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.<p>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>".<p>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.<p>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.<p>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.
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.
[edit] My comment below has nothing to do with error messages.<p>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.<p>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 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.