Thanks for the blog Jeff, and I found the 2-3 year discussion interesting. A lot of talk about needing to know the separate fields and therefore parsing/validation but I think many people missed your point that if the purpose is solely mailing then you are just replicating what is entered - if it doesn’t get to the destination then it is almost certainly because the user entered their address wrong - isn’t that better than the mailing program creating the wrong address format from what the user entered and therefore it being your fault?. A multi field form can still have users enter the wrong address also. Formatting an international address for mailing can be just as time consuming development wise as free text field parsing.
If you need something far more complex from the address database then separating it out is probably a better option (although I think too often developers assume the data is going to be used for more than it ever is). If you want simple demographics like knowing how many people in a database are from Sweden then you can still do this easily with a single text address field using SQL like “SELECT count(*) FROM customer WHERE address LIKE ‘%Sweden%’” - it should be accurate enough (using common sense of course and multiple conditions when looking at things like postcodes across multiple countries - ie "address LIKE ‘%Australia%’ AND address LIKE ‘%6148%’) - sure you might get a few outliers but is it really going to impact the demographic analysis (assuming you would only be analysing a db with a satisfactory sample size to cater for a margin of error in the first place)?
I have used both address input methods in a number of systems and there are pros and cons to each. Mind you, I have worked more on international intranet-based systems where user training is a luxury that you don’t enjoy with public websites. My personal peference is probably to split out the field entry but with text entry as opposed to long drop-down lists and using Ajax validation to assist correct entry and spelling but with overrides (ie allow user to enter something not on the list as a last resort). Guided flexibility is the often the key to any good input form. Too often we force strict controls rather than guiding the user to input what is needed correctly, and like many have said, lose international (ie non-US) customers because they can’t enter what is neeed.
I like the heart behind the idea, but not the idea.
Usability - Web forms have become a convention, and users have been trained for 10 years on how to fill out forms. Users would get confused, and some would bail out (abandon carts, etc.). Web forms work, and we know how to use them. Your form example violates the “Don’t Make Me Think” principle on many levels. What’s this? Should I fill in my apartment number? Can I hit “Enter”, or will that submit the form? Do I put in my country? Will they tell me if I’ve filled this out wrong, or will my order just be shipped to the wrong address? This is something I’ve never seen on the web before, so I’m not sure.
Economics - This is a lot more work for developers. Saying “who cares, this is the way it should be” only works in blog posts. I real life, someone pays for the developement. Does that mean the product costs more? The company pays the employees less? Or, more realistically, we skimp on other features or testing? Validating free text areas for addresses has an economic benefit for Google - they can route you over to local results, and give you targeted advertising for that area. There’s no real economic benefit to free text addresses in shopping carts or registration.
Leveraging Browser Features - As previously mentioned, browsers support autocomplete. I type in the first few characters of my street address and hit tab. With this, I’d have to type in my full address every time. Argh!
Ignoring the real problem - There’s no reason I should have to enter my address anywhere. Ever. It hasn’t changed in 3 computer lifetimes. We, the computer users, need to get over our childish opposition to digital identity and reap the benefits of allowing our computers to store our address - encrypted if need be, but store the dang thing in a standard format that websites can accept. Infocard…?
The enter button thing is tricky. Some users expect forms to submit when you hit the enter key. We just had to fix a bug on a site we’re working, requiring us to ensure that all forms in the site to submit when enter is pressed. That’s part of why I’m saying that multi-line textboxes aren’t necessarily as intuitive, since we’re not sure (as a user) how the form will behave.
Replacing address fields with freeform text areas is a bad idea because it
prevents autocomplete functions from working.
Does it? MS Office and OpenOffice both do autocomplete on freeform text within a document. Why can’t we do that in a data entry form. I realize it’s different for a web interface and a fat client, but it could still be done on the web, in theory.
As has been pointed out, I’m sure, is that you are correct that everyone has filled out a number of labels, but that conventions vary to a rather large degree. Case in point would be my (anonymised) address in Danish standard form:
Sune Mølgaard
Somestreet 1, 2. -3
8000 Århus C
Denmark
Good luck, even with your RegEx-fu, to get anything meaningful out of addresses entered verbatim in the convention of the native country of the user and, mind you, your example holds so very poorly, if some American relative was to be so helpful as to write my address in the Danish standard form to help the Danish postal services - renowned for their bad service - since the U.S. one would only have to look at the “Denmark” part to ship it most of the way.
As, I’m sure, has been pointed out, the only situations where you can get away with geocentrism are the ones where your service is indeed, and solely, centered around a specific geographical location. Can you come up with an example?