If this comments window wasn’t fixed width
It isn’t fixed width as of a month ago. Try it.
didn’t give an error when I click preview and then click on my name
Bug in Movable Type’s code, though not a very meaningful one. They shouldn’t make that clickable in the preview.
n fact its almost fun to see a form covered with tiny, text boxes because I know I can fill them in with one click.
Which works most of the time. But it’s an additional click from a third-party tool I have to install and configure manually. And I’ve had forms submit with bad data because the developers decided to name their fields in an inconsistent way. For example, one time, on the Sennheiser web site, it actually screwed up my order because the form didn’t do a server-side check on one of the fields! I know, crappy programming, but this is a kludge.
As previously mentioned, browsers support autocomplete. I type in the first few characters of my street address and hit tab.
Again, assuming the field has the right magic “name”. I’ve had autocomplete kick in that was totally inappropriate, or for completely unrelated things.
Does that mean the product costs more? The company pays the employees less? Or, more realistically, we skimp on other features or testing?
You could make this same zero-sum argument about a zillion other UI improvements. How much does it cost when a user has to tab through three annoying textboxes to enter a telephone number instead of just typing the darn thing in? Well, we don’t know, but we have to pay Joe Programmer $65k per year, so let’s just go with that.
Reducing friction is important, because the cost of switching to a competitor’s product is nothing.
http://www.alistapart.com/articles/flywheelsandfriction
Ignoring the real problem - There’s no reason I should have to enter my address anywhere. Ever.
Isn’t this why God invented Passport™?
But in all seriousness, I agree, persistent identity is the root problem. The browser should have some way of delevering this to websites with your permission. Something better than crappy, kludgey AutoFill and AutoComplete features.
Rick,
Your code doesn’t allow for a country code.
It also doesn’t allow for (nnn)nnn-nnnn. or nnn nnnnnnn, or nnn-nnn-nnnn.
See, it’s always “easy” right up until it isn’t.
Rick,
ok, so it does allow for the examples I showed above. But it stil doesn’t handle a country code. 
ok, so it does allow for the examples I showed above. But it stil doesn’t handle a country code.
You can make the phone validation a regular expression, which can account for any possible scenario. If you miss one, just edit the regex and add it. No need to recompile your code.
Completely agree - I was registering a domain name the other day, and had to fill in a contact details form designed by a US programmer. That would have been fine except for the fact that I live in Denmark where we often only have 2 line addresses and place some of the info in a different order. A multi-line text field would have been far better…
My mistake, the window is indeed now non-fixed width!
Peter-- see, I do listen! 
Jeff - I did answer the question. Users are idiots and provide unparsable, often irrelevant and useless data unless we painstakingly walk them through the process.
Since we often have to hand data off to secondary systems, it must be parsable.
Worse that being idiots are those who play the system. Credit card fraud is often perpetrated through unparseable or incorrectly parsed data when compared against a credit card holder’s true information.
Data is gathered the way it is for a damn good reason. Natural language processing is beyond the reach of software, as such we bridge the gap by regimenting how the data is provided. It makes the data parsable, reduces the possibility of fraud, and leads otherwise clueless users through the process as they continue to hunt for the “any” key on their keyboard.
From my personal perspective, what is important in online forms is achieving a balance between the three elements of:
On paper forms (which have been widely used for a /lot/ longer than a decade), having individual boxes for characters (eg multiple character-sized boxes joined together for a telephone number) is economical (doesn’t cost much more than having one box), reduces error (as the boxes restrict what sort of answers can be provided) and is user friendly (because the boxes provide a visual cue to the user about what sort of information they should enter). In online forms, this approach continues to be economical but can be less effective at reducing error (depending on tabbing rules) and, I believe, less user friendly (eg more clicks, more for a screen reader to churn through etc).
I think situations such as these have come about from a nave belief that paper forms can be directly translated into an online environment, when research actually shows that the two mediums are significantly different and so require tailored approaches. We need to think critically about how every question is best asked in the given medium.
Given the three-way tradeoff, for an online form I personally would choose a single box for telephone numbers which is parsed. This approach has greatest usability and is moderately economical and except when a form that has to work in more than a handful of countries, parsing a telephone number should be quite achievable. Conversely, having separate boxes is likely to reduce usability without a major reduction in economy (as the number still has to be parsed to some extent to ensure data quality).
When it comes to addresses, the situation is a little more complex. It is true that people write addresses correctly on mail every day. However, I believe the context cues here are very strong: envelopes are for addresses (and stamps) only; if you are sending something in the mail it has to be addressed a certain way so that it gets there etc. The context is very different on an online form: online forms are used to collect lots of different types of information; there are lots of different reasons an address is needed (ie not just shipping) etc. This loss of context could lead to reduced data quality, and of course many people don’t even address physical envelopes correctly. In my experience in Australia, postcode is forgotten regularly and this may even be why Australia Post introduced postcode squares pre printed on envelopes: as a kind of visual cue.
As anyone checking out Frank’s Compulsive Guide to Postal Addresses (http://www.columbia.edu/kermit/postal.html) would appreciate, writing code to accurately parse an international address is very complicated. Given that no matter how the data is entered, we should be confirming it with users before processing, I worry that the user might have to go through the confirm-fix-confirm-fix cycle multiple times, while the parser tries to get it right, which would definitely reduce usability. Conversely, if additional cues mean everything is entered right the first time, there is less work/frustration for the user, so a little more upfront work for the user doesn’t necessarily equate to worse user experience.
For these reasons I would personally have a single box for each of the following items: street address; suburb/town; state/province; postcode and country, with maximum widths set for each and adjustments made if that form is only used by a subset of the global population.
End my two cents.
I recently used a site that the input for address consisted of a text box and then postcode. I was admittadly unsure of what information they actualy wanted.
As somebody who lives in a country a long way off the normal beaten track (Thailand) of mainstream web development I find the whole validation thing that occurs on phone and address input a complete nightmare.
Some examples include the inability of many telephone number inputs to handle numbers like +66 (0)6 123 4567. Instead I have to fit it into an American scheme. Well great, but how are you going to use the phone number that was so carefully collected and error checked?
My address here starts 34/40 Pracha Utid Rd. Yes, that’s right, there’s a slash there. There has to be a slash or everything will go to the wrong place. More than one on-line sale has been lost because address validators won’t allow the character in the address. I’m not going to have something shipped to 34-40 because that’s half way across town. And Bangkok is a city. It doesn’t have a state or province or county. Bangkok, Bangkok makes no sense in the address and is only going to confuse the postman who’s having enough trouble trying to read western letters to start with.
Postal addresses in this country are highly structured with each conforming to exactly the same set of fields. When the shipping label doesn’t allow that structure to be followed then post doesn’t get through. I’ve never come accross an address input box which lets me fill it in with Thai.
Even that guru of usability, Jacob Nielson, won’t let you sign up to his mailing list with an address of the form l@domain.com because he assumes that you cannot have a single letter as your email address.
I think as programmers we have to hold the users’s hand to try to get the right structure in there, but we have to allow the users to insist that they know better. By all means mark up city and state as required fields, but if the user insists that one of them is irrelevant then you should believe them rather than your own bias. If the user insists on a non-standard phone number entry then capture exactly what they type even if you don’t understand it.
Over validation is normally worse then lack of validation.
Has anyone seen data, formal or otherwise, about autofill use and adoption? I’ve never once seen a user in a testing situation reference that they used autofill…
Dare, dare, dare I ask if we need to have a drop-down box for the state or country? It doesn’t make selecting the state any easier, and it would be programatically pretty simple to check for a valid name. I absolutely loathe having to search for “Massachusetts” somewhere down on the bottom of a long list when just typing in MA would work just fine. If we trust people to type out their names and addresses correctly, I’m sure they can be trusted with their state. And let’s not get into the “you run an ecommerce site that deals primarily with English-speaking countries yet you bury UNITED STATES and UNITED KINGDOM down in the U section.”
I’d be happy if websites were a little less US-centric in their address parsing. Having lived in a few European countries (F, B, D, CH), there is some convention:
Street-name number+suffix
Postcode City-name
Country-name
Note: no state/province, which is often insisted on, and postcode before city-name, not after it. Often the postcode has a country code in front of it, e.g. CH-8057. Some parsers accept this, others don’t.
If parsers could just handle this generic address form, it would be a start.
As for drop-down lists, sometimes I have to hunt around to see which is possible out of United Kingdom, Great Britain or England, and often in multiple language variations.
Perhaps the best way to handle international addresses is to select country first, then adjust the rest of the input form accordingly.
While on the subject of internationalisation - why do many international websites force language selection based on country? Obviously a good default is to choose a national language, but if the text is available in multiple languages, why not make that selectable? The Apple web site (otherwise excellent) is guilty of this.
I don’t get it…
I live in Elbonia (let’s say so) and my address is
Grababru Daroomph
B654 Foobark 5365
Elbonia
How are you supposed to know which one is my zipcode and which one the street number ? What is “Grababru Daroomph” ? the street name ? the city ? An human couldn’t figure it out, so… a regex ?
If the information is needed for a database, and the database must be able to sort people by zip code, then I’d say it’s pretty safe to have separate and distinct inputs for each one.
Of course, you could implement an app looking up for valid cities and zipcodes all over the world, but it still wouldn’t be fail safe, and is quite overkill for a simple form
Looking at all the objections in the comments, I want to point out that it’s been done.
A decade ago, Lotus Organizer had the ability to grab a several-line address, parse it into fields thru its EasyClip applet, and account for different country formats, with only minimal rearrangement by the user.
For those unfamiliar with the program who are curious about the functionality, I posted a screenshot @ http://www.osmond-riba.org/lis/Graphics/EasyClip.png. EasyClip imports the highlighted text into the fields, and then lets the user edit and move things around in case anything is incorrect.
Just FYI…
And then there’s the other problem with drop-down country lists: am I looking for United Kingdom, Great Britain, Britain, or England anyway?
obviously the author of this article is not a developer.
Nice Blog! Thanks for the information
