What is inline validation ?

Inline validation is the name of a reactive validation system applied to some fields. In real life, it’s when you are typing “John Smith” in a nickname registration field and the service, after an awkward slight cough, turn everything on red and suggest you “john_smith_983543″ instead.

Or maybe not. John smith buffer overflow ? (Twitter inline validation for sign up)

This method provide more feedback, is always up-to-date help users to complete forms faster, improve their satisfaction and provide a great check system for fields with high probability of error, especially when the errors are known only by the platform !

Let’s go for the implementation

Inline validation is finally a simple idea. That’s fortunate, because it has to be simple as possible. But despite this appearance, a lot of questions emerge as soon as we decide to write specifications and codes.

• Should we start the validation query at the first character typed to avoid useless request or wait for a convenient minimum ?
• Should we put a grace period before send the query, and if we do it, how long should it be ?
• Where are the visual feedback ?
• What should becomes in error ? All the field ? Only the border ?

And tons of little more questions. Although some of them can be perceived as futility, the addition of all this small decisions build a real implementation behavior, which is enough different to be noticed by the users. In this case, from a poor user experience to a great one : the devil is in the detail !

So, we write a guideline to share the decision

• At the first display, the field is neutral (no error)
• An error of inline validation is :
• A error red message, probably placed under the field A red border around the filed A font color of user input still as the original (not red)
• If possible, no additional message under the field (like “has to be unique”). If it’s required, this additional message is not replaced by the error message. The both are displayed
• Use a 1 second grace period*.
• Display a throbber at the right of the input.
• Live validation starts at the first char typed.
• Live validation doesn’t replace classic validation for classics forms (by opposition for inline edition). If the error is triggered when user submit the form, use inline validation error message and display.
• When user types or removes a char, hide the error message and the look of the field backs to normal, and call inline validation with grace period again.
• When a field in error becomes correct after validation, field stay normal. No more error and no validation mark.(Example at pinterest. Counter example at Twitter).
• If the field required a minimum length and the user stops his input before this limit, the inline validation should give a proper error message according this minimum requirement.

* Actually in the best of all possible world, the grace period should be set in regard of operation duration. IE if a query take 3 sec itself to answer, 3 sec query + 1 sec grace period = 4 too long seconds with 1 artificial sec.

Fine. But it’s text, and we want to design UI.

Illustrating guideline through wireframe

You can find in the following link, a wireframe to illustrate our inline validation, with 3 parts : * Cinematic of a classic validation * Field places and combinations * Which feedback give when a user submit an apparently validated form but in fact there are still some remaining errors

Even if it doesn’t seem to be a big deal, we hope everyone will enjoy this implementation !