Howto build a form that isn't annoying (Part 1)
By Pete Freitag
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.
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>
Howto build a form that isn't annoying (Part 1) was first published on January 11, 2006.
If you like reading about forms, usability, form, or best practices then you might also like:
- Howto Build a Form That Isn't Annoying (Part 2)
- Accessibility and Usability in Forms Outline
- Let the computer do the formatting
- Keep in mind that users don't read
Discuss / Follow me on Twitter ↯
Tweet Follow @pfreitagComments
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.
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 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.
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.
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
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.
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.
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)
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.
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.
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
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
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.