This is excellent Joe. Thanks for sharing.

It would be interesting to see the addition of phone number validation.

And, it would also be interesting to see a version if you were to extend beyond the UK, taking in those European countries (e.g. Germany) who use the decimal & thousand separators the other way, and countries with no decimal in their currency (e.g. Japan). And, I wouldn’t envy you, but … postcode validation in different countries.

I was about to say something about title dropdown, but then I remembered that I had a friend in an in-house web development team who got a request to update the “Title” dropdown to include “Princess”. Probably context is everything.

@Tom It’s funny you mention international standards, we’re working on resources to help interface designers with design problems in certain markets.

I’ve never been a fan of phone number validation – never really seen the point. When it’s there it doesn’t often work with mobile numbers and digets – the rule set gets complex. Title as you said is really complex especially for multi-lingual forms.

Postcode validation is a similar, tough to validate, easy to get wrong – there’s a great resource here on international address formats: http://www.bitboost.com/ref/international-address-formats.html#Formats

This is a great resource thanks

From work designing forms for businesses, stateside, I’d concur with your approach to populating the address {City} field from the postal code. Do you have a library to which to link for the British postal codes? One UX feature we’ve found that improves participation is to utilize HTML5′s placeholder attribute.

Hi Joe

Thank you for putting together something that should really help all developers get the basics right. Nice work!

Don’t know if you’re interested, but I found just one point a bit hard to grok. In the “No Nos” section, the second bullet point is about using only one field for phone numbers (which I generally agree with). However, because the section is titled “Some no nos”, I initially read this bullet as recommending *not* to collect phone numbers via a single field. Took me a few re-reads to get it right. Perhaps you could just turn it around to refer to collecting phone numbers via multiple fields?

Cheers and thanks again,
Jessica

Great! Very visual and excellent concepts.

Maybe I find controversy on the “no-nos”…
I think that on static very large(complex products like banking/eGov) forms(without js) columns can help users to get the full visual image…

Must say I find it aplicable for almost the 80% of actual webforms…

Thanks for sharing.

Thanks for this great resource!

This question is probably a little too specific but should I take it you recommend using drop down fields for DOB entry? Wouldn’t the number of years you have to account for (as well as validation problems for leap years and February) makes these form controls less than optimal for DOB entry?

Thanks again, Tim

@Bruno we’ve done a few large scale form projects for Government – specifically planning permission and found that column forms suffer the same problem. The form fields in the right hand side are easily missed. Typically one user in 6 missed a form field. It’d be great to see if you have any data on this.
Chunking form data allows the user to see what they have to complete.

@Tim it’s the trade off between error prevention and ease of use. The date/month fields are easy – the year, as you said, is harder. We have used a text box for year before but there is the chance of error…

Thanks for the resource – just read your article on forms via .net and it definitely hit my sweet spot (in a geeky kind of way).

I recently finished off a client site and the captcha code at the bottom said
“are you human?” with the simple sum of 2+4 and a form field for the answer. My client never understood or made the link between the 3 items (the question, the sum and the field) so I had to explain why it was there and what to do with it. None of her friends could understand what it was about either, and no, they were not of lower inteligence (in fact they were the opposite, most of her friends were proffs and doctors). It was a generational issue where I didn’t take the time to understand that most of the people in her circle were in their late 60”s and were not as web savvy as I assumed.

Just a simple issue of not doing my homwork properly to match needs with appropriate solutions.

@Tamixes

Great story. Captha’s are truly awful things and can kill a UX:
http://www.seomoz.org/blog/captchas-affect-on-conversion-rates

How about adding information about the significance of using differently aligned text labels:

http://www.lukew.com/ff/entry.asp?1502

I’m not sure if this has been mentioned elsewhere/already, but how do these guidelines translate to mobile? For example, with the reduced screen area, is it still feasible to align the form labels to the left? Aligning above might allow more visibility of entered content – is it a worthwhile trade-off?

Nice article. During my search for form inspiration I stumbled across the following form design tips.

http://flysoftware.com/support/top_10_form_design_tips.asp

I hope they are useful to your readers too.