Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When life gives you lemons, write better error messages

wix-ux.com

Post reply on HN
Print view View original

31–40 of 72 posts

Re: When life gives you lemons, write better error messages

#31

Post by dale_glass »

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."}]
Bloody infuriating. They built a system that translates sensible errors into completely useless ones.

Re: When life gives you lemons, write better error messages

#32

Post by bombcar »

dale_glass wrote: post #31

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!?…

Atlassian of all people did this right - you can upload a support zip and it warns if it’s large (do you want to try?) and gives you the option of (basically) the last 10/20 MB of logs to send instead.

Re: When life gives you lemons, write better error messages

#33

Post by protocolture »

dmd wrote: post #17
ozim wrote: post #16

Earlier quoted context omitted.

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.

I have seen the mailboxe folderss of companies with automated error responses and none of them were read.

Re: When life gives you lemons, write better error messages

#35

Post by hungryhobbit »

scottlamb wrote: post #29
ragall wrote: post #28

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. Ther…

Had the exact same thoughts. * I thought at first they meant "later" was too vague, but omitting the word only makes the message more terse, not more specific. It's as if they decided ahead of time that the old message was bad and embodies certain qualities (which they highlighted) and the new was good and embodies certain other qualities (also highlighted), and they didn't bother to rethink the new one after seeing…

I was so excited when I started the article: this person has thought hard about what makes a good error message and a bad error message. I was so excited to learn!

But it turns out they were completely full of it, and have absolutely no idea what separates a good/bad message. Quite disappointing.

Re: When life gives you lemons, write better error messages

#36

Post by heocoi »

Hit a fresh case of this last week porting an Astro layout. Wrote a literal `{` inside a `
` code block. Build crashed with "Expected `}` but found `:`" pointing to a line:col that didn't exist in the source file. Took 20 minutes to realize the position was from the compiled JS output, not my .astro file. Fix was escaping to {. The error wasn't wrong, just orphaned from the user's mental model of where the bug lives.

Re: When life gives you lemons, write better error messages

#37

Post by t-writescode »

Insanity wrote: post #26
magicalhippo wrote: post #2

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 hard…

IMO if you show an error to end users it needs to be actionable. Tell them what to do instead (e.g retry or wait, use other input file, etc etc). So don't say "InvalidArgumentException xyz", say "Expected a number but got 'hello'". This doesn't always work, but essentially hide tech details from users. If you must, include a bit of extra information (a request number or whatever) that helps you log dive.

Maybe in the UX; but for the love of all things, please shove that data in a user-accessible error log, with enough verbosity that someone could debug it themselves.

I am so tired of having to submit a HUGE FUCKING FILE that includes a ton of PII to customer support, only for them to ask the same “did you try uninstalling and reinstalling the app?” (Yes.) afterward.

Re: When life gives you lemons, write better error messages

#38

Post by [deleted] »

Insanity wrote: post #26
magicalhippo wrote: post #2

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 hard…

IMO if you show an error to end users it needs to be actionable. Tell them what to do instead (e.g retry or wait, use other input file, etc etc). So don't say "InvalidArgumentException xyz", say "Expected a number but got 'hello'". This doesn't always work, but essentially hide tech details from users. If you must, include a bit of extra information (a request number or whatever) that helps you log dive.

[deleted]
Post reply on HN