Good Practice in Implementing HTML Forms 21 November, 2007 — 11 comments — Stuart Brown
Tips & tricks for optimum efficacy in data collection
Forms are a critical but often misunderstood aspect of web design - most of the attention in tutorials and guides go to the presentational aspects, rather than the usability of forms.
There are countless times when I've been pained by over-zealous validation, postal code lookups which don't have my address, and data lost from a form I've just spent half an hour filling out. As it seems like I've spent the last couple of months working on nothing but forms, I figured I'd compile a handy set of general guidelines.
Single page forms...
In general, I'll avoid spanning a form over more than one page - it makes navigating backwards & forwards difficult for both the user and the developer, and turns the simple act of returning to the top of a form to correct a detail to a painful trawl through a series of pages.
...but paginate when necessary
If you're dealing with hundreds of fields worth of data (and have good reason to), then pagination may be the best way of dealing with it. Make sure you break the page at a logical point, and that full bi-directional travel is possible.
Most importantly, test thoroughly to make sure it's impossible to lose any data when traversing pages, or through server-side validation checks.
Minimise data collected where possible
Although a one-paged form is best, excessive scrolling is undesirable too. If you can compact or exclude some of the fields, do so.
This is particularly applicable to registration forms -you don't need to collect every last scrap of information about your user at the time of registration, just collect the basics. Just username, email, password, and perhaps a second password field to confirm. Anything more is superfluous - and you can allow the user to enter it at a later date.
AJAX in forms
Avoid AJAX controls in forms. If it breaks you'll have no route for graceful degradation without losing form data, and I'm yet to see such a control with any real use.
Form submission via AJAX is also less-than-sensible, unless you're dealing with a form in an environment that's already reliant on a steady page state. Don't use it unless you need to - the browser's in-built handling for forms via POST will be far more robust, and just as fast if done right.
Overly aggressive validation
Any unsafe data (i.e. SQL injection attempts) should be sanitised server-side - it shouldn't be a consideration client-side at all. You should be concerned about minor corrections, and even then - use a light touch.
Use <label> elements
I'm a fan of the implicit label in forms - that is, encapsulating the input element with a label to automatically associate them. It's simple, makes label / input pairs easy to style, and doesn't require too much extra markup.
The explicit (but more verbose) method is to use the <label> element's 'for' attribute - here you can specify the id to which the label belongs. This does allow slightly more flexibility as fas as styling goes, but it's down to your own requirements whether you use implicit or explicit labelling.
Labels provide usability hinting for the browser - for instance, in Firefox clicking the label associated with a checkbox will have the same effect as clicking the checkbox itself (effectively increasing the clickable area of the control) - a common convention in operating systems and a boon for usability.
The <input type="file"/> element is horribly broken as far as CSS is concerned. Styling via CSS is possible (such as this way or this one) but the backend code is messier than I would like and non-intuitive.
Also, if you're constructing a form that handles an upload don't forget to add the attribute enctype="multipart/form-data" to your form. Otherwise, it simply won't work - as I discover nearly every time I'm working with file uploads and forget all about the 'enctype' attribute.
Keep forms simple. Don't break anything. Consider usability at every step.