Inline field validation has become widely adopted as a fast and reliable way to check user information. There's been plenty of discussion and research on where, when and how inline validation should be used.
Before, while, after and on submit validation
A key study in this field by Luke Wroblewski investigates the impact of inline validation in contrast to on submit validation. Furthermore this study looks at a few variants of inline form validation.
Key takeaways from the study are
- Inline validation clearly wins over on submit validation in speed, error-rates, user satisfaction, completion time and reduction in eye fixations
- Inline validation on fields after the field lost focus (onblur) clearly wins over before and while validation regarding speed, error-rates and satisfaction
- users strongly disliked before- and while-validation.
The latter becomes clear, if you watch the video of the study showing the three variations of inline validation:
In some fields, in the before and while conditions, the user starts with an invalid value - no matter what you enter. Moreover, the salient on- and offset of the error messages in the periphery are extremely irritating and make for a very erratic user experience. No wonder users strongly disliked those conditions.
Based on such findings, we might want to ditch the before and while conditions altogether. However, let's first consider why such variations of inline validation would make sense in the first place.
Feedback is key in action regulation
Feedback is a key factor in action regulation. It tells us if we are on the right track and lets us adjust our actions accordingly. The more specific and instantaneous feedback is, the better. Inline validation in the while condition has therefore the benefit that we immediately know about wrong values - values get validated in real-time and this approach is thus the shortest way to correct values.
A tolerated state
So why did the before and while condition utterly fail in the study mentioned above?
In the study the fields had either an invalid, valid or default state. I'd propose that what is missing is a tolerated state.
A tolerated state regards a value that is neither wrong nor yet valid as, well, tolerated.
Imagine the field name that requires its value to be an alphanumeric string of at least 3 characters length.
While entering the value, a string of
- A would be invalid, but it may finally end up as valid - thus should be tolerated for the time being
- A# would be invalid and won't be valid (# is not alphanumeric) - thus not tolerated and therefore fail immediately
- Andy would be valid and thus tolerated either way
With the additional state in place, before- and while inline validation suddenly become very natural, providing immediate feedback without getting in the way.
I have no quantitative evidence for this (yet), but hallway testing suggests that while inline validation might correlate more positively with user satisfaction than after inline validation. For now I'll go with the additional state, thus the fields will have four states:
- neutral - Field is not yet touched
- tolerated - User is entering data, that is not yet valid but may eventually be (i.e. min numbers of characters)
- valid - Valid state while and after entering data
- invalid - Invalid state while entering data and onBlur. If a field has been touched and left in default state
- use instant inline validation using mark, feedback message and colour
- use a clear feedback message that represents the state accordingly
- have each state reflected by an icon - neutral and tolerated sharing the same icon
- have each state reflected by a colour - neutral and tolerated sharing the same color
- use transitions between states to avoid salient onsets and distraction
- use marks on the left consistently. This allows for an easy scan of all the fields and their state.
- use validation on all fields consistently. Even for simple fields like name.
Sure the concept of states can be expanded. For instance, some fields may only be validated in a combined manner (i.e. address, postal code, place). In this case an additional pending state “looking good - will check later” might be a good choice.