Forms that work: Designing web forms for usability


Although we did try really hard to catch all the mistakes in the book, some did creep in.

If you spot any, please let us know.

January 2011: we're delighted to be able to announce that the book is up for reprint and we're hoping that we can get all the errors noted on this page dealt with. Will update this page when we know the reprint is out.


The material in chapter 5, "Choosing forms controls" is based extensively on the paper "Should I use a dropdown" (Sarah Allen Miller and Caroline Jarrett). We knew that we'd likely, and embarrassingly, missed some key people out of our 'Acknowledgements' list and Sarah was definitely one of them.

The cartoon on page xv was drawn by Thomas Bohm.

The cartoons on these pages: 16, 34, 36,50, 58, 72,93, 95, 178 were drawn by Anthony Seldon.

Content errors

Labelling options

On page 96, we say "Describe your options clearly" but then we have a screenshot of a hotel form which includes the options "Low floor" and "High floor". We said "Options called "Low floor" and "High floor" are clear. It's easy to choose with confidence".

Graham Rhind pointed out that these options only make sense if you are familiar with the concept of hotels as high-rise buildings where you might opt for a room on a low floor in the building or a high floor. As he points out in his ebook Better data quality from your web form

"Now, I live in a country full of dinky houses next to canals, with windmills and people wearing clogs. OK, no clogs. And few windmills. But also few high rise buildings. When I first saw this questions (without reading the accompanying text) I could not imagine why somebody booking a hotel would be asked if they wanted the floor in their room to be raised or not – it’s not a question I’ve ever seen on a Dutch site or for any hotel I’ve ever stayed in. It took some time before I realised that the question was trying to ascertain whether I wanted my room to be on the ground floor (or storey) or a higher floor (or storey). So, whilst this was clear to one set of people, I personally would have re‐worded it to make it clearer to more".

He's right.

Moral of the story: test with users, and preferably users from a wide range of different backgrounds.


On page 134, we suggest using the markup <required> as a way of helping people who are using screen readers to understand that this is a required field. We said at the beginning of the book that there's almost no technology in it, and this was a place where we should have left it out. Ben Boyle pointed out that we've quoted an attribute that's available in some JSP (Java Server Page) implementations rather than available in browsers in general. We suggest deleting that line in the table and consulting your favourite programming person about the best way to achieve a good markup of required fields in your preferred technological environment. Ben says that @required is in HTML 5.


Page xvii: the photograph of a usability test is on page 174.

Page 91: On the lower (second) screenshot from Hyatt Hotels, the comment 'I misspelled the city name" should have a 'sad' face and the comment 'But Hyatt fixed it for me' should have a 'happy' face.

Punctuation and spelling errors

Some people have been kind enough to send us notes about punctuation and spelling errors. We haven't listed them all here but please feel welcome to tell us about any that you spot.




Log In


Last Modified 2011-01-21