How do you process the errors in your applications?

Question

I have a new application with a status bar that I want to use to display the errors that occur but only as long as they're relevant. For example if the user clicks on a button to do an operation and it fails, then the error would appear on the status bar. If the user tries again and it succeeds then the error message would go away.

So far so good, the problem is that the user might do something else in the application for which the error message is no longer relevant. For example the user could go to another screen and continue working there.

I'm leaning towards after every action firing "success" messages that would clear the error messages (if any). That way the error stays on until the user does something else.

How do you handle these situations?

EDIT:

I don't think I can/should use in-situ messages because there are many async operations that the user can perform. The user can be in another place by the time the error occurs.

The idea is not to flash something every time the user performs an action. Instead the status bar would be blank (probably hidden too) if there aren't any errors. If an error occurs then the status bar would display what happened. If the user performs another action successfully then the status bar would be blank again (maybe hidden too).

From the user point of view this seems like a good idea but I ask because sending all these success messages doesn't feel "right". There's a smell to firing all these events that would basically be eaten by the application. Maybe there's nothing wrong with it and I'm just making it a bigger deal than it is.

This seems like a common scenario for an application so I wanted to know what's a best practice.

Answer 1

Are these errors really important to your users?

This is the question you should really think of and then you will be able to answer it the right way.

Because if these errors are really not important, you should not annoy user with any messages at all. Otherwise, you should never hide them until user will be able to perform any action in response to the error message, I mean you should show an error the way it will be visible, clearly describe the problem and (in a case of async operations) allow user to repeat an action or review a cause of the failure.

So the better error message will looks something like "Sending message failed" with retry or edit/cancel options available to the user.

It seems like placing errors in statusbar is not so good (it's far away, have a limited space for showing several errors etc), I would prefer to use a specially dedicated area (at the top of the app window) which will show an error and available options. And it shouldn't be hidden if user will switch the screen.

Answer 2

If I'm reading this right, you suggest that an error message for action A disappear as a result of a successful and unrelated action B. I think that it might be pretty confusing for the user, who might perceive the error message going away as the error being resolved. This has the direct damage of misleading the user into thinking that there's no error, and also of making him stop and wonder how action B could possibly affect action A and what the implications of this may be. Then there's the collateral damage of harming his mental model of the system, his feeling of understanding and of control.

You can fight this by emphasizing the change of context and making it extremely clear that it applies to the status bar itself, and not just the work area. There are many visual means that can help you with this.

Answer 3

I wouldn't use success messages in that way, as they mean every action will be accompanied by a potentially distracting change. If the action the user takes is quite far away from the status bar, that means the sudden change will occur in peripheral vision, which is particularly disruptive.

I would simply clear the error message as the user moves screen or takes different actions. Or I might eschew the message bar entirely in favour of messages in-situ, so they appear next to the control they relate to and in the user's field of view as they're focusing on the control.