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.
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.
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 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.
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!
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.
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).
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.
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.
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.
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.
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.
