Is it better to give the user instant feedback that a field is invalid on keypress, or should you wait until they blur the field? The first option might annoy users if they are told their input is invalid before they've finished typing. The second could annoy users if they have to refocus a field. Perhaps a solution is to display validity/completeness (green) in real time, while delaying the display of erroneous validation until blur?
Validate on blur, or on submit. Don't validate while typing, for exactly the reason you describe.
There are studies/observations that show the people generally complete the entire form and then return to values that are incorrect. Even if you validate on blur they will tend to complete all fields and will then return to fix.
Article: Usable error message presentation in the World Wide Web: Do not show error right away Author: Javier A. Bargas-Avila, Glenn Oberholzer, Peter Schmutz, Marco de Vito, and Klaus Opwis Source: Interactive with Computers, Volume 19, pages 330-341 (2007)
Results of the Study
- When Completing an online form users have two modes: Completion Mode and Revision Mode
- Users tend to ignore immediate error messages when they are in Completion Mode
- Of the size possible ways to present error messages, three proved to be more effective than the others:
- Present the error afterward, embedded in the form, all at once
- Present the error afterward, embedded in the form, one by one
- Present the error afterward, in dialogues, one by one
The study alone suggests you should present error after the user has completed the form -- in other words, on submit.
If you validate on blur, show a simple non-obtrusive error (a highlight and possible a short message next to or under the field). Do not force the user to fix it immediately. You can disable the "submit" button until all fields are validated -- include a small message or popover indicating why the "submit" button is disabled (e.g., "Please fix the highlighted fields before submitting"). You can let the user submit despite errors too and display an additional error message then.
Validating on blur helps the user realize something is wrong before they submit, but you will also need to validate on submit to make absolutely sure everything is formatted the way you want it. However, the study quoted above would suggest that validating on blur does not buy you anything that validating on submit already provides.
As revealed in this fantastic article, the answer is on blur.
When we used the “after” method in the first half of the form, participants completed the form seven to ten seconds faster than when we used the “while” and “before and while” methods respectively. Why? Here’s what happened when we used the “while” and “before and while” methods: When several participants noticed an error message while trying to answer a question, they entered one additional character into the input field, than waited for the message to update. If the updated message continued to show an error, they entered another character, then waited for the validation message to update again, and so on, resulting in longer average completion times.
The “before and while” method not only caused longer completion times, but also produced higher error rates and worse satisfaction ratings than the other inline validation variations we tested. Our participants articulated their strong distaste for this methodology:
“It’s frustrating that you don’t get the chance to put anything in [the field] before it’s flashing red at you.”
“When I clicked in the First Name field, it immediately came up saying that [my first name] is too short. Well of course it is! I haven’t even started!”
“I found it quite annoying how red crosses came up when you hadn’t finished typing. It’s just really distracting.”
These negative reactions, longer completion times, and error rates illustrate that validating inputs prematurely can be harmful. Instead, when you validate open-ended questions, give feedback after the user finishes providing an answer. Or in situations in which people need help sooner, give feedback while they work toward an answer, but use an appropriate delay so premature error messages don’t frustrate them.