March 7, 2006
Why do HTML forms have to be death by a thousand tiny textboxes?
The classic example of this is phone number, which typically forces you to tab through three annoying little textboxes to enter a single number:
Why can't we let the user enter the number however they like, and accept lots of formats?
Yes, it's a bit more work for the programmer. But who cares? The developers will only code and debug this once. Users, however, will be forced to enter thousands of telephone numbers in that tedious, time-consuming tiny textbox way. Forcing hundreds of users to do more work to make a single programmer's life slightly easier is a false economy.
I also wonder why we have to enter addresses in a bunch of textboxes.
Wouldn't it be easier if I just filled out a mailing label and typed my address exactly the same way I write it?
Everyone has filled out an address label before. It's completely and utterly intuitive, even if you live in another country.
I realize this doesn't work for the entire order form. We still need to collect email address, phone numbers, and so forth. But it sure would make the address entry a lot easier -- and more obvious -- for the users.
We have to stop optimizing for programmers and start optimizing for users.
Posted by Jeff Atwood
They want to collect metrics based on the address information for the separate fields. Although it's possible to parse the values programatically, it is never going to be consistant 100% of the time with a free form text field.
is never going to be consistant 100% of the time with a free form text field.
It's never going to be consistent 100% of the time with human beings entering data, period.
And Google is clearly able to parse an address entered in a single line. G'wan. Type an address in the Google search box like you would on a mailing label. This is even HARDER to parse because it lacks carriage returns!
"Everyone has filled out an address label before. It's completely and utterly intuitive, even if you live in another country."
Hmm, not really. At least in Czech Republic (and I'm quite sure that German address conventions are similar) the address is entered slightly different:
Peach Pit Lane 431
I strongly support optimizing for users, but it could be quite difficult when your audience is global or when you don't know who will use the app.
What about classical example with date formats? Consider entering date - is it DD/MM/YYYY or MM/DD/YYYY? 23/2/2006 is easy. But what about 2/3/2006?
I've saw quite a lot wanna-be-smart datetime controls trying to guess ... and fail... :-/
Hear hear! I hate all the fields, particularly address fields. Devs need to try harder to let people enter data in a way they find natural. Maybe I have the address on my clipboard for some reason. Please please please let me use my clipboard!
It was one of the things that drove me bonkers about Mapquest, I'd find an address listing online and copy it to the clipboard, but Mapquest wouldn't have it. I'd have to type or paste each individual address component in its own field. Uggghhh, at least try Mapquest!
Martin and Space, you are both guilty of making you're own lives easier at the expense of the user. You say, we can't parse it 100% of the time, so just give up.
There are ways around this, for one you can give them a big old text area, and then parse it out and show the user how you interpreted it, with all the parts(street, zip, etc) dropped into fields and labeled. Then, if you completely screwed the pooch parsing it, the user can still enter it in manually the slower, multiple field way.
I think it depends on how the address is going to be used. If it's mainly as a shipping address, how it is entered, stored, and retrieved doesn't matter a whole lot. If it's used as a data source (e.g. showing sales data in a given region, or possible study participants in a given state/city). Then you need to take a little more care in how the data is entered and especially stored.
I used to live and work in Albuquerque, NM. We had to enter a lot of address data for people. Guess how many different spellings of Albuquerque we had? Our solution? tah-dah. Autocomplete text boxes. Creating an autocomplete text area is a little more difficult. But if you're running a query that says "select * from People where city = 'Albuquerque'" it sure helps everyone if you help the user enter as much as you can.
Well if the address is a real address, it is possible to parse with as pretty much the same accuracy as separate text fields, but it requires getting postal data from the USPS.
I once worked on code that parsed free-form address fields and it relied on USPS data.
For addresses alot of the time you only need housenumber and postcode. That's all you strictly need if your mailing something localy. However, this isn't really practicle for global shipping etc.
Another problem that my girlfriend was telling me about. One of her friends has legally changed their name so that it is now just one name. No forename or surname, just the one. How are they meant to fill out the "Firstname Lastname" forms? Though that problem extends further to the fact they can't get stuff like insurance, because they simple won't accept that they don't have at least two names.
it could be quite difficult when your audience is global or when you don't know who will use the app
How so? You're filling out a shipping label. We'll print it out EXACTLY as you fill it out, and that's where we ship what you ordered. What do we *really* need to parse?
Probably just enough to calculate shipping costs.
That said, parsing all the world's shipping formats is definitely more daunting than just the US.
Maybe I have the address on my clipboard for some reason
Oh man, I mean to keep blogging about this, but forgetting. Beyond Compare checks the clipboard for your registration info and AUTOMATICALLY ENTERS IT FOR YOU when you enter the dialog.
Swoon. I'm in love all over again.
For the record, clipboard integration and the web browser is a different story. IE has some basic clipboard support, but I don't think Firefox/Mozilla allows any access whatsoever.
while I agree on the phone edit box, I don't know about the contact information, I work on a field where I see a lot of user entered contact information and I can tell you that
- users will come up with the most amazing ways of entering data
- address recognition software is very expensive or time consuming to create
of course in the specific case of the USPS, they have all the data they need to recognize any US address, even tell you if such address exists
Replacing address fields with freeform text areas is a bad idea because it prevents autocomplete functions from working.
What you should do is use single-line input boxes with sensible name attributes (like "name", "email", "street", "city" etc.). If a form is properly designed this way, the client's browser ought to be able to help filling it in.
If the user enters a zip code, then the state and city are already known. All that is left is the actual street address.
There are very few sites that use this method. Why?
I beg to differ Jeff, data normalization and data cleaning are very important processes of any Marketing, Analisys or classification of a database.
If you give a "textbox" only, your're opening your database too much and the users can (and will) enter inconsistent data.
The more, the merrier. There are webtechnologies that can help a user complete a form without much hassle. I agree that the phone should be a string and period, but the address?
Try to later perform a data segmentation, mining and classification on a huge filled with crap textbox.
Nonsense. I worked with very large databases (companies like Kellogs for example) that pay zzziilllions of dollars to clean their db. It's a hard job. Believe me.
My two cents.
John: even "zip codes" are more complicated than you think. So your software can handle "90210"; that's lovely. What about SL6 7AA, 2042 or K1A0B1? And even if you decide to limit yourself to the former British colonies that have lately begun styling themselves "the United States", there will still be problems. I know, for example, that there's not a strict 1:1 mapping of postcode to state in Australia; there are about a dozen postcodes that straddle state lines, usually on some of the smaller sheep stations that are about three times the size of your average US state. There's likely a similar problem around the edge cases and extremes in the US zip code system.
Edge cases make programming hard.
Edge cases make programming hard.
No, programmers make edge cases hard by focusing on them instead of the other 99%.
FWIW, Google maps does a good job in parsing a one-line textbox and extracting enough information from it to be able to find you on a map. (Although sometimes it has to ask you to disambiguate.)
Jeff, I think you might be overstating the case for how inconvenienced users are by separate boxes for discrete info. Is it REALLY so horrible to have to enter a separate first name and last name? I can assure you that I can throw a volume of Knuth down the hall here and hit someone whose name is exotic enough that I don't know whether they're giving me the family name or given name first. So why don't I let them tell me instead of me having to guess?
Besides, we've already raised a generation or three of people who know the drill, heh. We're just following the lead of those trendsetters, namely government bureaucrats.
I'm with you on phone numbers and postal codes, maybe even city/state/zip (maybe), because if those need to be parsed, the variants are reasonably finite. But street info ... man. I deal with lists of only a few hundred names, and even then it's unbelievable how many ways users can come up with to enter information wrong. ;-)
John: zipcodes can span more than one city, mine for instance. Occasionally I get mail addressed to the adjacent town. My SO likes it, since the other town is much nicer than ours :)
I've almost forgotten about this problem. The Auto-Fill feature on my Google toolbar makes quick work of the very forms you are talking about. In fact its almost fun to see a form covered with tiny, text boxes because I know I can fill them in with one click.
Users are idiots. If we don't hold their hands, the second they get in front of a computer they forget how to do the most basic of tasks they normally take for granted.
Frankly, I am surprised that choking on your own tounge isn't lead cause of death amoung computer users.
Give them a box maked phone number and you can EASILY expect to get a poem instead. Not expecting extension numbers? Why give them the change to enter it.
Need a address? Gotta use it for 2 different forms such as shipping label and a commercial invoice? Forget free form entry. Again, the data will be hopelessly and endlessly manged beyond all hope of being useful.
We ask for data in an organized fashion because it narrows a user's expectations of what to provide, giving US a better change of not only getting the right information but also being able to use it too.
Take, for example, you idea of a postal code, or state/province. How do you know where one ends and the next begins for say, croatia, jamaica, norway, france, fiji?? You don't.
You think that just because most americans fill out an address a certain way that the whole world does it? Forget it.
Your way doesn't allow for ANY type of data validation whatsoever and easily promotes the exact type of data manipulation that fraud artists THRIVE on.
Worse, users would generically have no clue what to do. The fact that it is a 100% parallel to something do without the computer not withstanding.
Jeff - surely you aren't suggesting that we should all develop something as complex as google and its constatntly maintained database just to parse addresses?
Oh, and google FREQUENTLY misparses addresses and gives me totally wrong information. It works much better if you start layering in information like city first so it can interpret on context.
To give you an idea of how complex the problem is, calgary,ab breaks its city into 4 quadrants. NW,NE,SE,SW. Edmonton, Ab a mere 300 km away uses straight N,W,S,E. Google works because it has HUGE databases of street addresses that it can use its standard search engine against. The database is constantly maintained and the code is continually tweaked.
Totally appropriate for a search engine, but way more effort than a simple address box can justify.
All valid points. If you did attempt the single text box approach you should provide feedback to the user as to how you are interpretting the data behind the scenes - you could do this on page refresh or asynchronously. If it has made any incorrect assumptions the user can then make the adjustment and move on...
Not ideal for many users who will be forced to do this because of the dozens of inconsistencies across the globe... but a fun little project for someone.
Xepol, you're focusing on the wrong things (user "stupidity", parsing complexity, the requirement to parse at all). Go to the root causes that Jon Galloway outlined.
This is a thought question. We should be asking why we have this problem!
I have dedicated a good deal of time to parsing and converting address data, and as has been said before, if it isn't only to be used verbatim, it is a bitch.
By far the hardest of the lot was parsing. People are very imaginative and diverse in how they use address fields, and even when consistent there is ambiguity. In my fields (property related) especially it is important to try to squeeze what people think their address is into a template.
We've recently had to face this problem and we had to split our address fields.
The biggest prolem is that when people have the choice, the leave important data out. Like postal coses or provinces, etc. This can cause a whole lot of headaches later.
Also you can't compare google search addresses to filling in addresses on forms. Google will parse what it can and give you back the image. If it's not right, the user can then change the search criteria. But you can't do that with stored data when sending parcels for example.
As a Dutch user, I absolutely detest mutiple-editbox address forms. They get it wrong -- always -- unless I deal with a Dutch or Belgian web site. One big edit box is just more user friendly, because as this page shows, addresses are essentially unparsable.
However, as noted, companies need more detailed information in their database, so (just a quick idea) why not let the user fill it in free-form, then let them use the mouse to click on their town name, own name, etc., as the application requires?
I also like the free-form - parse it - multiple editbox idea.
Maybe a seperate Passport(tm)-like Address Markup Language(tm) is required, but before that has any decent browser support, we're one and a half decade further.
"If it's not right, the user can then change the search criteria. But you can't do that with stored data when sending parcels for example."
Why not? Every company I know that uses only house number and postal code ask you to confirm that the details they interpreted are correct. You can check with the user that the data is correct.
Edge cases make programming hard.
No, programmers make edge cases hard by focusing on them instead of the other 99%.
At my point of view, software has to work in 100% situations and edge cases are just cases that has to work as 'normal' cases. So that split between normal and edge doesn't exists in reallity. It's just that you simplify the situation in what you say 'the normal' cases and get all the hard stuff in 'the edge cases'.
I use to aproach the problem without doing differences. The algorithm has to work with all the data that can come.
On the other side, let's talk about money. What about if you tell to your customer: I will do a single textbox that can read all the data entered by the user. It's just 1500$ (probably more).
As far as the user's work doesn't make my customer loose his customers I'm pretty sure that he will say: 'forget it'.
Or what about if you say to the end user: you will be able to put all the data on a single text box but all you buy here will be 1% more expensive. What would like the end user?
I see people talking here as if coding was free ...
What do you think?
I had a bad experience over the weekend. I was filling in a web form, and it had boxes for first name, surname, and then a big one for address as in your address label example.
So I filled it all in, with my full address in the (huge, multiline) address box, and then noticed the next three boxes - Town/City, State/County, Postcode... To say that this annoys me is an understatement.... Granted, I should probably do a bit of read-ahead, but all I was doing was filling in an address...
legally changed their name so that it is now just one name.
So "firstname"=name, "lastname"=name. I get that a lot, there are a heap of places that send stuff to Ms Moz Moz for no readily apparent reason.
Having normalised one database, I can say users are quite imaginative. We got more than 20 spellingings of Adelaide, for instance (it's not easy - try it). But really, we don't care. Print it, post it, next question.
If you want demographic data about your users, ask for it.
Did you know that there are PROFESSIONAL FORMS DESIGNERS and FORMS ANALYSTS who actually earn their livings keeping amateur crap like this from happening??
Hire a pro and this wouldn't happen.
A (US) phone number is generally parsable without a lot of effort. As the original post suggests - just once for the developer vs 10000 times for users.
On the other hand, a (US) address parser is WAY more complex, requiring purchased (is monthly good enough?) data. A big expense. And why parse rather than just leaving a lump? Apart from the aforementioned sales analysis, the USPS will give you discounts for sorting your bulk mailings to those sales analyzed ZIP codes.
Did you know that in the US you can send a letter to:
(123 is the house or apartment number)
So you can really save yourself some database space but good luck explaining that to your end user! :)
MoZ: That's a good idea. Doesn't help with things like insurance where legality is involved. But that's a different kettle of fish.
If this comments window wasn't fixed width and didn't give an error when I click preview and then click on my name, I would be easier to take your comments on board Jeff.
You like to play ping pong with other peoples comments, yet here are two problems which have been here as long as I can remember.
I know you'll say it's because of the software you use.
But I don't care about that, I'm just a user being annoyed by a problem.
All you folks talking about autofill (not autocomplete, but the web browser autofill) are missing one factor.
The Autofill functionality was added because it is a pain to enter that data all the time. In all those boxes, in whatever format the developer decides on.
So the autofill functions were added to make life easier. And you still have to go through the hassle of getting autofill setup correctly (after a couple of submissions, it starts to remember).
I don't have too much of a problem with the '1 textbox for the address' idea (except as a developer I'd be glad for someone else to do the code for it!) but the single text box phone number entry? I beg to differ. To me, it's far easier to type in COUNTRYCODE (TAB) AREACODE (TAB) NUMBER than it is for me to type in the number "(BRACKET)555(BRACKET)555(HYPHEN)5555". Even allowing all formats ("5555555555") can cause problems for me because as humans we remember phone numbers exactly like "COUNTRYCODE AREACODE NUMBER" - not as one long string of numbers.
First Post - EXCELLENT blog, by the way...
If only there was some way to store information, like security information, on the computer in a secure manner. One that the user had to initiate. Some kind of information store that would allow any application to set up a little footlocker inside the store. What would we call such a thing? A Keychain maybe? ;)
Yes it's a big step to impliment the parser the first few times. But it would eventualy become a common implimentation.
Allowing free-form phone/fax entry and full zip-code entry (with optional zip extension) is very easy. Here is some basic C# code to extract exactly this with very little error:
string FullPhone = Request["PhoneTextBox"];
string PhoneDigits = new string();
foreach(char c in FullPhone)
// Remove optional "1" at the start
if(PhoneDigits == '1')
PhoneDigits = PhoneDigits.SubString(1);
string AreaCode = PhoneDigits.SubString(0,3);
string Phone = PhoneDigits.SubString(3,7);
Extension = PhoneDigits.SubString(7);
See how simple that was? Remove everything that isn't a digit and an optional one and you have pretty good data. I've been using this method for years and its worked perfectly. Of course, this is just my memory of how the code works, not a copy/paste so sorry if there's a HDD-Formatting bug in there somewhere.
This method allows users to input their phone number in any crazy format they like (wtf is with people that like to do "1.234.567.8910" or "234/567+4559 x998!" ?).
The same method can be used to parse US zip codes...the first 5 digits are the zip, the next 4 are the zip ext if they are there. If the length of the "digits-only" string isn't 5 or 9, that's an error.
Of course, our website is only for our customers, and we only contract inside the US, so this may not be that great for other countries. For all I know, there are random ASCII glyphs of musical notes and fractions in foreign zip codes ;)
Address parsing is...uh...left as an exercise to the reader.
This same method works for
This has long been a pet peeve of mine too. I implemented a product last year that does data validation for ASP.NET web apps, and I made sure it didn't propagate this broken pattern. The pre-fab validators for phone numbers, credit card numbers and the like will accept a variety of different formats from the user. The programmer gets a nice property that they can pull JUST the digits from without worrying about how the user typed it.
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.
Ignoring the real problem - There's no reason I should have to enter my address anywhere. Ever.
Isn't this why God invented Passport(tm)?
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.
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.
ok, so it does allow for the examples I showed above. But it stil doesn't handle a country code. :P
ok, so it does allow for the examples I showed above. But it stil doesn't handle a country code. :P
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:
- usability (ease with which users can fill out the form),
- economy (cost of the form and data processing for the originator),
- error prevention/minimisation.
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 firstname.lastname@example.org 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:
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
B654 Foobark 5365
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.
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.
BTW: It's "ZIP" code, not "Zip" or "zip" - It stands for Zone Improvement Program.
Easy vacation times now
We Wish You A Merry Christmas
and A Happy New Year and A Seasons Greetings 2009!
With a special gift for your Vacation holidays
Delivered by postmail
Better than internet gifts
Easy vacation holidays
no more high expensive hotels or guest houses too worry about
Now vacation holidays in your personal tropical fully furnish house with no expensive of maintaining!
Valued your way access
Valued Special Moments
Valued test drive vacation
Send your email for reservation!
A life time vacation dream come true!
Welcome to all internet visitors especially ladies and you can reach me at the following e-mail enclose even have a chat on a msn window plus i offer a postmail gift to you and if anyone promotes my guest book here i also offer real nice genious prizes my street address: york house golf club road, christ church, Barbados, west indies.HAPPY HOLIDAYS!!! email@example.com
Nice Blog! Thanks for the information
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:
Somestreet 1, 2. -3
8000 Århus C
signifying Somestreet 1, 2nd level, room 3 in 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?