3 ms·

There's a school of thought that would say that by default, error messages shouldn't be a huge scary wall of text, because you have to consider that a majority

There's a school of thought that would say that by default, error messages shouldn't be a huge scary wall of text, because you have to consider that a majority of the people who would see an error message are not developers, and have no idea what to do with that information. It should certainly be possible for someone who can diagnose an error to see the details, but making it the default can be problematic when the message has a chance of being shown to real end users.

firethief 8y ago
That sounds like airbags in a car. On the majority of trips you don't need them, but their presence is of little consequence. When you do need them, you're out of luck if they're not there.
AnthonyMouse 8y ago
> There's a school of thought that would say that by default, error messages shouldn't be a huge scary wall of text, because you have to consider that a majority of the people who would see an error message are not developers, and have no idea what to do with that information. I think normal users have a pretty good idea what to do with it -- show it to the nearest tech person or paste it into Google. Just giving it to them up front makes things easier, not harder. They need help so they take a screenshot. If it contains the relevant information, someone can help them. If it just says "an error occurred" then nobody can help with that because it contains no information. Now they have to go back and have the tech walk them through trying to extract the information from some log file, which is seventeen clicks through an interface they've never used and now there are 5000 entries and they don't remember exactly what time it happened etc. It also deprives the user of any opportunity to learn. The user has a problem, they get a message, they ask the tech what to do and the tech tells them. Now the next time they get the same message they know what to do. But if the message is always the same regardless of the cause then they lose the ability to match known problems with known solutions and give up. Not all users care to learn that sort of thing, but you take it when you can get it, not purposely inhibit the user from doing it.
- afureta 8y ago
  Thank you for that perspective - I've never thought of it that way before. Would it be worth appending "if you don't know what this means, ask your local nerd"?
  - AnthonyMouse 8y ago
    Sure. You don't have to take over the whole screen with a gdb console they don't know how to use. Make the message as friendly as possible, but it still ought to actually contain the information necessary to identify what happened. I suspect the modern trend of making problems opaque comes from companies that do it on purpose. If the user can solve their own problems, what do they need with your expensive support contract? Why have the user fix problems with their existing device when you can sell them a whole new one the first time anything happens? And then other developers who don't even use those business models still cargo cult the same UX.

firethief 8y ago

That sounds like airbags in a car. On the majority of trips you don't need them, but their presence is of little consequence. When you do need them, you're out of luck if they're not there.

AnthonyMouse 8y ago

> There's a school of thought that would say that by default, error messages shouldn't be a huge scary wall of text, because you have to consider that a majority of the people who would see an error message are not developers, and have no idea what to do with that information. I think normal users have a pretty good idea what to do with it -- show it to the nearest tech person or paste it into Google. Just giving it to them up front makes things easier, not harder. They need help so they take a screenshot. If it contains the relevant information, someone can help them. If it just says "an error occurred" then nobody can help with that because it contains no information. Now they have to go back and have the tech walk them through trying to extract the information from some log file, which is seventeen clicks through an interface they've never used and now there are 5000 entries and they don't remember exactly what time it happened etc. It also deprives the user of any opportunity to learn. The user has a problem, they get a message, they ask the tech what to do and the tech tells them. Now the next time they get the same message they know what to do. But if the message is always the same regardless of the cause then they lose the ability to match known problems with known solutions and give up. Not all users care to learn that sort of thing, but you take it when you can get it, not purposely inhibit the user from doing it.

afureta 8y ago
Thank you for that perspective - I've never thought of it that way before. Would it be worth appending "if you don't know what this means, ask your local nerd"?
- AnthonyMouse 8y ago
  Sure. You don't have to take over the whole screen with a gdb console they don't know how to use. Make the message as friendly as possible, but it still ought to actually contain the information necessary to identify what happened. I suspect the modern trend of making problems opaque comes from companies that do it on purpose. If the user can solve their own problems, what do they need with your expensive support contract? Why have the user fix problems with their existing device when you can sell them a whole new one the first time anything happens? And then other developers who don't even use those business models still cargo cult the same UX.