Live data from Hacker News

When life gives you lemons, write better error messages

wix-ux.com

61–70 of 72 posts

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

#61
post #59

Earlier quoted context omitted.

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.

The action on an unhandled / unexpected exception is “please submit this information to your closest administrator” And then dump whatever you want, with a copy button

Then you find the bug report form was deactivated and the message never being updated.

So your now stuck with an error and no where to report it to.

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

#64
post #10

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

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…

IBM have been doing this for centuries, each error comes with a code you can look up for more information. Although this is probably way too late, all nix/nux utilities should come with either a magic ID string you can copy into Google to find all the other people baffled by the same error message ("Quadrant change in relocatable expression", that's an actual error message), or just an option to launch a browser with said info, because the message itself ain't giving you anything to go on.

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

#65

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

Hopefully but seems unlikely. The example good error message wix-ux provides still has near zero context.

Yes, but it's reassuring, and has the words "DON'T PANIC" in large, friendly letters on the cover.

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

#68
post #17
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.

The only place I've worked that logged out technical details (inside of a element) was also the one that did the best with logging those in Bugsnag and then having engineers triage them and create tickets. I think those things are very connected.

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

#70
post #48

Earlier quoted context omitted.

As someone who is a penetration tester, I can assure you that this is a TERRIBLE idea. Look up "CWE-200". While you are correct that this might help someone fix an issue, I can assure you it will help MANY more people to understand the technology stack you are working with and allow them to exploit unpatched vulnerabilities in your tech stack.

And all these years I was told security through obscurity wasn't a thing... I work on desktop applications. Tech stack is visible to anyone who can see the error message. If you got a web-based SaaS sure I understand your position, but then you spit all that good stuff into a log and have the error message include the relevant log ids so support can easily find it. If something bad happens while loading a file, inclu…

You're right, this is more for web applications than for desktop applications.
Post reply on HN