Usability.gov has an interesting article on converting paper forms to online forms. What is striking about the article is how many fields paper forms have, and how those fields do not translate to the web. Additionally, web forms with too many fields confuse users. Here is a list of lessons learned that the article points out:

• A form that works on paper may not necessarily work online.
• Don’t ask for the same information more than once; collect only information that you are going to use.
• Provide a logical structure.

And then the article goes on to point out 6 usability issues to keep in mind when designing the web version of the form:

• Avoid using jargon; use clear, simple language for all field labels and questions.
• Provide a context for filling out the form.
• Include field formatting instructions, if necessary.
• Ensure form elements (widgets) can actually be used.
• Ensure all questions are worded clearly.
• Reduce cognitive load in a form; don’t make users think (humans don’t think like a database).

Overall, the change is drastic, and I find the web version of their form much more pleasant to look at. You can also note that they opted for label placement above rather than to the side. You can compare the paper version and the final web result. In addition, I created a copy of the form using Wufoo. 10 minutes later I had a fully functioning form with validation that met all of the usability requirements.

One feature request that we’ve received a few times is for the ability to add multiple columns to a form. You can currently float form fields alongside one another using a little bit of custom css, and we’ll discuss adding multiple columns into the form builder itself, but you might want to take a look at MarketingSherpa’s Email Marketing Benchmark Guide 2007 preview before placing more than one field on a line. The entire report costs $247, but if you take a look at alert #2, you’ll see that the forms built with one field per line are the “winners”, while those with multiple columns are the “losers”.

As Kevin had said before in his article on label placement, “when it comes to filling out a form, you want your users to spend less time understanding your form and more time filling it out.” When fields are top down and predictable, the form often appears less complex and increases the probability that a user completes it.

When it comes to filling out a form, you want your users to spend less time understanding your form and more time filling it out. Over at UXMatters, Matteo Penzo wrote a fantastic article detailing the results of some eye-tracking studies he’s done on the impact of label placement in relation to form elements.

“Input elements should be organized in logical groups so that your brain can process the form layout in chunks of related fields.”

Obviously the closer you have the label to the input element, the less fixated the user is on trying to figure out the association between what the form is asking for and the task that needs to be accomplished. Since there’s a pretty good relationship between cognitive processing and eye fixation, the lower the fixation the faster the field is being processed. The big question, however, is if it’s faster to put the label to the side or above the field. Here’s a quick overview of some of the results.

• Labels to Left and Aligned Left : 500ms
• Labels to the left and Aligned Right : 170ms for Experts and 240ms for Novice
• Labels Sitting Directly Above the Field : 50ms

What’s surprising (even to us) is that putting the labels directly above the field (like we do with Wufoo form layouts) is almost 5X faster for the user to process than putting the labels next to the field.

“Placing a label right over its input field permitted users to capture both elements with a single eye movement. Also, if a label indicated data that was very familiar to users—for example, their first name or family name—users did not fixate on the label separately to read it.”

Definitely head over there and check out the results for yourself and let us know what you think. It’s a great read and I really appreciate the guys at UXMatters for taking the time and resources to share the results for free. Thanks to studies like these, hopefully, form designers will have more information in their arsenal to build forms that are inherently faster to understand and fill out.

In regards to how this will impact Wufoo designed forms, we’ve always been fans of the label above layout and since a majority of the forms created on our system are short forms, we’ll continue to leave this placement as our default layout. We are, however, closing in on providing a way to allow users to attach their own CSS file on their Wufoo forms so they can customize these layouts to their heart’s content. Currently, we’re working on providing the appropriate CSS ids and class hooks to give designers the most amount of flexiblity when this feature goes out. Any suggestions or requests on this feature are always welcome.

In July, we opened up discussion on how we should handle radio buttons and the ability to have no default selection. Feedback from the community was fairly balanced, but in the end we decided to make it so that you can create radio buttons without a default selection. The reason we took out forced default selections is because we wanted to give as much flexibility to the Wufoo admin as possible. Now, you can create both an unselected radio group and a radio group that has a default selection.

Be sure to read about this change and others that went out in the Wufoo 1.0.5 update.

We’ve had some internal debates and looked at the feedback from our users over the default behavior of our Multiple Choice field (or radio inputs to you Web Developers out there). Right now, when you make a radio group (called Multiple Choice in the builder), and do not select a default option, we automatically make the first option the default for you. One of the main reasons we do this is because of the W3C:

At all times, exactly one of the radio buttons in a set is checked. If none of the <INPUT> elements of a set of radio buttons specifies `CHECKED’, then the user agent must check the first radio button of the set initially. View

In addition to the W3C, various user interface books we have come across stress the importance of making one option selected by default. The “proper” way to make a radio group would be similar to below:

What is your favorite day?

• New Years
• 4th of July
• Thanksgiving
• None of the above

In that example, “None of the above” would be set to default. You can also use “Other”, or if the data is numerical you can do “Greater than” or “Less than.” The reasoning behind this is that it always gives the user an out in case they accidentally clicked one of the selections.

Now, even though the way Wufoo currently handles radio buttons is “right,” we’re not so sure it makes things easier for our users. For example, consider a multiple choice test you take in school. Most of the time, there is no “All of the above” answer. The student is left to pick one of four choices, and none of those choices are pre selected. In fact, a pre selected choice may even place bias on that choice.

We wanted to open up our internal discussions, and get your feedback. Should we automatically select a default radio button for you, or should the radio group load with no radio button selected?