I have a signup form where I made a REAL-TIME validation when the user starts typing as you see in the picture.
To quote from nngroup.com:
7. Don’t Validate Fields Before Input is Complete
It can be annoying to see an error message before being given the opportunity to finish typing.
Validation should not start before input is complete
When the user starts entering a correct value, no errors should appear while typing. The input is considered to be complete when
- the input focus is lost (navigating to another field) or
- the form is submitted (e.g. autosubmit when pressing enter) or even
- after not receiving input for some time (e.g. 3sec after the last input event).
Showing input errors immediately while typing is very distracting ("must have at least 3 characters" when starting to type) and rarely helpful.
Validation errors should be removed on the fly
Once the field is validated, and shows some errors, the user wants the error to vanish as soon as the edited value is correct, not when he leaves the field or submits the form (which probably will be disabled anyways as long as there are errors displayed).
This can be achieved by removing all errors from the field when it becomes dirty again (and revalidate it later on submit or focus lost), or automatically revalidating the field every time it is changed.
Rather than continuously display a red validation message when the user has not met a field's requirements, a nice alternative is to (1) display a tip that tells the user what is expected, and (2) display a green "requirements met" message when the user has entered a valid value. You can go green as soon as the input is OK.
It depends on the type of Input Field.
- For the Email Field:
You don't wanna be too jumpy. Let the user finish typing the email address. If the input field turns red with an error-text at the moment the user starts typing, it will annoy the user.
The right approach would be to let the user finish typing and when the user shifts the focus away from that field, validate and show whether it looks good or throw an exception text if there is any.
- For the Username & Password Field:
Username and password fields need to be validated pre-submission because they have the strictest input requirements. So clearly show the user what is accepted and what is not in real-time as they start typing.
Link to the Articles:
Real-time validation works if you properly handle incomplete responses.
The example given is bad UI because "reara" is a valid way to start an email address. An example where real-time validation can reject an incomplete response is "reara@@". In that case the real-time validation can reject it without waiting for completion.
In general, you need to be show an error message when there is no additional input which can make the response valid. How hard it is to detect this will vary from case to case. If you have a dictionary, it's fairly easy. With regular expressions, less so.
It of course helps to have good error messages, which are appropriate in the context of incomplete input. "An email address should contain exactly one @ sign" for instance.
If you can't handle incomplete responses, for example because it's always possible to enter a suffix to make a particular field legal, then you should wait for complete input as suggested in the other answers.
I wrote an article about the problem with live validation:
In short: it either provides feedback too early and often before the user has had a chance to type their answer OR it provides it too late once the user is finished typing their answer and is focused on the next field answering the next question.
Instead focus on:
- clear and concise label, hint text and error messages
- forgive trivial mistakes
- let the user submit the form when they’re ready
This way users will very rarely see an error message and when they do, it will be when they expect to see one.
It is good to validate live. However, such a validation needs to distinguish between two cases:
- input that can be made valid by adding stuff at the end, and
- input that can not be made valid by adding stuff at the end.
The latter case should pop out the error message instantly, while the former needs to wait until the input is complete.
But how can you tell one from another?
That's a bit tricky given current tools, but if you are writing your own regular expression engine (or some other kind of finite state machine for validation) you can achieve it like this:
- if the engine reached the end of the regexp (the goal state), there was a match.
- if the engine reached the end of the string, there might be a match later.
- if the engine couldn't reach either, there's never going to be a match.
The problem is, most programming languages don't give any indication about reaching the end of the string. Also, even though it's a minor change to any existing regexp engine, rolling your own is pretty much certainly out of scope for every user interface design project ever.