— Text by Stuart Brown

orms 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.

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.

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.

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.

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.

Don't be too aggressive with your JavaScript validation. Consider it to be like a velvet rope, guiding users away from any obvious pitfalls but not in any way a major impedance. Remember - JavaScript can (and will) be turned off on the client.

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.

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.

Finally, a post!

<label> is in my opinion one of the most useful element when designing forms, especially when they have lots of radio buttons and checkboxes. Unfortunately, it is also the most widely forgotten...

Welcome back!

Forms are one of my biggest gripes. So tedious to create, check validation etc. I hate the fact if I check the form using javascript, I then have to check it using php server side.

I quite like AJAX in a form, however, the "check username" function is usually a good one.

Ugh. Forms.
It's the one thing in building web pages that I really hate doing.

I don't think it's necessarily true that one should avoid Ajax in forms. As with anything, it just needs to be done properly to add optional functionality.

The example of 'check username' is a good one. It's a useful thing, but it's also quite possible to set up so that if JS isn't available the 'check username' button doesn't appear.

Likewise, if the Ajax request fails, show a friendly message saying that the name couldn't be checked.

It's all about progressive enhancement. Make the form work, then (and only then) add stuff to make it work better and improve user experience.

Although I tend not to use Ajax for form submission, the same principle can be applied. Make the form work without the Ajax call, then (if you have the time and inclination) do the Ajax submission with some detection/fallback if the Ajax call fails.

On the subject of checkboxes, radio buttons and labels. I'm in a state of flux as to how exactly to mark up a group of radio buttons (for example).

Assuming that your form has a question/answer format do you use a legend tag and a fieldset to group your buttons together then apply labels to each radio button? Or do you group them in a div and put your question into a label for that div?
I can never decide!

Oh, yes, welcome back :)

I encountered some nasty forms on the British Gas site recently. I couldn't remember my password, so tried to reset it. The forms use some pretty but ultimately useless AJAX tooltips that don't actually advise you on what validation is being applied to the fields, and what help is available becomes unavailable if you shift focus; to another form field or browser tab, for example.

What's worse, one of the password validation criteria -- that you can't choose one of your last 12 passwords -- isn't listed *anywhere*! I only found this out by emailing BG.

Luckily, I remembered my password and didn't need to reset it after all.

Yes, yes and yes. Great post on coding forms.

Use Ajax/JavaScript effects sparsely on your forms only when necessary. Don't hide important information behind fading JavaScript effects unless it is very intuitive and adds to the user's experience.

Labels are very important.

Aggressive client-side validation can lock users out while revealing your business logic.

For file uploads, the basic file uploads are horrible for uploading multiple files and styling, consider SWFUpload or a Java uploader like Facebook.

I'd generally advise against any AJAX stuff in forms, but I must confess I've been impressed once or twice with those forms that check username availability before submission.

@Pete - Can't say I'm a regular user of the fieldset/legend elements, but (for longer forms especially) they could be useful for grouping elements, stylistically at least.

Fantastic post, i got enriched with valubale information regarding HTML coding.

Thanks for finally making a post!! I know you been busy with work and all but seeing a post is great!

All this advice really helps, I never have had overly large forms. Some stuff on this post is totally new to me, so I will be looking more into that soon.

Cheers Stuart!!

Forms that require unnecessary information piss me off big-time! Case in point, I'm trying to alert someone to a 404'ed link - but the site designers DEMAND I enter my first & last name plus some other junk they don't need. My response, generally, is to enter garbage (eg "William Gates III" or "Why, why, why"). On bad days, the garbage gets a bit more, er, spicy.

FYI, I've not no complaint with your comment form. It just seemed apropos to enter crap. Sorry. :)

Hmph. I suppose I'll have to prepopulate the name with 'Anonymous' or similar :-)