Inline validation design and implementation

This post is a continuation of the article about Research into inline validation which discussed risk of loss of conversion.

When (re)designing a form for inline validation you might come across some design challenges. This article discusses some issues and considers some suggestions on how to solve them. First I will discuss implementation issues, and the technical costs, then design issues.

Error messages

With inline validation forms become very dynamic. Because inline validation occurs while the user fills in a form, there needs to be adequate room for helpful error messages. The form probably needs to be redesigned to make room for these messages. This may have some negative consequences. Error messages being inserted and removed between fields may confuse and annoy users due to fields constantly moving from their original position.

This could be solved by a combination of the following:
Compacting forms (horizontally). Its nice to place error messages right next to the field they are refering to. The form may need redesigning (decreasing widths of input fields) for these error messages. This may create new usability issues or new design challenges.
Increasing vertical whitespace between the fields. Increasing forms vertically has many downsides. A longer page might convert less well and makes labels less scannable. It may put off users from filling in the form in at all.
Call-out error balloons can be used. But these may overlap other form elements or obscure other error balloons.
–  Short error messages with the risk of making them potentially less clear and less helpful.

Also keep in mind:
– Show each error message near the field instead of only at the top of the page. This is the whole point of inline validation.
– Prevent error messages from appearing above or below the fold and out of sight. Scrolling to the error might be disliked. The problem can be partially solved by ensuring that error messages appear above their respective fields, where they usually have more chance of being noticed. Discussions about scrolling to errors here and here. This feels like patchwork, however, so try to solve the initial problem rather than using ‘scotch tape’ or stop-gap methods to cover up new ones.
– Error messages should be noticable, visually distinct: most times red.
– Don’t make an error message a Javascript dialog.

Error icons

In inline validation a correct field could be marked by a tick or (green) checkmarks or the text OK. The purpose of this is to reassure the user that what was typed in that field is correct. The business value is that it can help motivate users by giving them the confidence that there is no error so they can continue.

The checkmark as a confirmation of acceptance or pass may not be universally understood by all cultures. Some plausible variants of checkmark:
– OK text (preferably in green)
– smiley
– thumbs up
– VALID text (best for accessibility is an icon that includes the word “valid” or an even more specific messages such as “valid email address”)

If you use inline validation, you shoud strive for consistency. Just like error field might need an error icon, every valid field then also needs a checkmark icon. Leaving the checkmark out may make users uncertain about the fields that do not contain an error symbol. The user will start to think “are these fields correct?” or “is the system still checking these fields?”. This is especially an issue if you plan to use inline validation only on a few fields within your form, which would be an inconsistent user experience.

On the other hand, consistency can be a bad thing. It can be overdone. For example, watch out for the christmas tree effect: it could leave you with many green (valid) and red (error) colours blotted over your form. Ensure your form remains clean and aesthetic.

Checkmarks that fade out with time are easily missed by users. To avoid the christmas tree effect, you might want to make disappear or fade out after a few seconds. [2]: “Yahoo provides instant feedback each time users fill in a field by showing a tick at the end of the field. Each tick disappears after a few seconds. The majority of the participants commented they did pay attention to them. However there were mixed opinions from the participants on the animated ticks. Some of them gave positive comments, whilst others thought they were distracting.”

The tick or checkmark is the most common symbol to indicate that a filled in field is valid. Consider the effect of leaving them out; they might not be needed at all. Can you afford to go for inline validation for only a few fields, or will it make people think and doubt? See my other posts on in which situations I think inline validation can be useful versus harmful.

Implementation challenges

Inline validation comes at a cost. Is there hope? Here are possible work-arounds for overcoming the cons.

Leads: Capture e-mail address and contact details first. Ensure you capture data while a form is filled in, and not only upon clicking submit button. This requires an AJAX like server communication, possibly more moderation and more costs…
Smart format recognition: Ensure forgiving input (make the system smart in recognising errors and correcting them itself).
Requires Javascript. Use a lightweight Javascript. Around 2% of users have Javascript disabled (on purpose), so by using inline validation your are losing them. If you want to support users without Javascript, you might want to use inline validation with normal server-side validation as a back-up. Alternative technologies are Flex/Flash, Java and AJAX, although Javascript is your best bet due to its ubiquity.

– All client side validation (onBlur) must be enforced with server side validation (onSubmit).
– Scroll to the first error onSubmit, as even for large resolutions the error might still be out of sight (outside the fold).

For a comparison of server-side and client-side validation (ideally you should have both in case one fails), see this article.

Developer toolkits

This post is a continuation of the article about Research into inline validation. Be sure to check out my other posts on inline validation research.



One Response to Inline validation design and implementation

  1. […] Design and implementation of inline validation […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: