No wonder the world is falling apart.
Should error messages apologize? (2013)
71–80 of 262 posts
Re: Should error messages apologize? (2013)
#72I don't even like "We" in UI messages. "We couldn't find that site." "We're just updating your computer." Perhaps I'm just an old fogey, but passive voice feels like the only right choice: "The site could not be found." "Your computer is being updated." The insertion of "We" feels like an imposition; the company who wrote the code reaching in and enacting their will with your equipment, using your screen as their soa…
Re: Should error messages apologize? (2013)
#73I don't even like "We" in UI messages. "We couldn't find that site." "We're just updating your computer." Perhaps I'm just an old fogey, but passive voice feels like the only right choice: "The site could not be found." "Your computer is being updated." The insertion of "We" feels like an imposition; the company who wrote the code reaching in and enacting their will with your equipment, using your screen as their soa…
Re: Should error messages apologize? (2013)
#74I don't know why we do it frankly - when there are real humans one can talk to, rather than pretending one is having a meaningful exchange with a website or advert.
Re: Should error messages apologize? (2013)
#75I don't even like "We" in UI messages. "We couldn't find that site." "We're just updating your computer." Perhaps I'm just an old fogey, but passive voice feels like the only right choice: "The site could not be found." "Your computer is being updated." The insertion of "We" feels like an imposition; the company who wrote the code reaching in and enacting their will with your equipment, using your screen as their soa…
It can be worrying too, those Windows updates where you have a blank screen with something like "We're getting your files". Could be interpreted the wrong way...
Re: Should error messages apologize? (2013)
#76Honestly, no. An error message shouldn't apologize. A good error message has the following conditions: * Concise. ("You need to enter a number in this field, not text" = Good, "we're very sorry but we can't understand it if you write your age in text" = Bad). * Clearly telling the user what went wrong without relying on technical jargon. The line number where something went wrong doesn't need to be in an error messag…
Error messages this general become slightly annoying when the app doesn't respond intelligently to all possible scenarios that its wording might imply.
For example, if the field only parsed numeric digits, and failed on inputs like "12.5" or "3e1" because they contained the characters "e" or ".", then they should have written something like "Only numeric characters are accepted," or "The number must consist only of digits (0-9)," since it rejected valid numbers. The app is saying I need to enter a number, but I did enter a number, and it's just too primitive to recognize it.
Re: Should error messages apologize? (2013)
#77Re: Should error messages apologize? (2013)
#78I suspect there are cultural preferences here, there's no reason to believe there's one correct answer for all of humanity. I'm from the US but I've traveled to places where it's considered rude to say "no" directly and apologies aren't common. Like when trying to order an unavailable item from a menu: - I'd like the beef burger - The chicken burger is very good - That's OK, can I have the beef burger? - Our hot dogs…
> We're in a thought bubble otherwise "HN commenter" is already a much tighter bubble than "the West".
Re: Should error messages apologize? (2013)
#79No, error messages should tell the user what they need to do to accomplish their goal as concisely as possible.
A library discovering a mismatch between a configuration setting and a value it received by API isn't in a position to make a decision on which is wrong: is it misconfigured, or is the value it received via API under the control of the user?
The caller of the API isn't necessarily in a better place to make a decision. The higher up the stack you go, the more context you have on the action the user is trying to perform but the number of potential errors increases exponentially. It's usually not feasible to contextualize every possible error condition, particularly for things like configuration which are side-loaded while executing code and are a library implementation detail from the perspective of the application writer.
Consider access denied to a file: is this a user mistake or a permission mistake? Should the user change the file permissions, or not try to access that file?
Consider quota exceeded while writing to a file: should the user free up space, create a smaller file, or ask their administrator to give them more space?
What if the quota was exceeded due to a configuration setting in the application specifying where to put scratch files?
It gets very complicated very quickly, and even the simplest of actions - like writing a byte out to a file - have errors that require global knowledge to give good actionable feedback on.