programming and human factors
by Jeff Atwood
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.
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.
Space Goat on March 7, 2006 5:59 AMis 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!
Jeff Atwood on March 7, 2006 6:04 AM"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:
Alan Smithee
Peach Pit Lane 431
Hollywood
90210
USA
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... :-/
Martin Vobr on March 7, 2006 6:11 AMHear 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.
Damien Katz on March 7, 2006 6:24 AMI 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.
Scott on March 7, 2006 6:25 AMWell 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.
Haacked on March 7, 2006 6:29 AMFor 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.
Jeff Atwood on March 7, 2006 6:44 AMwhile 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
Eber Irigoyen on March 7, 2006 7:02 AMReplacing 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.
Phil on March 7, 2006 7:12 AMIf 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.
Eric TF Bat on March 7, 2006 8:51 AMEdge cases make programming hard.
No, programmers make edge cases hard by focusing on them instead of the other 99%.
Jeff Atwood on March 7, 2006 9:09 AMFWIW, 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 :)
Ricky Dhatt on March 7, 2006 9:30 AMI'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.
Jason on March 7, 2006 9:30 AMUsers 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.
Xepol on March 8, 2006 1:04 AMJeff - 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.
Xepol on March 8, 2006 1:13 AMAll 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.
wioota on March 8, 2006 2:18 AMXepol, 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!
Jeff Atwood on March 8, 2006 2:46 AMI 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.
Brady Kelly on March 8, 2006 3:45 AMWe'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.
Mladen Mihajlovic on March 8, 2006 3:56 AMAs 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[1] 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.
[1] http://www.bitboost.com/ref/international-address-formats.html#Formats
Joost on March 8, 2006 4:09 AM"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.
Two comments:
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?
SoMoS on March 8, 2006 4:31 AMI 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...
Carl
Carl Wright on March 8, 2006 4:37 AMlegally 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.
MoZ on March 8, 2006 4:49 AMDid 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 href="http://www.bfma.org"http://www.bfma.org/a
the old formsmaven on March 8, 2006 6:48 AMMoZ: That's a good idea. Doesn't help with things like insurance where legality is involved. But that's a different kettle of fish.
[ICR] on March 8, 2006 7:16 AMIf 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).
Eric D. Burdo on March 8, 2006 8:29 AMI 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...
Ryan Shripat on March 8, 2006 9:08 AMIf 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? ;)
a href="http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Security_Services/chapter_4_section_6.html"http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Security_Services/chapter_4_section_6.html/a
a href="http://developer.apple.com/documentation/Security/Conceptual/keychainServConcepts/index.html#//apple_ref/doc/uid/TP30000897"http://developer.apple.com/documentation/Security/Conceptual/keychainServConcepts/index.html#//apple_ref/doc/uid/TP30000897/a
Scott on March 8, 2006 10:13 AMYes it's a big step to impliment the parser the first few times. But it would eventualy become a common implimentation.
[ICR] on March 8, 2006 10:45 AMAllowing 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)
{
if(Char.IsDigit(c))
PhoneDigits.Append(c);
}
// Remove optional "1" at the start
if(PhoneDigits[0] == '1')
PhoneDigits = PhoneDigits.SubString(1);
string AreaCode = PhoneDigits.SubString(0,3);
string Phone = PhoneDigits.SubString(3,7);
string Extension;
if(PhoneDigits.Length 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
Rick Scott on March 8, 2006 11:15 AMThis 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.
Tim Farley on March 8, 2006 11:31 AMIf 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.
Jeff Atwood on March 8, 2006 12:16 PMn 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(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.
Jeff Atwood on March 8, 2006 12:18 PMRick,
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.
Scott on March 8, 2006 12:19 PMRick,
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...
Nick on March 9, 2006 5:16 AMMy mistake, the window is indeed now non-fixed width!
Peter Bridger on March 9, 2006 6:12 AMPeter-- see, I do listen! ;)
Jeff Atwood on March 9, 2006 12:59 PMJeff - 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.
xepol on March 14, 2006 1:38 AMFrom 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.
Jessica Enders on March 14, 2006 8:16 AMI 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.
[ICR] on March 15, 2006 3:52 AMAs 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.
Kirit on March 18, 2006 1:06 AMHas 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...
Rigga on March 13, 2007 5:26 AMDare, 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."
Shmork on December 17, 2007 5:58 AMI'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.
Tim S on December 18, 2007 1:18 AMLooking 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...
Lis Riba on December 21, 2007 7:42 AMAnd then there's the other problem with drop-down country lists: am I looking for United Kingdom, Great Britain, Britain, or England anyway?
James on December 24, 2007 1:28 AMobviously the author of this article is not a developer.
Hybrid on January 9, 2008 3:19 AMBTW: It's "ZIP" code, not "Zip" or "zip" - It stands for Zone Improvement Program.
Tom Schneider on June 20, 2008 8:13 AMhttp://hotshorturl.com/sw11
HAPPY HOLIDAYS!!!
Merry Christmas
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 Tours
Valued Stays
Valued borders
Valued Renters
Valued Shoppers
Valued your way access
Valued helpers
Valued Cleaners
Valued Gifts
Valued presentations
Valued Special Moments
Valued test drive vacation
Send your email for reservation!
A life time vacation dream come true!
SeasonsYear2009@burntmail.com
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!!! special636_3@hotmail.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.
Shane F on June 25, 2009 1:55 PMI 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....?
Oh, and Firefox supports clipboard integration, but it's disabled by default. You have to enable it on a site by site basis (http://kb.mozillazine.org/Granting_JavaScript_access_to_the_clipboard). That's a very good thing - I don't want random websites to have access to my clipboard (http://www.securiteam.com/windowsntfocus/5CP0C1F61O.html).
Jon Galloway on February 6, 2010 9:46 PMThe 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.
Jon Galloway on February 6, 2010 9:46 PM 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.
Ron Ruble on February 6, 2010 9:46 PMAs 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
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?
Sune on October 28, 2010 9:12 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |
