Wandering Thoughts archives

2012-06-11

What bits of a form are useful to check on the client side

I spent part of today adding more JavaScript to our account request system, in the form of some client side form validation code. As part of this I wound up considering which bits of form validation are worth doing in the browser.

Of course, for some people the answer is 'all of them'. This may be justified or worthwhile in some environments, but my view is that I don't have the time or energy to write a second copy of form validation code (and any needed backend services to support it) for all fields. Until the day comes when I can write one set of validation code and have my framework magically generate both client side and server side code from it (along with the AJAX callback services necessary to support it), I'm going to need to pick and choose 'high value' form validation on the client side.

My conclusion is that the fields that are really worth adding client side validation for are the fields that people can't completely check for themselves just from inspection. This sounds abstract and obscure, so let me give a concrete example. Our 'request an account' form asks for both your name and the login that you want; on the server, we validate that you supplied a name and that the login you asked for is a valid login that is not already taken (or requested). Someone filling in the form can easily see whether or not they've supplied their name, but they have no way of knowing whether or not the login they've picked is already taken. Client side validation of the login gives people immediate feedback on this without them having to go through the slow process of form submission and examining the results. As a side effect, it lets them check several different logins so they can pick the one they like best (because, unlike form submission, they are not committed to a choice that the system accepts).

(By contrast, client side validation of the name field would just be telling people 'hey, the name field is still blank', which is something they can see for themselves if they look.)

A related approach would be to figure out what problems the submitted forms are most likely to have, on the grounds that these give the highest payoff from early detection and feedback (in the form of users having to go through fewer cycles of 'submit form, get errors, try to fix errors, repeat'). I think that this is going to get you more or less the same results unless your form is unclear (or confusing), but the advantage is that if you wanted to you could drive this from logging actual validation errors on the server.

(This is obvious but worth saying: client side validation is never a replacement for server side validation, it's only a supplement. You always have to have full server side validation, so the question is how much immediate in-browser validation you add on top of it.)

WhatToValidateClientside written at 23:27:59; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.