Sunday, September 13, 2009
Luke Wroblewski recently put inline validation—letting a user know if a field on a web form has been filled out correctly before the user clicks the submit button—through a formal usability test. To no one’s surprise (I hope), inline validation resulted in significant usability and satisfaction gains:
When compared to our control version, the inline validation form with the best performance showed compelling improvements across all the data we measured. Specifically, we saw:
- a 22% increase in success rates,
- a 22% decrease in errors made,
- a 31% increase in satisfaction rating,
- a 42% decrease in completion times, and
- a 47% decrease in the number of eye fixations.
Luke’s tests go further to test various details of possible inline validation options. He also rightly warns about the difference between “correct” information (which is generally not tested by web forms) and “valid” information (which generally is tested by web forms). His tests used a green check mark which led to some confusion on that point.
I agree whole-heartedly that inline validation is a big usability winner. I can’t help but wonder, however, what the best way to implement it is. Inline validation is, by definition, a client-side feature. It’s a bad idea, however, to rely on client-side validation as it can easily be bypassed; there must always, therefore, be server-side validation. How, then, does one best implement client- and server-side validation without repeating one’s self on both sides (and thus violating the DRY principle)? The obvious answer is to have the client-side code make asynchronous calls to the server to check validity but that can lead to a lot of otherwise unnecessary server calls and slow validation for the user. Are there any other ideas out there?