When life gives you lemons, write better error messages

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.

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.

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.

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.

"Oh no, you broke reddit."

I didn't break it!!! Reddit is down and your server is overloaded.

My most blood boiling error message (long time ago, maybe they fixed it):

"No headset audio" -- displayed by the Oculus desktop app, in regards to not having audio on the headset. There's a "learn more" link, which would send you to the general troubleshooting FAQ.

So, the program knows something is wrong with the audio, but completely refuses to say what. Is it a headset problem, a driver problem, a restart needed!?

Then to make it more fun, when I complained about this stuff originally I got the advice to upload a debug log. Ok, good. That failed every time with "The upload took too long, connection was lost". I pulled out the dev tools and then I saw that what the API actually returns is:

    [{"error":"Attachment is too large. Limit 20 megabytes."}]

My mindframe about error messaging: Errors are just a form of routing decision. The quality of the error message lies in the destination, not the message itself.

I misread the title as "write bitter error messages", and that resonated with me deeply.

Long ago, I had the insight that not all users are equally technically proficient. Some had the chops to fix some problems if given sufficient information. Other users would be confused with too much detail.

I was writing code for AT&T (in the 1980s), and we were our own customer. So I wrote the error routines to check an environment variable and provide different error messages for different types of users: developers, testers, and a few power users got very detailed error messages, ordinary users got friendly, simplified messages (and weren't told about the environment variable).

(I can't read the first part of the title without hearing Cave Johnson)

(2022)

Prev discussions, Oct 2022, 250+ comments: https://news.ycombinator.com/item?id=33261125

Very good article, I've never given a big thought to my error messages, but clearly I should have. Going to snatch these rules and ideas!

I fail to understand why "Try again later" is considered bad because "Generic", but "Please try connecting again" is good because it's "Help them fix it". Likewise, it says "You changes were saved" is good because it "provides reassurance", but is it true ? The next sentence is "but we could not connect to your account", which could very well mean that the request didn't go through and the changes weren't saved. There's no way of knowing.

Yeah I really hate Microsoft's terrible error messages lately. "Something went wrong". Like on teams. Well yeah no shit. But tell me something that actually helps.

I'd also display an error ID to the user, which is tagged on the error log. That way engineers can instantly locate a detailed error log from a screenshot provided by the user.

If I had a LLM generate fake HN headlines, this would be one of them. Let's do better guys.

My favorite useless error message is in chrome/brave: `DNS_PROBE_POSSIBLE`.

If its possible, just do it?

(2022)

Readable link: https://archive.md/N1Eg9

[dead]

[flagged]

[dead]

[flagged]