Client side form validation can let people explore their options

June 13, 2012

Here's something important that I just realized about in-browser form validation: in-browser form validation lets people check their options out or to phrase it differently, in-browser form validation lets people change their mind.

Yeah, sure, technically plain forms let you change your mind too. But the problem with a plain form that asks people to make a choice, like picking a login name, is that the only way you have to find out if the login you're considering is taken or available is by submitting the form and submitting the form is making a commitment. Not only have you found out that the login is available, but you've committed yourself to it. That's not something that promotes exploration.

But in-browser form validation is different. Because in-browser form validation is not a form submission, you're not committed to whatever you put in a field that the system accepts; you can go back and change your mind (at least in any sane design). This makes it a great way to let people experiment or check several options to see what's available. They can change their mind as many times as they want and see the effects if they do.

As an obvious note: to make this work well your client side validation needs to not just report errors but also provide positive feedback, so that people know that their choice is a good one (well, acceptable to the system at least). And it should be relatively obvious feedback, because otherwise people may miss it.

(I more or less lucked into doing this in my web application; I put in visible positive feedback partly because it vaguely seemed like a good idea and partly because it let me see that my client side code was actually working and getting the right answers from my AJAX callback to the server.)

A related thing that in-browser JavaScript can help with is making any relationships and dependencies between form fields and form options clear to people (or at least clearer). Sure, your web page says which bits are mandatory and which bits are optional and that you should only fill in field B if you ticked option A, but we all know that not everyone is going to read all of that and get it right. In-browser JavaScript can just manipulate the form to make all of that directly visible; if option A isn't ticked, you hide field B entirely and so on.

(This can be extended to much more elaborate multi-section forms or drastically changing field options if you need to, although you're starting to run into the limits of graceful degradation and perhaps UI issues.)

Written on 13 June 2012.
« What bits of a form are useful to check on the client side
Some tricky bits in in-browser form mangling and validation »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jun 13 00:31:52 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.