Howto build a form that isn't annoying (Part 1)

January 11, 2006
web

As a web user filling out a form tends to be a most dreaded activity. While forms will always be mundane to fill out, it is possible to create forms that don't drive the user crazy.

I'd like to challenge some common bad practices, and promote some best practices that are often ignored. My hope is that it will generate some discussion, and with any luck - less annoying forms.

This is the first of a multi-part series on building forms that don't suck.

When asking for a country, use the 2 character country code

Unless you live in Afghanistan you're probably aware that scrolling through hundreds of countries to find yours is annoying.

Fortunately the International Organization for Standardization has defined two character country codes for every country. Wouldn't it be a lot easier to just type in two characters?

Yes you would need to do some validation on the server side, but you should be doing this anyways.

When asking for a US state, use the two character code

For the same reasons as above, it is much easier for me to type NY than it is to find NY towards the bottom of the list, after several other states that begin with N.

This leads me to my first generalization, which I am hesitant to call a rule or best practice, because there are always exceptions:

Don't use a select list when the user can more easily type in what they want.

You can even use some AJAX to display the country or state next to the code once they type it in.

ajax example

Keep in mind that people don't like to read

If your form is so complicated that users have to read descriptions to figure out how to use it, it may be a good idea to go back to the drawing board.

I wrote a blog entry a while back about a form on T-Mobile that asked for the last four digits of your SSN, or your birthday. The form would throw an error if you entered both. It took me a few tries before I noticed the OR in the instructions.

Use the label tag

I love the label, and I'm not sure why more people don't use it. Not only does it improve accessibility, in most browsers when you click on the text it gives the focus to its associated form element. This is really makes checkboxes and radio options more user friendly because you can just click on the text to select the option.

They also make it really easy to style your forms with CSS.

Here's an example:

<input type="checkbox" name="remember" id="remember" />
<label for="remember">Remember me on this computer</label>


Related Entries

22 people found this page useful, what do you think?

Comments

I totally agree with your thoughts here. I can't stand select boxes for state and country. Further using label in conjunction with fieldset and legend make for a much more accessible form and really cleans up code. Plus in the process you get away from using table based layouts and move to css which while not perfect certainly leaves more readable code. I recently began a project to handle form creation with this in mind using XML for configuration and CSS for all the display. I know XForms and XSL exists for a reason but it doesnt really meet my needs in a lot of instances. So far its working pretty well but the list of features I want just keeps growing. An interesting possibility is automated form handling based on that same xml configuration used to build the form.
there are many users who would have no idea what their country's code is. if you really want to chop this up, break the countries up into regions or use a map. also in i18n apps, it's best to provide country names in the language of the user (again not the code).
Pete, Thanks for spotlighting the label tag! It drives me *bonkers* that a good 90% of Web forms don't use it, especially on radios and checkboxes.
Paul - thanks for your i18n comments. I like the map idea. To take it one step further you could click on a region of the map, and then display flags in that region, sorted by the population of the country. I didn't realize that some people wouldn't know their country code - you could perhaps provide a link "What's My Country Code" that would let them look it up. This would make the form easier for the majority, while still servicing the minority.
I'm intrigued by your suggestion to use two letter codes instead of drop down boxes. It seems like it might be a good idea, but like PaulH, I wonder how many people might not know their codes. Has anyone actually seen this practice in use currently? I know I haven't and there might be a good reason why. I'd want to see the results of some user testing before trying this.
I have used two letter codes on an ecommerce site without any reported problems. Though most orders were from the US, or other big countries. I too would be interested in any studies relating to this. My thought however is that if the use of the two letter codes became more common people who didn't know them, would learn them. It's only two letters - we expect people to memorize email addresses, and domain names. As I said in my last comment it is probably still a good idea to provide a link to help people who don't know.
Pete, regarding stylizing your labels... Are you just saying that you could apply a label{} class in the CSS rather than having to span the label text and explicitly define some subclass of span for example?
Yes Dave that's what I'm saying I'll post an example in another blog entry.
I have posted an article on styling forms with CSS using labels here: http://www.petefreitag.com/item/527.cfm
uh, flags? no, no flags. flags are often used to represent languages & are a big no-no. you put up the UK flag, americans & ozzies get mad. so there is kind of a "stink" around using flags (even if it really is to represent a country). if you wanted to get fancy, you could pick up their current country from their IP (really more of a guess though w/the right tools you guess right 90%++ of the time) & push that to the top of the selection list.
I thought I would try out the two character country codes with some client side validation. http://tinyurl.com/7qmj9 Ideally the select would be hidden until requested by the user, but both IE and Firefox have annyoying quirks with hidden selects, so I've made it visible for now. (I haven't looked for workarounds yet) Although you can start typing the name of your country in the select, the two letter codes are language independent, so better for non-English users. The select is good for those that don't know their country code, but can be done away with if need be. And of course it could be reduced to a drop down instead of list. What do you guys think? Jason
jason, those language codes aren't language independent, their based on english. if you really want this to be i18n, you're supposed to provide the countries in that user's language.
PaulH, the codes are language independent. However, they are not alphabet independent. They are all based on the Latin alphabet, but generally represent the local name of the country. If I were a German using the field on a German, English, French, Portuguese and Polish website the language code would be DE for all of them, however traditionally I would have to know to look for Deutschland, Germany, Allemagne, Alemanha and Niemcy. The strings in the select should be localised, but you can only do that if you know the language of the user. By using the country codes you don't need to know their language.
jason, sorry but those codes don't represent anything but english names. they are not localized in anyway. you're misunderstanding my other point, the names of the countries should be localized in the language/locale of the user (who if were german speaking wouldn't be looking at a polish language site). as far as knowing what language they use you can simply ask them or use something like: http://www.sustainablegis.com/projects/geoLocator/ which combines ip/country database & http_accept_language. btw this is what i mainly do for a living.
PaulH, I may be wrong about them not being English, but the following lead me to believe otherwise. CH Confoederatio Helvetica (Switzerland) DE Deutschland (Germany) ES EspaƱa (SPAIN) HR Hrvatska (Croatia) And, from what I've seen, it seems that the local names of most other countries are similar enough to English to use overlapping characters. I understand your point about having the names of the country in the language that the user reads. I noted in my previous comment that the select box should be translated. However, it is not feasible for a site to have translations for all the languages represented in the 240 countries. By using these standard codes you alleviate part of that. In addition there are plenty of people that will use websites outside of their TLD and language. Multilingual people might not be common in some parts of the world, but it's rampant in others. And if we're talking about saving time by not having to search through a list, then it's quite reasonable to save time by not having to consciously remember what the translation is in the language you are currently reading. Also, asking a user their language is only useful if you have translations for them. If I'm forced to read Polish because I need something only that site has then I'll be grateful that at least that one step is easier. I can also assure you that an American tourist in Japan would be quite annoyed at having to read Japanese while using their webmail because that's what their IP and web browser claimed they could read. All of this is supplementary to the fact that typing in 2 characters is easier than searching a list, or typing in the name of the country until it's narrowed down in a list. (especially if it's not your native language)
like many i18n data, happy coincidence. thailand? egypt? UAE? those local names aren't even in a western european alphabet. there's a lot of "strange" stuff in the i18n world (why does core java have a buddhist calendar & why does it automatically use it thai locales, even when you don't ask for it). having 2-letter country codes is no substitute for translations, never will be. what languages/locales a site serves is based on a number of factors but the majority default to en_US when they can't. when you ask a user what language they'd use, it's beggars belief that you suggest languages that you don't have translations for. i really can't follow your logic on this point or your assumptions how language negotiation works (its good & common practice that you *always* have a manual way for users to swap languages). i simply don't agree that two letter country codes is going to work well across the world.
PaulH, Happy coincidence? I would like to challenge you to find a single code that is blatantly English. Here's a couple things to keep in mind while you search, the characters ABC... are not "English," they are the Latin alphabet which is the most widely used alphabet in the world. (English and otherwise) Also bare in mind that there are exceptions to the "native name" rule, however the codes for these are not based on English either. An example is JP Nippon (Japan). Yes, JP does not represent "Nippon" in any way. However, NI NP and NO are in use by other countries. So they could have used NN, but instead they chose to use characters that represented Japan better for the entire world. Remember, I'm not talking English here. These are some of the other names Japan goes by around the world: Japan, Jit-pun, Japon, Japonsko, Jaapan, Japanio, Japania, Japanio, Japanyo, Japonya, Japana, Jepang, Japonija, Japonska, etc. While there are languages that use the Latin alphabet that do not have J and P in the name, the majority do. >having 2-letter country codes is no substitute for translations, never will be. I think there are a few people who disagree with you. Never mind that your bank runs on these codes, lets look at the web. Say I love electronics and I want to see what's new in Japan, since they get a lot of the good stuff first. I want to go to Sony's website and since (you say) translations are better than codes I go to http://www.sony.co.Japan. My French speaking buddy wants to see something, so he goes to http://www.sony.co.Japon. Both addresses take you to the exact same web page which happens to be in Japanese. Wouldn't you want to find the country that had the shortest name for Japan and use that instead and save yourself some time? You even used "en_US" to represent a language and location. Even if I only visit English web sites, I still want to use the code for country input, since it's quicker. Despite what you say, these codes are language independent and increase usability. If anyone else has some input I'll be happy to discuss, otherwise good luck to you PaulH.
Pete - Love it! Good stuff. I did not know about "label" :)
Put a map with countries clickable... simple and works for all.
Hey Stefan, The problem with maps is that you need something like http://upload.wikimedia.org/wikipedia/en/4/4b/World-map-2004-cia-factbook-large-2m.jpg before most countries are large enough to be clicked. That map is 2MB and 4000x2949 pixels. That's a lot of space to take up in a web form. And even then not all countries are large enough to be clicked by skilled clickers. It's made even worse when you consider people with poor/no vision, poor motor skills, slow Internet connection or poor geographical knowledge. In most cases you'd still need to have labels on the countries which would then need to be translated into the local language. Now it would be possible to have a drill down, so that you click on a small map, which zooms in, repeat until you're at you're at a scale that's good for clicking your country. But then you'd need to sort out if someone wants to zoom or select the country under the cursor. If the goal is ease of use and speed then I don't think that maps fit the bill. ymmv Jason
i have hidden folder it showing because in folder option (Do not show hidden file and folder)is selected but stile it showing i try all option in folder option so please tell me what to do

Post a Comment




  



Spell Checker by Foundeo

Recent Entries



foundeo


did you hack my cf?