3 ms·

This is true and yet I wonder how much more efficient it would be when they call me for help. “It said a bunch of gobbledygook that ended with dhcp timeout”, or

by rapind 6y ago

This is true and yet I wonder how much more efficient it would be when they call me for help. “It said a bunch of gobbledygook that ended with dhcp timeout”, or “it just says connection failed”.

bosie 6y ago
or have some sort of a middle ground. 'not connected. more info: blah #32893289327". Microsoft did something similar with an error code that you could google. that was super useful for debugging. the error message was in laymen terms though.
- Groxx 6y ago
  Makes things much easier to search for too, as those IDs don't need to change across languages or UI refreshes (which may e.g. rewrite the error messages, breaking all those old searchable phrases), both internally (unambiguous to grep!) and externally (google / stackoverflow / etc). And users are FAR more likely to read them back correctly to support, instead of saying what they think the message says (every tech-support-person has had to deal with this some number of times). Error IDs on everything, please.
recursive 6y ago
> “It said a bunch of gobbledygook that ended with dhcp timeout” I've done a little end-user support, and this is a pretty optimistic take on what you'd get. It would probably be more like "It didn't work." in both cases. Maybe you'd get "there was an error message" Q: What do you see on your screen? A: Nothing Q: Try again and tell me what happens. A: It didn't work and I still don't see anything. Many people have an automatic reactions to any kind of error or message. They get dismissed automatically. It seems that some people don't even realize they're doing it.
- cratermoon 6y ago
  The reason this happens is because users reason that if the program worked but had a problem, it would not show "an error". They see so many errors they can't do anything about, they just dismiss them and look at the non-erroring program for guidance. Users then see an "error" that pops up as being an error that's getting in the way of seeing the problem. A good program doesn't say "that was an error", because users are now habituated to assuming the error is nothing they can do about, and ignore it. A good program just gives feedback as if it were performing normally. A good program simply says, implicitly because it's not framed as a problem, "You wanted to do X and expected a Y but got a Z because.."

by rapind 6y ago

bosie 6y ago

or have some sort of a middle ground. 'not connected. more info: blah #32893289327". Microsoft did something similar with an error code that you could google. that was super useful for debugging. the error message was in laymen terms though.

Groxx 6y ago
Makes things much easier to search for too, as those IDs don't need to change across languages or UI refreshes (which may e.g. rewrite the error messages, breaking all those old searchable phrases), both internally (unambiguous to grep!) and externally (google / stackoverflow / etc). And users are FAR more likely to read them back correctly to support, instead of saying what they think the message says (every tech-support-person has had to deal with this some number of times). Error IDs on everything, please.

recursive 6y ago

> “It said a bunch of gobbledygook that ended with dhcp timeout” I've done a little end-user support, and this is a pretty optimistic take on what you'd get. It would probably be more like "It didn't work." in both cases. Maybe you'd get "there was an error message" Q: What do you see on your screen? A: Nothing Q: Try again and tell me what happens. A: It didn't work and I still don't see anything. Many people have an automatic reactions to any kind of error or message. They get dismissed automatically. It seems that some people don't even realize they're doing it.

cratermoon 6y ago
The reason this happens is because users reason that if the program worked but had a problem, it would not show "an error". They see so many errors they can't do anything about, they just dismiss them and look at the non-erroring program for guidance. Users then see an "error" that pops up as being an error that's getting in the way of seeing the problem. A good program doesn't say "that was an error", because users are now habituated to assuming the error is nothing they can do about, and ignore it. A good program just gives feedback as if it were performing normally. A good program simply says, implicitly because it's not framed as a problem, "You wanted to do X and expected a Y but got a Z because.."