I actually think it was the web form that got me interested in web design, and later programming. I guess I saw that there was a true art to making a visually pleasing and easy-to-use form online. (Now though, designing a form is about my least favorite thing to do.)

I think we (I know I do for sure) sometimes over-estimate Average Jane’s capabilities and understanding of the web. I try to pay close attention to my friends comments and actions when they use my computer. They probably think it’s freaky the way I study their actions, but it’s useful to me. A lot of times it’s funny—the things they do or say. (Then I realize how dorky I am for giggling at them).

I was checking my email and made a comment about a few spam emails I had received. My friend quipped, sounding as smart as he could, “That’s why I don’t use Outlook Express. It causes too much spam.”

As mentioned in the article, password fields are usually blanked out after posting a form to the server and returning with errors. Although annoying, this is indeed done for your protection. When the form is posted to the server and then redisplayed, the password fields have to be repopulated just like any other field—this means writing the password in clear text to the html source. Password fields are _displayed_ as asterisks, but the source data is written as plain text from the server. In fact, in signing up to ALA to post this remark, I tested the form and found this very issue! (Fill in a password field but leave another required field blank, submit the form, then view source.)

Now, what are the odds that I’ll submit the form, then leave my computer unlocked with the partially-submitted form visible so that someone could or would actually find my password? Probably slim. However, don’t forget that now that it’s been written in clear text to my browser, it’s also sitting *in clear text in my browser cache* as well (indeed, to verify this, I simply browsed to my browser cache folder, did a quick ‘search in files’ for the term ‘password,’ and voila - there’s my cached ALA form entry with my password as clear as day). Probably not a good thing if someone with this basic knowledge ever compromised my machine, especially since most people use the same password for many sites. For this reason, websites should generally never write passwords back to forms _from the server_ (client-side validation does not have this issue, of course, since no data is ever written back to the form until the form contents leave the client).

Another thing to remember abut phone numbers: Some of us are from outside the US. And it’s not very obvious how to fit an 8-digit phone number + a 2-digit country code, preferably prefixed with a ‘+’, into a standard US phone number format…

Same kind of thing with a state choice: it’s always nice when there is an option for leaving it blank. We don’t have ‘em here ;)

And if the form is supposed to absolutely only cater for USAians, please make that clear from the very, very beginning. I probably can’t count how many times I’ve filled one out only to find three screenfuls later that sorry, this is only valid for citizens of the US. The ‘net is global - so plan for it.

Amen for “opt-ins” over “opt-outs” on email newsletters, but I don’t think that message will be heard soon. In my opinion, email newsletters should be on their way out thanks to RSS, but sadly I know they’ll stick around for quite awhile.

Overall a solid article. I can’t stress enough how important it is to have small forms. Whenever I hit a site with a massive 15+ registration form, I often skip it. I have a friend who won’t register on just about any site. Not due to security concerns, but due to laziness. He’s been using digg.com, slashdot, ESPN for months now and hasn’t bothered to get an account on any. Whenever a form comes up he hits the back button. So the most important question when thinking about a form is “is it really necessary?”

Thanks for your insightful comment about the issue of password security. I’d thought about this very thing when writing the article and it occurred to me shortly after submitting for publication that perhaps I’d left that a bit to open-ended. Perhaps this security issue is a problem with the architecture of forms themselves and not really a flaw caused by designers.

Password security is important; but I believe there is a way to make it work without sacrificing clean interfaces. -BC

I think that there should only be one phone box, and let the user enter however it should. Not only is this recommended for US users, but even more important for international users, since not everyone has a 10 digit phone number. Also, since the US is not the only country in the world, it shouldn’t limit or require the state box. Or if it requires it, only for US residents. There have been numerous times when I had planned my trips to the US, but felt crippled as to what I could do INSIDE the US because I have to call a 800 number in the States, or the online tickets were good only for residents. I can understand some services (like grocery delivery) being limited, but it shouldn’t be that way for concert tickets or other entertainment sources.

—A disgruntled expat who is frustrated at the lack of internationalization sometimes.

The article advises against using these, but they are an important web application interface widget in my opinion (we aren’t all using forms for simple marketing and contact purposes!) How else would one go about allowing the user to select several options from a large list (too large to think about checkboxes)?

Even though it makes absolutely sense to use a checkbox for a Yes/No question there are reasons to use two radiobuttons in stead.
I work for a insurance company where we need the user to actively give an answer, leaving a checkbox unanswered is not an action.
Also on top of that almost all our questions are mandatory, a telephone number is one of the very few exceptions to that rule.

Most of the stuff to look out for is well documented in the article (good job on putting together such an easy to understand piece). It’s good to see it written down (rather than sloshing around in my head).

Instead of supplying those massive long lists of countries to choose from, why not let the user type it in as well as choosing from a select dropdown? What about grouping the “most common” countries into a select dropdown and providing a regular text input for others? That’s certainly more usable for a wider audience.

What really gets me is the decision to require users to fill out a ZIP code. If the user selects USA then by all means provide a ZIP code as mandatory… but we don’t have ZIP codes here… and whilst they are often called Postcodes outside of the USA, they are by no means well known (in all countries) and certainly not used outside of business correspondence (in many countries).

The use of labels, legends, fieldsets and non-mandatory fields are what makes me bother to come back to a site (ok… and great content - thanks ALA).

Be careful what you wish for, I run into a lot of websites that want me to fill in a phone number or email address. Without those I can’t submit the form. It happens to be that my grandfather ordering that particular set of classical CD’s does not have an email address. And in my personal case: I don’t have a phone number. I use Skype.

In fact I’ve noticed the very company I work for lose a lot of subscriptions by asking people what state or province they live in, and making that a mandatory field. Some countries don’t have states or provinces.

As for wanting a certain input for a phone number, don’t spread it over multiple fields but keep it simple (that principle alone saves hundreds of Euro’s every day). As noted by someone else: autofillers don’t particularly like a phone-number field that is actually 3 fields.
If you really want to receive a format you like to read or one that your database works best with then format the number server-side.

I’m regretting leaving out mention of international issues when using forms. To all of the international users who have responded here, thanks for your input and I hope you realize that many of the principles I’m putting out there (such as allowing *any* format of input for a telephone number) are extremely beneficial for International users as well.

As far as multi-select boxes go; you’re not going to convince me that it is not a confusing and haphazard field for most users to work with and my take on it remains the same. If you’ve got a list that big to choose multiple items from; maybe you need to take a look at your information architecture and break it down into more manageable sections. That said, I do believe there are exceptions to every rule and the multi-select box *can* have its place. But, as you said, that place is in web applications, not websites.

bq. Be reasonable; are we so afraid of regular expressions that we can’t strip extraneous characters from a single input field? Let the users type their telephone numbers in whatever they please. We can use a little quick programming to filter out what we don’t need.

Amen to that, brother. Even more annoying is credit card forms where the developer requires a 16-digit number with no spaces or other separators (despite that being the way it’s printed on the user’s card and being easier for the user to confirm the number). What’s so hard about stripping out those non-number items on the validation end?

I recently did a form for an insurer in the PNW(Pacific North West), so NANP(North American Numbering Plan) phone numbers only, where I wrote regular expressions to strip out any user formatting (spaces, dashes, dot’s, etc. ) and to change mnemonic numbers to numerals (CALL-ME = 225563). While I was at it, I even checked the formatting of the number itself:
* does the number begin with “0” or “11”? (reject as non-direct-dialed NANP number)
* does the number begin with a 1 and then a 2-9? (drop the unnecessary ‘1’ from the Db entry)
* is it exactly 7 digits long? (alert and ask for the area code)
* is it longer or shorter than 10 digits (after dropping the leading 1)?
* does it follow the numbering pattern of the “NANP”:http://www.nanpa.com/number_resource_info/ ?

I was even able to ultimately check for bogus, Hollywood-style fake numbers (of the “˜555’ ilk) using the info at NANP. It really wasn’t too hard to write the regular expression to do all of this—it took more space to describe it than it did to write the regExp. The benefits are that a user can enter the number in any format style with which they’re comfortable, while giving the insurer the best chance possible of collecting valid user phone numbers (used for customer i.d. verification in this instance, not marketing purposes).

I’m sure with a little research, the same could be done to handle international numbers as well. There’s some excellent links off of the NANP site to some of the international numbering standards sites.

Good read. Too bad those who need it most will most likely not read it.

I agree that a little more info than “Credit card didn’t work” or whatever should be in order for the user. However, hackers love descriptive error handling. The hacker looks for anything the developer will give him/her to find vulnerability. When a developer is too descriptive it can result in tipping a hacker off into how close they are to adding some cross-site scripting or sql injection or whatever else. Maybe a good option would be to provide a link to the administrator’s email upon finding an error dealing with transactions or errors that are bigger than the simple form validation.

One problem that afflicts larger forms, is when drop-down menus have no default option. If you are in a hurry, or lazy, or haven’t read the form (me, me, and me) it is easy to progress to the next step without remembering to select your appropriate option.

This has caught me out in two very important areas. First, my online banking system has a drop-down menu for payees. If you are paying several invoices to the same people, it is easy to forget to select the payee each time. I’ve also booked flights online FOR THE WRONG MONTH because the ‘default’ was set to a month hence, not the current month. In both cases, a default null value would have ensured that, if I forget to make a selection, I don’t waste my money.

I completely agree that forms should accept phone numbers and credit card numbers however the user chooses to enter them but I don’t think it hurts to indicate what the preferred format is.

We’re used to forms being picky, both on and off of the web. Forms are usually associated with something complicated and exact like tax returns or job applications. If it’s not filled out as intended, we _expect_ something to go horribly wrong. Normal text input boxes don’t offer a lot of guidance as to what should be in them and that can be scary.

As a web-saavy user I’m never sure if the phone input is one long text box because the form designer is considerate and will accept whatever I throw at it or because the form designer just got lazy and forgot to specify that I need to include a space after each number and a semicolon at the end or it will blow up. I spend valuable seconds trying to guess what the form _wants_ me to do.

Maybe even if you don’t have a preference on format you could somehow indicate that all permutations of 10 digit phone number are accepted and offer examples.

I ran across this link earlier this morning. While it ignores the issue of being able to select multiple consecutive items using the Shift key in Windows, this behavior could be duplicated with a little extra JavaScript.

“Scrollable checklists”:http://c82.net/samples/checklist-samples.html

I think it makes this functionality more usable… especially since all web users aren’t savvy designer and developers.

A great article for sure, but a few examples would go a long way. I’d like to know what is considered good form (ha) for label, caption, fieldset and legend elements.

Also, is there a framework or good piece of source code that someone could share for reusable forms that validate input? Something PHP driven would be great. A good regex example for telephone validation would go a long way here as well.

In regards to the comment about descriptive error messages. To an extent ‘hackers’ like them. However the name of the game is to make your scripts secure. The first step is to make your forms as strategic as possible - This is the best way to have a sure footed direction for your form validation as well.

Example:
A phone number consists of three separate entities - which can simplify the data entry by providing three fields, 2 with a max of 3 characters and 1 with a max of four characters. The form validator only has to validate whether the fields are numeric or not - As opposed to stripping and separating dashes, parenthesis and other odd delimiters; (By saying odd delimiters this goes for ‘dark’ methods of input as well.)

Justin, a North American phone number is not simply 3 numbers followed by 3 more followed by 4. There’s more to check there if you want to get a valid NANP number. Area codes always start with numerals 2-9; so do prefixes. It’s also possible to spell out a phone number with letters; and while the average phone number is just numbers in most peoples address books, why force the end user to figure out that ‘d’=‘3’ on the dial pad? That’s just lazy.

Allowing one field for entry (and allowing the user to enter it as they prefer) is just plain user friendly. The more separate fields you force a user to tab through, the less likely they are to complete the form. Sure, to answer someone else’s comment, you might provide an example of the suggested format, but not all users will even heed that as they fill in the form.

Good article. It didn’t mention much about when the programmer changes what the form fields are supposed to do. Many times I have clicked on a radio button that let me to another page, and it made me scared of the whole website.

This is about the proud programmer, who believed that pulling off some cool trick, people are going to think that what he did is awesome. Other programmers would probably think so, but normal people will be scared off by his gimmick. Just because you can do it, it doesn’t mean that you should!

Another proud programmer is the one who thinks because he can program a form, then he’s the elite person who shouldn’t listen what other people, like the author of this article, is saying, so he just goes off and does it his own way. People should be thanking him that he programmed a working form in the first place! he thinks. And that’s also bad.

I actually do read a lot of these articles on usability, and I live on Jakob’s website, and there is still much I need to learn.

Very nice roundup. You mentioned the importance of the label tag for accessibility. I would like to add that the indication of mandatory fields should also be included inside the same label element. If it’s not, screenreader readers are forced to leave the ‘forms mode’ to find out which fields are required to fill out (which can be quite time consuming). By putting the asterisk (or whatever you’re using to indicate mandatory fields) inside a span (that’s nested inside the label element), you can style it differently and even float it to the right of a text field if you’d like.

You should be glad you don’t have to use select boxes to choose your street type and house type. When creating/modifying an address on our website you must manually select from a list of hundreds of different types of streets and units, with no way to simply type them in.

One of the choices for unit type is “Igloo”, and perhaps your Igloo can be found inside a room, yes a room (as in street type). Why we have to do this I do not know, nor do I know why I’m not allowed to use checkboxes and radio buttons anywhere on the website, or why you have to “select” your birthday from drop downs.

At least one doesn’t have to select their name.

So even though I completely agree with this article, I just wanted to remind everyone that designers rarely have the input they deserve (at least for me).

Good article but I am surprised nobody has mentioned unnecessary JavaScript in forms. I have seen many forms with no submit button but instead a link with “[removed]submit()” as the target. There is no conceivable reason for doing this and it breaks just about every usability rule including preventing users from submitting with the enter key.

Just out of curiosity, caption is mentioned in the context of forms and labels. I’ve only seen it used to label tables, which is consistant with what I’ve seen in the w3’s docs. I saw no mention of a change in the caption element for xhtml 1.1, am I missing something?

bq. As far as multi-select boxes go; you’re not going to convince me that it is not a confusing and haphazard field for most users to work with and my take on it remains the same.

Absolutely agreed. I have to support a couple of web-based services at work, and both of these use multi-select boxes with potentially 50 or more entries - fortunately they are optional ‘enhancement’ features rather than essential to the use of the site. Even though it says clearly by the side “Press Ctrl+Click to select more than one option, *and* it explains this in the instruction manuals I wrote, *and* I point this out whenever I am showing someone how to use the system, it still seems that the majority of people are unaware they can select more than one entry.

I think a key problem is that it looks too much like a normal drop-down select menu, and a lot of people don’t twig that it is different.

One website that I use quite a lot is for looking up train times & fares (UK) - “Qjump”:http://www.qjump.co.uk/ - and there are three aspects of the enquiry form that irritate me.

One trivial one is that when you mouseover a field, it highlights the entry by turning it lime green. This means that if you click in a field and type, without moving the mouse, you can barely read what you’re typing.

A second is that if it doesn’t recognise the station name you type in, it gives you a huge long list to choose from without making an attempt at a “best guess”. Far better for it to suggest the most likely option, and list the others below in case it was wrong.

But the third, and most pertinent to this article, is this. If you select “one-way journey”, but then enter a date a/o time in the section marked “return”, instead of ignoring that data, it spits it back at you and rudely tells you that you are *not allowed* to give a return date when you’re making a one-way journey.

In comment #20 Justin wrote:
bq. [...] by providing three fields, 2 with a max of 3 characters and 1 with a max of four characters. The form validator only has to validate whether the fields are numeric or not [...]

_Never_ rely on the fact that you are only receiving _n_ characters because your forms have such an attribute set. You could end up inserting a little more than you wanted. ;-)

Ah yes - I got a little too literal in my description of what I wanted to achieve. I wanted to paint a verbal picture on how one could lay out a phone-number entry without making users enter their own delimiters.

However, the validation methodology still stands - is it alpha/numeric?

I just have one question about the description of the <caption> tag. You write:

“Employ the <label> tag to ensure accessibility is maintained for all users. Also, make sure your labels are descriptive enough that users do not question what is expected in that field. Field names should be clear and concise. If additional information would be helpful, XHTML 1.1 provides the <caption> tag to add a descriptive caption and provide proper accessibility. For the less adventurous, you can always create small caption text using traditional XHTML 1.0 markup and CSS.”

I thought the <caption> tag was added around HTML 3.2? Second I thought it was only meant for use in tables (see “W3Schools”:http://www.w3schools.com/tags/tag_caption.asp ) - or am I missing something here?

After reading the article it got me thinking and I wrote a few thoughts on the subject of form usability. Feel free to visit “my post on justaddwater.dk”:http://justaddwater.dk/2005/12/23/sensible-forms-a-form-usability-checklist/

Excellent article, Brian. Another benefit to the single-field phone number is the accessibility aspect of only needing to label one field. If you have to label three, what would you call them? area code, prefix, and last 4? Suffix? Who would understand that in context? Thanks again!

Great article, and easy to read and understand. I also heartily agree with Poster 4. My biggest beef with forms, is having to take the trouble to fill it all out… for example, for a free DVD describing the shop’s wares… and only after it is all filled out, finding they do not ship outside the U.S.

Sometimes, to satisfy my curiosity, I search the site for where I may have missed this info… and it is buried on some page in a small font, but is definitely not anywhere near the form page or within the form. I think such info needs to be made explicit. My suggestion is to put this type of info directly under the Title of the Form, something like “We do NOT ship outside the U.S.” It doesn’t hurt, especially if the form is a tad long and requires scrolling, to reiterate this message again, on top of another form section.

Although I am giving a specific example, I think the basic idea is a more general one: Let your audience know whether or not the Form even applies to them. The cardinal rule I would like to add goes something like: “Your users’ time is precious. Never waste it, or make them go through filling out a form unnecessarily. ALWAYS let them know whether or not a form applies to them, by stating these things clearly and upfront. Let them know if only people filling a certain criteria can apply.

Off the top of my head, another example might be if only VISA is accepted… shouldn’t you let people who may only have other Credit Cards, or none at all, know that ‘at this time, only VISA cardholders can complete the transaction’?

Always use a https:// address for any form that contains any sensitive data (and pull all elements on the page from the https:// domain so the users don’t get a message about secure and non-secure items!).

A properly set up browser won’t cache data from a secured web site so your credit card details won’t be cached unless you overrode the default browser settings and enabled caching of secure web sites.

I’m like the others who despise forms that make information I don’t think the company needs for any valid purpose as mandatory and as much as possible when I hit such a site I ensure they get unusable garbage ( bitbucket@edgeoftheinternet.drop is my favorite email address :) ).

If your form requires cookies, please say so, if only as an error message (this means you AListApart; I just spent several minutes trying to log in before I realized what was going on).

JavaScript

If your form requires JavaScript, rethink, but if you must, use a <noscript>This form requires JavaScript.</noscript>

Autofocus

Don’t autofocus on the first field on page load. I can’t count the number of times I’ve typed the first field and started typing the second (usually a password) when the page finishes loading and I wind up typing all or part of my password into the first, visible field. I also suspect this might be an accessibility issue for folks using screen readers, but I can’t say for sure since I don’t use one.

If it’s not an accessibility issue, then be intelligent about it and don’t autofocus if I’ve already started doing stuff with the page (typing, scrolling, tabbing through links, etc.). (And if the form isn’t the page’s sole purpose in life, then how do you know I want to fill in the form at all?)

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.

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 user@domain.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.

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.

bq. 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 * if writing “required” in full would make it look too cramped or untidy.

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.

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.

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?

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.

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.

As a general point, I would suggest that form elements should behave as they do ‘out of the box.’ All browsers make form elements look and behave in the same default way - if web developers stick to this, then users don’t have to deal with small changes and quirks specific to individual sites. In particular,

1. Avoid javascript unless absolutely necessary. You may think you’re helping the user with some javascript ‘trick’ but it probably just confuses them.

2. Avoid using css the style a form - forms can be made to look neat without changing the elements themselves.

Your article was great… thanks! I was wondering what your opinions are regarding when to hide versus when to disable buttons on a web form? I am having quite a bit of trouble identifying any standards or conventions regarding this and am now just curious what people think. Any thoughts??

As far as disabling versus hiding buttons on forms; I consider it to be pretty situational. In my own opinion, it is almost always better to completely hide options rather than disabling them. Few things can frustrate users (including experienced users on this one, as I’ve definitely been in these shoes) like seeing an option that they would like to choose but are not allowed to for reasons seemingly out of their control.

As to the commment about constraining user input for data integrity:

The issue of whether or not state abbreviation should be a list of choices or a 2-character input text box is likely just going to generate a lot of debate from both sides of the argument. In my own opinion, in this case, there is not a significant advantage or disadvantage in terms of general usability and I believe that even users will debate over which whey they prefer. That said, the cleaner validation on the server side does make an argument for the select box.

Brian, great article, covers just about everything one can think of while working with forms. Now coming to my opinion on why form usability is still a prerogative of the “big” or the “hifi” websites. Usability, by itself, if followed to the word, takes more effort, more specialized knowledge and maybe even more manpower. Maybe if developers used better evolved frameworks which address atleast form usablility we may be able to overcome this problem.

Charles Belov says:
_If your form requires JavaScript, rethink, but if you must, use a <noscript>This form requires JavaScript.</noscript>_

I believe that using the noscript tag is a good idea. However, the brevity of the message can cause more harm than good. There are a lot of web users, some having websites of their own, who know little or nothing about Javascript. The message, “This form requires JavaScript.”, would only frustrate or confuse them, as they wouldn’t know what to do to satisfy the requirement. However, the noscript tag is a vital complement to the script tag, so what’s to be done?

One possible solution is to do it the way we do. We give the user brief “information about Javascript(what Javascript is and why it is required) “:http://www.xqst.com/faq.cfm#technical_faq1

“There are a lot of web users, some having websites of their own, who know little or nothing about Javascript.”

Those people are unlikely to have disabled Javascript in their browsers.

Oh, and I’ve got a sock puppet on my hand with a “Brian Crescimanno” name tag. Now I’m making it say “Hey Mike, those 7 people who made comments are right; the <caption> element is only for tables. I was absolutely mistaken.” It’s okay, sock puppet Brian. We all make mistakes.

Great article! I especially loved what was said about formatting input. As you said in your opening, computers are supposed to do work _for_ people, not make it more complicated. Some simple regex is the way to go.

Good article — too many websites have lengthy forms that require way too much information. I think people forget it’s an inverse relationship between the number of form fields and the successful completion rate of a form.

What is a good UI design to capture user’s address
information in a order form for example? I’ve tried using two or more normal input textfields and also single textarea. Both with different feedbacks from users.

Ok, here goes, please be gentle. I understand that one is encouraged to use a checkbox for yes or no; but I can’t understand why! If a radio button is either one or the other, and a checkbox can be for many, why the preference?
Thank you,
B.

I’ve found a few recommendations to show the asterick after the label or field. And I disagree. I’d like to see the asterick appear before a label so that a user’s not forced to read the labels and fields before noticing the asterick. What do you think?

What continues to astound me is that, whether it be a multi-million dollar company or your local muffler salesman, websites are riddled with elementary usability problems. As an experienced writer, I am always more acutely aware of content and am often over zealous with my criticisms. As a usability analyst, however, such harsh criticism is inspired by the apparent lack of thought that is apparent on so many sites. Simple, effective, changes deliver a much better user experience but, apparently, such components are just not important to the company and thus, neither are the customers’ experience. Incredible.

I would think that the division of a medium/long form into multiple columns (possibly two) would have the advantage of appearing short (or not overwhelming eg. https://account.atlanticrecords.com/wallet/NewAccount.asp). Does this have significant disadvantages compared to a single-colum forum in which the user can move vertically without interruption? thanks.

“You can also use CSS to hide the fields that are already filled in correctly and only display those which need to be corrected.”

Why use CSS? CSS is for design. This is not a design element, this is a behaviour. For define behaviours of our document, we have to use JavaScript. Imagine if the user clears away the stylesheet, or defines his/her own.
First the (x)html, then write JS, and CSS should be the last component.