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?
2 Answers
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.
Note that you have to validate on submit if you want make sure you catch errors. Client side validation (i.e., on blur) requires JavaScript and JavaScript can be turned off. It is rare these days, but it is not unheard of. Also, not all browsers support the same level of JavaScript.
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.
-
I believe I've seen the study you're referencing, but I don't recall them testing the hybrid validation I suggested. In other words, never turn a field red until blur, but do turn a field green once it's valid. Leave it white if it's invalid but the user is still typing.– CubertoCommented Nov 20, 2013 at 19:22
-
Indeed, I've not seen a study on your hybrid approach. Personally, I would avoid turning it green. It is not common practice and changing the color will capture the user's attention (be it red or green) -- they'll wonder why and get distracted. My personal opinion is that it is "valid until it is invalid"... or "white until it is red". Commented Nov 20, 2013 at 19:31
-
@Cuberto, I've updated my answer with the study I was thinking of and re-worded my answer slightly to better emphasize the findings. Commented Nov 21, 2013 at 7:00
-
I have to say that while the study quoted is the most comprehensive to date, the "Modal Theory of Form Completion" proposed within is largely ignored by the ux community. The authors assert that further research is needed to clarify the results and that it goes against the ISO 9241 recommendation (which implicitly favours on blur). There are also a multitude of issues one could criticise with regards to the method employed - such as meaningless and oblique obstacles users were facing (eg, forcing a trailing
/
on a website entry).– IzhakiCommented Nov 21, 2013 at 23:59 -
In addition, the third recommendation (After-Dialog-OneByOne) seems truly baffling and goes against many established concepts like immediate feedback (equally the all-at-once approach goes against sequencing and short term memory). Not only this, but I fail to recall a single credible website that handle form validation this way. The answer itself is great, but I have to warn that the research itself may be proven flawed.– IzhakiCommented Nov 22, 2013 at 0:02
As revealed in this fantastic article, the answer is on blur.
To quote:
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.
-
Generally agree, but would also recommend a middle-ground of providing immediate feedback when something is entered so far that could never be valid. For example: a comma typed after the @ in a field for email address.– EricsCommented Nov 21, 2013 at 6:12
-
2@Erics - One approach to the middle ground is to use throttling to wait to update the feedback after, say, 500 milliseconds. This gives the feedback when there's a pause in data entry, possibly at the point in which the user is looking at the screen for confirmation. It also avoids executing the code for the validation multiple times in succession. Commented Nov 22, 2013 at 15:23