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

Write better error messages

wix-ux.com

Post reply on HN
Print view View original

61–70 of 265 posts

Re: Write better error messages

#61

Post by vbezhenar »

grandinj wrote: post #27

Probably just me, but I am less concerned with how good my error messages are, and more concerned with trying very very hard to make the errors happen closer to the cause of the problem, rather than further away. "Fail early, fail hard" i.e. if I can make the error message happen near the beginning of a process, I can get away with making it a hard error. Hard errors in the middle of a multi-hour operation tend to an…

Exactly. Software must crash as soon as possible and include some context information which is necessary to further debug the problem.

Re: Write better error messages

#62

Post by kortex »

mariusmg wrote: post #17
zagrebian wrote: post #8

Earlier quoted context omitted.

This just means that the error message needs to be more clear. For example, after the error itself, it could give direct advice: “PERFORM THESE STEPS: You must define ENVVAR. Go to . Set ENVVAR to a proper value and restart the service.” Notice the direct language. It reads like an order. The less direct the message, the higher the chances that the user will not act upon it.

>it could give direct advice: “PERFORM THESE STEPS: You must define ENVVAR. Go to . Set ENVVAR to a proper value and restart the service.” Really, should logs also be documentation now ? Just mindlessly logging the same "advice" over and over again each time the error happen ?

It depends who, what, and when the error is about. Failures are generally a bathtub curve. You have a high rate at start (usually configuration issues), some fairly fixed rate during operation, and then more at end of lifecycle (exhaustion, service hiccups on scale-in).

If it's in the early lifecycle, absolutely, because it's most actionable. X is set wrong, Y can't be reached, etc, guide whoever is operating the system how to fix it.

If it's mid cycle, it's often post-hoc, but context is worth its weight in gold. Less about telling the operator how to fix and more about why it broke, to avoid in the future.

End of cycle, whatever.

Re: Write better error messages

#63

Post by bartread »

grandinj wrote: post #22
hprotagonist wrote: post #3

I would, if i had any evidence at all that they would be read and acted on. I’m convinced even seemingly competent people are just rendered contextually blind by the appearance of any error at all. In the past month, i’ve had about a dozen interactions like this: developer: your service crashed, here’s a screenshot of the last 5 lines of the crash me: do you see where the final text you just pasted is “RuntimeError:…

Some developers are just lazy, and will likely need some kind of negative feedback to force them to confront their own laziness. Which can be tricky, because the degree of negative feedback that is appropriate to the person in question can range from "Polite one-on-one suggestion that you read the error message more than once before calling me" to "Full on yelling at the person in the middle of an open-plan office".…

> Some developers are just lazy

I'm really lazy: if I were on the receiving end of emails with error messages that included instructions about how to fix said error I'd automate Freshdesk (or whatever ticketing system I was using) to respond with instructions specific to that error message, in the first instance, along with a note to get in touch again if that didn't solve the problem. I'd also set the ticket to autoresolve after a set period of time.

Re: Write better error messages

#64

Post by [deleted] »

londons_explore wrote: post #19

A big part of this is to direct more of your development time into errors that happen more frequently. Most systems I was involved in designing have some kind of error tracking system, so we can know exactly how often each error occurs. An error that never happened needs (usually) no attention. An error that 28% of installations have seen needs a lot of attention. The error text should be translated into local langua…

[deleted]

Re: Write better error messages

#65

Post by madeofpalk »

tiborsaas wrote: post #51
grandinj wrote: post #27

Probably just me, but I am less concerned with how good my error messages are, and more concerned with trying very very hard to make the errors happen closer to the cause of the problem, rather than further away. "Fail early, fail hard" i.e. if I can make the error message happen near the beginning of a process, I can get away with making it a hard error. Hard errors in the middle of a multi-hour operation tend to an…

That's not really a respectful practice. Error messages should be clear and actionable. Users don't care if you consider an error soft or hard.

I think the point is that the higher up you fail, the harder it is to identify why you errored in order to give the user clear and actionable feedback.

Re: Write better error messages

#66

Post by duxup »

For me error messages come in two forms.

1. For the user.

You can't do that (maybe explain why). Don't do that.

2. Error that's actually there for the support or engineering team for a customer to convey to support, probably with a handy copy to clipboard link (that the user has at best a 50/50 chance of using no matter how much prodding).

That's it.

Humans generally lock up hard when they see an error in my experience. No amount of information or hand holding will help most of them figure it out. It's better to try to solve it in software.

If the software can't fix the issue internally then they get an error message and 2 things happen:

1. The user is going to try something else and solve it themself (awesome) regardless of the error because they're smart and capable people and could probably solve it no matter what you told them.

2. Their brain locks up, they do the same thing 20 times and get the same result and complain to support with some form of "doesn't work". Doesn't matter what error you give them, they won't even try to tell you what the error was / doesn't register in their brain unless it had a cute cat on it or something (that actually works... so forget this "tone" stuff).

I like the article, but I am skeptical about a UX team who doesn't answer support tickets ... just magically knows what the user is thinking / will work. I get lots of advice on error messages, I change them when they ask, but when it's from folks inside the company who know the product it often isn't helpful.

Heck even users give bad advice about errors. I've had them tell me "Well it should have said X" where X is exactly word for word what it said (they forgot...).

Granted I still try to help the user along, but I'm skeptical that software with any large user base can have "good" error messages.

Re: Write better error messages

#67

Post by tiborsaas »

madeofpalk wrote: post #65
tiborsaas wrote: post #51

Earlier quoted context omitted.

That's not really a respectful practice. Error messages should be clear and actionable. Users don't care if you consider an error soft or hard.

I think the point is that the higher up you fail, the harder it is to identify why you errored in order to give the user clear and actionable feedback.

That's possibly indicating a bad UI / information architecture if you are unable to tell that.

Re: Write better error messages

#68

Post by dvtrn »

chillfox wrote: post #55
starkd wrote: post #39

Earlier quoted context omitted.

I think his point was the developer tends not to even investigate the ENVVAR at issue or visit the link. If the developer does investigate the link and still has an issue, than you have a point.

Pretty sure his problem was he got contacted about an issue he considers uninteresting, and his preferred solution is the user stops behaving like a human. Reaching for the easiest way to solve a problem first is a very human thing to do, and in this case he was easier to contact than opening up a browser and reading an article that presumably is written in the same kind of language as the error message.

I’m left wonder at what point does the “give a man a fish/teach a man how to fish” method of pedagogy apply in terms of ‘acting like a human’ in this context?

Asking as someone who otherwise generally agrees that there are some truly poorly written errors and exceptions out there, but has also been on the admittedly frustrating end of the constant requests for help deciphering error messages that were very plainly stating what the problem is for someone who didn’t even try looking for the fishing rod.

Re: Write better error messages

#70

Post by est »

Redesign err msg or UX you want, I hope there is always a "more" button to show exactly what went wrong. I hate eventvwr.msc or less -nir wall of log texts.
Post reply on HN