Discuss: Sensible Forms: A Form Usability Checklist

by Brian Crescimanno

41 And about asterisks

I’d say if a field is required, use the word “required”. Using an asterisk means the visitor has to look for the footnote, which might not be on the visitor’s screen at the moment depending on how big their browser window is. And even if it is onscrenn, they still have to find it.

posted at 12:57 am on December 31, 2005 by Charles Belov

42 A lot depends on target audience

One thing that wasn’t strongly forced in the article is that your form design matters depending on your target audience. On my current project, our audience (insurance agents) are used to entering data in short question/answer forms with multiple steps and/or pages. They generally do not like large forms. On my previous project, our audience was mortgage brokers. Brokers are very familiar with very picky and long forms — no multiple pages for them.

Regarding e-mail validation: don’t bother trying to validate an e-mail address using a package that tries to send a test e-mail. Many large ISPs and companies use virtual mailboxes. The server universally accepts mail to domain.com and THEN sorts out if userdomain.com actually exists. If you are trying to write a regular expression, anything less than the regular expression in Perl’s Email::Valid module (http://search.cpan.org/src/MAURICE/Email-Valid-0.15/Valid.pm) is not enough.

Also, don’t make your own widgets! I see too many sites now that use their own radio button image to match their style and hack it in with JavaScript. That completely destroys any familiarity a user has with form elements. Elements match the operating system for a reason. This falls under “too much CSS!”, too. One of the biggest blunders I’ve seen in form dsign are websites that switch the scrollbar location on textboxes from right to left.

posted at 08:04 pm on December 31, 2005 by Eric Brown

43

With regards to the poster asking about the legend tag: sometimes usability and accessibility need to take a front seat and having your form look “pixel perfect” on all browsers becomes the second banana. That said, you might also consider less sophisticated styling. My experience with the legend tag is that as long as I keep it simple, it will generally work.

Designing for your audience is just good design principle in general and should apply to your entire site design; not just your html forms. My thinking when writing this article was to address issues in “general forms for the general public.” Obviously, as your audience changes, so do aspects of your design.

posted at 05:25 pm on January 1, 2006 by Brian Crescimanno

44 Required

I’d say if a field is required, use the word “required�?. Using an asterisk means the visitor has to look for the footnote, which might not be on the visitor’s screen at the moment depending on how big their browser window is.

As an alternative, use <abbr title=“Required field: you must not leave this blank”>*</abbr> if writing “required” in full would make it look too cramped or untidy.

posted at 10:38 am on January 3, 2006 by Stephen Down

45 Stop With the Same-Width Fields

I can’t stand forms where all the fields are the same width. Someone somewhere is trying to make a form “pretty.”

Why on earth would address2 be the same width as address1? Make it smaller. If “state” is supposed to be a 2-letter code, why make it the same width as email address? People don’t think, so they need the form fields to look about as wide as the data they’ll type in.

posted at 10:59 am on January 3, 2006 by Ben Chestnut

46 examples?

This is not the high quality article that I’ve come to expect from ALA. Where are the examples?

posted at 03:55 am on January 5, 2006 by h b

47

What examples would you like to have seen? There were suggestions and recomendations for best practices scattered throughout the article. One of the few places I think an example might have been warranted is some example php (or any language really) to perform proper telephone number and credit card validation; but these can be found quite easily. I don’t think we’re trying to reinvent the wheel here. Nothing in the article involved any type of advanced coding techniques that would merit technical walkthrough; but if there is some point I can help clarify for, I’d be more than happy to.

posted at 02:08 pm on January 6, 2006 by Brian Crescimanno

48 Validation Method: Client or server?

What happens after the user clicks the submit button?

One thing not mentioned in the article or comments is a preferred (in terms of Nielsen-esque “usablity”) form of telling the user that there were errors in the submission. Possibilities include JavaScript alerts, AJAX feedback (continually submitting the form), traditional server-side validation (refreshing the page), and probably more I haven’t considered. Any preferences there?

I’ve always tended toward JavaScript alert boxes so that I can know the data going into the database is what it’s supposed to be, but I know plenty of people don’t have JS enabled (which would rule out AJAX as well).

And while server-side validation is nice, you then have to do some database interaction with incomplete/incorrect data and then figure out how to re-populate the page with everything the user entered. Which is fine for text fields and textareas, but gets into not-so-fun DOM work to select the right item from a pull-down menu and which radio button to select, etc.

Not sure there’s a “right” answer here. Should fields with errors be highlighted? Brought into focus? Field labels changed?

posted at 10:37 pm on January 6, 2006 by Kevin Bolduan

49

Using an appropriate server side language (php, jsp, asp, etc.) you do not necessarily have to hit the database at all. Simply validate the data with your server side application code and return the form that way.

Javascript (and thus, AJAX) can be a usable solution, but only when used in conjunction with true, server side validation. There is simply no reliable client-side validation that can be done; but those who do have javascript enabled might appreciate its use anyway in this case.

posted at 12:12 am on January 9, 2006 by Brian Crescimanno

50 Special XHTML 1.1 Caption?

I’m a bit confused by the Brian’s mention of the <caption> element within a form context. By looking at the XHTMl 1.1 spec, caption is only allowed as a direct child of a table element (see http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_tablemodule)
not within a form or fieldset (or as a child of any other element for that matter). In the article, it sounds like one could use caption anywhere.

posted at 10:45 pm on January 9, 2006 by Marcos Caceres