Andy Hulstkamp

about creating online experiences

21. June 2013

UX - Inline Form Validation revisited - the while condition

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

Further

  • 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.

More states

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.

further reading

Origami. A Pattern Generator - Generative Art.

Origami. A Pattern Generator using raphael.js. Generative Art.

Keystrokes.js

Javascript API to interactively display keystrokes and short-cuts.