Should you clear user errors when the error is perceived as fixed or when it is confirmed as fixed?

Question

When a website or application has user input controls that validates the input, the user is (usually) notified in one way or another if the input doesn't meet the requirements. Eg. incorrect email address, input format etc..

The error is presented more or less clearly across the range of websites/applications. The quality of presentation is not however the focus of this question.

I'm interested in one specific aspect of how this user error is presented. That is whether the error should be visible until the user tries to submit the input again, or if it should be cleared as soon as the user manipulates the input in the control where the error occurred?

I'm not really interested in whether this should depend on how the validation is carried out, ie. in real time or on submission. But rather if the user is comfortable pressing the "Next"/"Submit" button when there's an error indicator present, for an error that may have been fixed by the user.

The reason I'm asking is that I've noticed that eg. Microsoft Hotmail has user errors present when composing an email even after the error is fixed. I would suggest that this is not in accordance with good UX. I would think that this could cause unease with the less experienced users, who may be searching for additional errors just because of a misleading error indicator.

Is there a good reason for the Hotmail approach that I'm not seeing?

EDIT: To clarify, it is this last sentence that I'm really interested in. Why would an application choose to display an error message that may have been fixed.

Answer 1

I believe users will notice what action made the error message appear and expect the same action to “check” the new input. Thus the same user action that triggers the error message should trigger clearing the error. If the error appeared on Submit, then clear it on Submit. If it appeared when the control lost focus, then clear it when it loses focus. If it appear as the user was typing, then clear it when the user retypes (or backspaces).

A case can be made to clear the error message before submitting, if it’s technically possible, but that’s true for showing the error message in the first place, and if you can detect corrections before submitting generally you should be able to detect errors in the same way, so the rule still applies.

Answer 2

I'm not really interested in whether this should depend on how the validation is carried out, ie. in real time or on submission.

Well this does have a bearing on the issue:

• If the validation is only carried out on submission - on a login form for example - then you have to clear the error when the input changes. You've no idea at that stage whether the new input is correct or not. You have to assume it's correct until the validation has had a chance to occur and that's on submission ("Next" or "Finish").

• If the validation is carried out in real time then you can - and indeed should - keep the error visible until it's truly fixed.

Answer 3

If working with a pre existing system, when the validation is carried out will drive your solution, unless you can start from afresh.

I would say the sooner you can identify that the user has fixed the issue the better. In most situations real time error checking would be preferable and updating to confirmation when the user has resolved the issue. But there are situations where this may not be possible, such as on passwords.

In these cases you have a couple of options I can think of:

1 - continue showing the error until submit is clicked;

2 - Hide the error as soon as the user interactions with the object/the object loses focus;

3 - Once the user interacts with tht object/the object loses focus, there could be a way to communicate to the user that this field has yet to be validated (so is marked in a way that isn't right or wrong).

I would prefer options 2 or 3.

I would recommend real time validation/confirmation where possible. And I probably sound like a broken record but for confirmation go ahead and test different versions with users to find out which is the best solution.

Answer 4

Ideally, errors should be cleared when the text has been corrected. What this means is that error validation should be done by AJAX, which has the advantage of showing errors immediately too.

So

I'm not really interested in whether this should depend on how the validation is carried out, ie. in real time or on submission.

is critical to the question. Ideally, errors should be validated in real time, meaning that corrections to errors should also be done in real time.

Most validation is done on submission, just because that is easier. As long as it is clear, then that is not a problem. It should be possible to get a correct submission on the second go at the latest. If this is not possible - if the validation requires guessing a unique user name, for example - this should be done in real time.