Anyway, I disagree strongly on the technical jargon. Ok, if it's not really an error and the user can retry or similar sure.
But if it's bad times, an exception or similar, don't care about the user. Instead include as much detail as you need. A non-technical user won't be able to do anything anyway, and a sanitized error message means support or a technical user has a much harder time figuring out what the real issue might be, in order to work around it.
Failed to load a shared library? State the filename and exact error code and message, and anything else that might be useful. And so on.
Agreed, but you can have both. A simple error for the user to understand, and a click for more details that spits out all the troubleshooting information.
If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user. User should get “our support team received the error” and support should handle it directly.
“Something went wrong, try again later” is also acceptable but only if support team gets info about it and user really ca just try later.
I have approximately zero confidence that if I see an error message that says "our support team received the error" that anyone has received the error.
In fact I would generally bet thousands of dollars against that.
I think it’s a good thought but we’ve been conditioned that these things are black holes. User should have all agency in escalating or continuing troubleshooting rather than implied wait for deus ex machina from the support team.
I've done this to myself because I was too lazy to write the `fmt!()` instead of the raw string while I was iterating and then just forgot to fix it later. I think the Go logger's default of accepting chained parameters that it logs by default to JSONL worked well to avoid that. Convenient ergonomics just in time (in the cosmic sense of programming) for it all to be irrelevant because an LLM always puts it in the error string.
Depends on exactly the situation- when I worked on a very expensive desktop application years ago I was warned about giving too much information in error messages as it might help crackers.
With how powerful Ghidra is now, I'm not sure that it matters much any more.
> Depends on exactly the situation- when I worked on a very expensive desktop application years ago I was warned about giving too much information in error messages as it might help crackers.
As a sysadmin (having spent 30 years dealing with desktop software) the attitude of the people who gave you that direction make me seethe with anger. Crackers gonna crack. That just hurts the people who have to make the product work in their environment.
Just yesterday I completely reverse engineered several proprietary audio codecs from a game without even having to touch the static analysis tool myself.
I think this post has some interesting points, but it kinda misses a few more as well.
First, appropriate tone depends heavily on the product or service in question. A bank or otherwise serious business should probably not be giving messages like "whoops, something went wrong". But an entertainment product could have those sorts of messages, and treat it as part of the overall experience.
Secondly, I'm not a huge fan of error messages that don't give actionable feedback for how to fix the issue. Yes, a lot of users don't need that sort of information, but some sort of error code or technical reference can be handy for more involved support processes.
So, if the product or service is business orientated, maybe have that info in a dropdown box or something, where a support agent can ask the user to find it if an issue keeps occurring. And of course, if the product or service is aimed at technical people (like an open source infrastructure project), maybe just skip the casual language and just get to the point.
Hopefully this becomes a reversal in the trend of giving less and less context to the user.
I'm not against the considerations of the article regarding the user and its state of mind, but please do add as much technical detail as possible!
Even if an error message is a cryptic error code, that's better than a "Something went wrong" message. This is not better, or even friendlier, UX. An error code can be referenced, can be searched on the internet, can be passed around on a ticket or on a call... add parameters to your error template, reference the name of the file, the item name that does not respond, the HTTP error code... just give the user some transparency, some agency. Help the client build up a mental model of the error: when / how / why might it be happening.
I'm somewhat fond of including a UUID for that reason. As long as they can copy-paste it into Google, they can get results that are precisely the errors from your application, unlike "error 55324". The same works internally: zero ambiguity which system it came from, and it's trivial to find the full history of the error (message). It's not great for verbally communicating tho.
But yes, I can get behind making things nicer to read and less technically scary, but include enough detail so that people can solve their own problems if needed. There's a decent chance that the software will outlive your desire to support it.
You can certainly learn a bit about how a company thinks about UX, accessibility, and its users more broadly by looking at its error messages. Although I didn't care for much of the specifics proposed, I am glad about this post as I think it is important to think through error messages with intention and treat them as products in their own right.
Regarding the proposed "good" alternative, it has less actionable information than the original "bad" message, depending on what the product is and who its users are. In particular, you can't determine whether "fetch data" is impenetrable jargon without looking at the product itself and its users.
I also frequently see people use the designation of a user as non-technical as an excuse to dismiss their intelligence. It's true that tech folks generally underestimate how confusing computers and software are to the average person, but erring too heavily in the other direction also has negative impacts for accessibility. Either way, you can at least hide away that extra detail, with jargon and all, using that link tip she mentioned.
Finally, this writer seems to overestimate the extent to which most users view "contact Customer Care" as "giving them a way out" and not an invitation for further aggravation.
Error: File not found
Which file?!?!?!
Anyway, I disagree strongly on the technical jargon. Ok, if it's not really an error and the user can retry or similar sure.
But if it's bad times, an exception or similar, don't care about the user. Instead include as much detail as you need. A non-technical user won't be able to do anything anyway, and a sanitized error message means support or a technical user has a much harder time figuring out what the real issue might be, in order to work around it.
Failed to load a shared library? State the filename and exact error code and message, and anything else that might be useful. And so on.
Agreed, but you can have both. A simple error for the user to understand, and a click for more details that spits out all the troubleshooting information.
It depends.
If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user. User should get “our support team received the error” and support should handle it directly.
“Something went wrong, try again later” is also acceptable but only if support team gets info about it and user really ca just try later.
I have approximately zero confidence that if I see an error message that says "our support team received the error" that anyone has received the error.
In fact I would generally bet thousands of dollars against that.
> “our support team received the error”
Oh good, I guess I’ll expect to hear back never.
I think it’s a good thought but we’ve been conditioned that these things are black holes. User should have all agency in escalating or continuing troubleshooting rather than implied wait for deus ex machina from the support team.
I've done this to myself because I was too lazy to write the `fmt!()` instead of the raw string while I was iterating and then just forgot to fix it later. I think the Go logger's default of accepting chained parameters that it logs by default to JSONL worked well to avoid that. Convenient ergonomics just in time (in the cosmic sense of programming) for it all to be irrelevant because an LLM always puts it in the error string.
Depends on exactly the situation- when I worked on a very expensive desktop application years ago I was warned about giving too much information in error messages as it might help crackers.
With how powerful Ghidra is now, I'm not sure that it matters much any more.
> Depends on exactly the situation- when I worked on a very expensive desktop application years ago I was warned about giving too much information in error messages as it might help crackers.
As a sysadmin (having spent 30 years dealing with desktop software) the attitude of the people who gave you that direction make me seethe with anger. Crackers gonna crack. That just hurts the people who have to make the product work in their environment.
Static analysis tools + MCP server + a debugger with an MCP server makes reverse engineering incredibly easy and low-cost.
I wrote a blog post about this recently: https://landaire.net/reverse-engineering-with-ai/
Just yesterday I completely reverse engineered several proprietary audio codecs from a game without even having to touch the static analysis tool myself.
This is security through obscurity -- can complement other methods but won't do much for you against competent adversaries.
I think this post has some interesting points, but it kinda misses a few more as well.
First, appropriate tone depends heavily on the product or service in question. A bank or otherwise serious business should probably not be giving messages like "whoops, something went wrong". But an entertainment product could have those sorts of messages, and treat it as part of the overall experience.
Secondly, I'm not a huge fan of error messages that don't give actionable feedback for how to fix the issue. Yes, a lot of users don't need that sort of information, but some sort of error code or technical reference can be handy for more involved support processes.
So, if the product or service is business orientated, maybe have that info in a dropdown box or something, where a support agent can ask the user to find it if an issue keeps occurring. And of course, if the product or service is aimed at technical people (like an open source infrastructure project), maybe just skip the casual language and just get to the point.
Hopefully this becomes a reversal in the trend of giving less and less context to the user.
I'm not against the considerations of the article regarding the user and its state of mind, but please do add as much technical detail as possible!
Even if an error message is a cryptic error code, that's better than a "Something went wrong" message. This is not better, or even friendlier, UX. An error code can be referenced, can be searched on the internet, can be passed around on a ticket or on a call... add parameters to your error template, reference the name of the file, the item name that does not respond, the HTTP error code... just give the user some transparency, some agency. Help the client build up a mental model of the error: when / how / why might it be happening.
I'm somewhat fond of including a UUID for that reason. As long as they can copy-paste it into Google, they can get results that are precisely the errors from your application, unlike "error 55324". The same works internally: zero ambiguity which system it came from, and it's trivial to find the full history of the error (message). It's not great for verbally communicating tho.
But yes, I can get behind making things nicer to read and less technically scary, but include enough detail so that people can solve their own problems if needed. There's a decent chance that the software will outlive your desire to support it.
You can certainly learn a bit about how a company thinks about UX, accessibility, and its users more broadly by looking at its error messages. Although I didn't care for much of the specifics proposed, I am glad about this post as I think it is important to think through error messages with intention and treat them as products in their own right.
Regarding the proposed "good" alternative, it has less actionable information than the original "bad" message, depending on what the product is and who its users are. In particular, you can't determine whether "fetch data" is impenetrable jargon without looking at the product itself and its users.
I also frequently see people use the designation of a user as non-technical as an excuse to dismiss their intelligence. It's true that tech folks generally underestimate how confusing computers and software are to the average person, but erring too heavily in the other direction also has negative impacts for accessibility. Either way, you can at least hide away that extra detail, with jargon and all, using that link tip she mentioned.
Finally, this writer seems to overestimate the extent to which most users view "contact Customer Care" as "giving them a way out" and not an invitation for further aggravation.
"Oh no, you broke reddit."
I didn't break it!!! Reddit is down and your server is overloaded.
(I can't read the first part of the title without hearing Cave Johnson)
You're right, all error messages should be voiced by Cave Johnson.
(2022)