Review of "Web Form Design, Filling in the Blanks"

“Forms suck. If you don’t believe me, try to find people who like filling them in.”;

Are you kidding, I paid for a book that begins like that? My first reaction was that I could have written that! Well I didn’t write it, and I also feel that I got my money’s worth out of Web Form Design, Filling in the Blanks, by Luke Wroblewski.

Forms are hard. I don’t think I need to mention how hard they can be for users… nor do I need to mention what’s at stake if a user finds your form too difficult. Every web developer who doesn’t have his/her head in the clouds should know that. Forms, however, are also very difficult to create… correctly! A well designed form requires a lot of careful, detailed thought. You have so much to consider… usability issues, accessibility issues, and you usually don’t have anything to go on except for your personal experience. This book will help you methodically approach form design, and give you the experience of an expert to guide your decisions.

Web Form Design is useful, because Mr. Wroblewski takes a very detailed approach to each aspect of form design. Within each chapter, he thoroughly analyzes the major elements to consider when designing a form. For example, the chapter on “Actions”; is devoted to action items such as submit and cancel buttons. One of the sub-sections discusses where to place these items on the page. The author first presents the reader with the following image demonstrating all of the reasonable placements for the submit and cancel actions.

Using eye-tracking and usability data, he then discusses the pros and cons of each arrangement, without ever deciding one is better then all others. This is key because it lets the reader, knowledge in hand, decide his/her own course of action.

The book is especially valuable because of the user data, eye-tracking data, and case studies presented within. Mr. Wroblewski’s backs his reasoning with either a summary of these tests or with an example culled from his experiences. He reinforces his points with a number of demonstration images, all available from the book’s flickr page. Then he includes a short “best practices”; section to close each chapter, outlining what was discussed. These can be used almost as checklists. Interspersed in the text are sidebars which present real-life examples and perspectives from numerous field authorities.

Using the label element for form accessibility

I’ve always been a fan of the <label> element. It’s an incredibly simple way to make a form more accessible. It does two things:

• It explicitly associates text with a form element, so a screenreader doesn’t have to guess what text goes with what form element.
• For checkboxes/radio buttons, it gives the user a larger click area, which is useful for people with limited vision (or me, since I always end up missing them!)

You can find a number of simple usage examples on the W3C’s WCAG Techniques page for labels.

I recently discovered something new about the <label> element (new to me). I hadn’t realized that you can associate multiple labels to one form element. This is useful because it allows you to associate even more information with a form element. With it, I could write something like this:

<label for="box">1. </label>

<input type="checkbox" id="box"/>

<label for="box">This is some text with a 

<abbr title="full title name">shrt. title</abbr> other stuff inside.</label>

This isn’t the most useful example, but I think it demonstrates the general idea. [Note: normally, I wouldn’t write out an explicit number, I would use an unordered list. But without major support for CSS counters, I find myself between a rock and a hard place.] My optimism was quickly quashed though, because, as Roger Johansson mentions, screenreaders tend to ignore two labels. I will have to do some of my own testing to find out more, but I find this very disappointing.

Another interesting application is to include labels for screenreaders, while using CSS to hide them from visual users. Just make your label a block element, give it a 0 width (to remove the width it would have taken in the document flow), and move it off-screen. You cannot simply display: none the label, as that usually hides it from screenreaders. I would like to look further into the end result using current technology (hoping for improved results since 2004), but I certainly believe this leaves no excuse for anyone NOT including labels in their forms.

Back to using one label again, I ran into a Firefox Bug where a link is included in a label element. When a link is clicked inside a label element that is associated with a checkbox, the checkbox becomes checked! Hit the back button, and the item will still be checked, with the visual check the only evidence anything happened. You can see how this would not be friendly to a screenreader (not to mention visual users!) IE and Opera both behave without checking the box. If you have a moment, please vote for this bug and help me get it fixed.

Website usability annoyance no. 1

When you do a search, and you click on a deep page. The website makes you login, which you do begrudgingly. Where do they take you? To your home page. Do they even offer to send you to the page you were looking for? Almost never.

Come on, guys & girls. That’s just too easy…

Thought for the day

My thought for the day is this:

Everyone should keep usability in mind while performing their job. While creating something (especially like a website), some aspects end up being unrelated-graphic design to programmers, implementation details to designers, etc-however usability should be an part of every aspect of the creation process. There are an unending number of uses to design for, the least we can do is succeed for one or two.