8

I have come up with this question for 2 reasons.

  1. Not all errors can be avoided. For example login information which might cause program to throw unhanded exception if login information is not correct.
  2. Using default error messages might be too confusing for a user.

I wonder if I should take any extra precautions while handing program errors? What kind of errors should be avoided?

While on a point of errors. How errors should be delivered to a user? Something tells me that too many message boxes would waste some time while clicking on OK button too much, causing user frustration. Labels should be a better choice?

What is your opinion?

Improve this question
8
  • 4
    none ever, manage your errors internally and avoid the user from any technical mambojambo - e.g. even if the "login information is not correct", that's not an error but rather a "revisit your inputs demand" ;)
    – Leon
    Dec 7, 2011 at 9:50
  • Well that's a dangerous approach on designing systems. What if the document the user tried to save wasn't saved due to an error - should the user close the program with all his work lost, in the belief that it's safely saved?
    – Henrik Ekblom
    Dec 7, 2011 at 14:40
  • @Leon not always possible. For instance websites go down, 100% uptime is impossible, some errors can't be avoided and sometimes a user must be made aware of the issue.
    – Ben Brocka
    Dec 7, 2011 at 20:58
  • I think Leon is trying to distinguish between an error and a message. If a document fails to save, you don't want the application to say "Error writing bytes to filesystem" or anything remotely technical. Instead, a clear message should be given, along the lines of "Your document could not be saved, please try again" (although even that's not great, just a quick example off the top of my head ...)
    – Bobby Jack
    Dec 8, 2011 at 0:49
  • @HenrikEkblom - in an ideal world you would queue the task and make it happen whenever the system is ready
    – Leon
    Dec 8, 2011 at 11:20

3 Answers 3

Reset to default
15

The basic idea with showing an error message is to let the user know that something went wrong and his actions may not have resulted in a desired way.

So, if the error is something that doesn't affect the users perception of the program - don't show it, but keep it in an error log (for example, the function took 50% longer to execute due to some errors, but all of the actions the user made was executed correctly).

If the error affects the users goal - let him know that it went wrong so he can fix it. For example, the file couldn't be saved due to an error (incorrectly user chosen path or a bug in the program itself). If the user can fix it, tell him that. If the user can't fix it, he still needs to know that file wasn't saved.

To disrupt the user's workflow can be annoying but if it's crucial information ("the file couldn't be saved) - the user mustn't miss that! So it's a judgement from the designer of the system to decide if the error is crucial enough to disrupt the user.

Improve this answer
1
  • Great points. There is a fine line between an overload of information to the user which will ultimately annoy them and not providing enough leaving them in the dark.
    – Aaron McIver
    Dec 7, 2011 at 14:53
3

Philosophically, I believe in empowering users as much as possible, which means disclosing all error conditions. Obviously, no rule is absolute, and defining what is an error is a bit grey. But generally, I need a damn good reason to hide information about "behind the scenes" actions of a system.

How you communicate errors to the user should in some way be relative to the impact of the error on the user's workflow-- the more catastrophic the error, the more disruptive the notice. And if a user decides that they are not interested in being informed of a particular type of error, then they should be able to opt out of being interrupted by that error notice (as long as they have a way of finding out what they've missed).

To the point that too many error messages are disruptive and annoying to the user - I agree. And I believe the user should be annoyed by a system that generates enough errors that their disclosure could be disruptive. The problem is the errors, not the notification. Don't shoot the messenger.

As I said, this is a bit of a philosophical issue, so I respect that other viewpoints are equally valid.

Improve this answer
3

I recently signed up for a USAA account. We never got our check card. After calling the bank and talking with their rep, I was told "ah, I bet you typed a dash in the address. Our web site will delete everything after the dash so we probably mailed your check card to the wrong address. This happens all the time."

Not knocking USAA as I find their web options and customer service far exceed the competition, but this is a great example of where its critical that a user see an error. Even if it's an indecipherable message, at least the user knows something went wrong and can try and triage the issue via phone or email prior to things like one's check card getting mailed to someone else.

So, assume there will always be errors, and then these errors need to be communicated in some form to the end user. The goal then is to make the error language applicable and understandable to the end user's task objectives and needs.

Improve this answer
1
  • 1
    A great example of an error that occur unnoticed for the user and leads to an undesirable result.
    – Henrik Ekblom
    Dec 8, 2011 at 8:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.