by jessepollak on 2/26/16, 7:43 PM with 30 comments
by korethr on 2/26/16, 8:44 PM
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.
by rossng on 2/26/16, 8:30 PM
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.
by Animats on 2/26/16, 10:02 PM
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.
by hannob on 2/26/16, 10:03 PM
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.
by Mithaldu on 2/26/16, 8:17 PM
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.
by stegosaurus on 2/27/16, 3:22 PM
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.
by exclusiv on 2/27/16, 1:31 AM
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.
by sandworm101 on 2/27/16, 1:39 AM
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.
by ksk on 2/27/16, 1:16 AM
by lscharen on 2/27/16, 6:56 PM
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.
by Dylan16807 on 2/27/16, 5:03 PM
by utefan001 on 2/26/16, 10:03 PM
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?
by mattedwards984 on 2/27/16, 9:25 AM