I read this article a long time ago and I took it seriously. So instead of asking for address, postal/zip code, city, state/province, I just put up a big text area labeled "Full address" so that people have complete freedom about what to fill in.
80% of the users ended up only filling in their street address, not their postal/zip code, city and state/province, even though they're from countries where (most?) addresses satisfy that format.
We ended up reverting to the previous form where we explicitly asked for postal/zip code etc.
This is where most of the "falsehoods programmers believe" articles fall flat.
The thing to do is not try to design a single form that accommodates every possible address or name or whatever. The thing to do is examine your use case, design a form that works for, say, 99.9% or more of the people you want it to reach, and then if you really want to get the last 0.1% have someone who can do customer service and has access to a freeform text box into which they -- not the end user -- will enter the information.
Because when you get right down to it, the freeform text box is the only thing that accepts 100% of valid addresses (or valid names, or whatever). But it also necessarily accepts a ton of invalid ones, too, and so it causes more trouble for the common cases than it saves in the uncommon ones.
So maybe have a typical address form and add a checkbox labelled "My address doesn't fit the required format" that would replace your usual form with a freeform text field?
I've found that if you have authoritative addressing data for your target market(s), a search/autocomplete field is a great alternative to the multi-field form being talked about in this discussion. Having access to that sort of data is, of course, a pretty big caveat as much of it is currently proprietary but efforts are being made globally to address (couldn't resist!) this (e.g. http://openaddresses.io, http://alpha.openaddressesuk.org).
"Punt and let customer support handle it" is a pretty lazy solution, in my view. Additionally, what a developer might think of as a "99.9%" solution is more often than not a 99% solution, or a 90% solution. With enough customers, dealing with everyone who can't use your slapped-together form will be more expensive than doing it right.
Software doesn't become great by assuming someone else will handle the edge cases and details, although you may get away with selling it for a while until your user base grows.
With enough customers, dealing with everyone who can't use your slapped-together form will be more expensive than doing it right.
The way you write shows some deep assumptions: that this is a case of "slapped-together" vs. "great" software, for example. And those assumptions are, I'd assert, counterproductive to the discussion at hand.
The comment I was replying to actually was a real-world example of what you're missing, namely that this is a trade-off. Every time you support another 0.0001% of corner cases, you're increasing the surface area of potential failures for other cases. And since the other cases are far more common, they're going to bite you more often.
Supporting the most common cases, to a 99.9% or so level, directly and then having an escape hatch for the rest is not "slapped together" -- it's deliberate design which takes the problem and the cost/benefit of different solutions into account. It's also, from that perspective, almost certainly the correct design.
And yet it gets blasted repeatedly in articles like the OP here, which assume that the only possible reason for such design is ignorance/incompetence on the part of the developer. That simply is not true, and you should stop implicitly buying into that (it's another assumption that's hidden in the way you write).
Except, in this scenario, it's relatively easy to come up with a good 99.9% solution:
Seven text fields will cover greater than 99.9% of users:
Name
Address Line 1
Address Line 2
City
State
Country
Postal Code
So much of that article discussed stuff that was irrelevant - Live in Singapore? Great, just fill in Singapore, Singapore, Singapore. I've done that on many, many sites and it's always worked fine. Don't have a postal code in Ireland? Most people there learn to try EIRE or 00000.
I think a better article would have been:
"Here are the scenarios in which the 7-text address system doesn't work, and how you can make it better." - But I couldn't find anything that suggested it wouldn't work just fine.
My country unfortunately doesn't fit that scenario. Here in the UAE there is no residential postal delivery, so if you want to receive letters you have them sent to a PO Box. Most people usually use their office's, but I have my own. That means you can reach me with simply:
PO Box XXXX
Dubai
UAE
For sending parcels to be delivered by a courier you can include a physical address, however most streets here don't have names (and even if they do people have no idea what they are) so people go by directions. Which means something like:
Flat XXXX
Building Name next to / opposite / near Landmark
Area Name
In most cases it's best to include a phone number so the courier can phone for directions if they get lost (without street names it's easy), and of course everyone requires a name even though I'm the only person living here and using this PO Box. That means my 'full address' ends up being:
Name Surname
Tel: 05XXXXXXXX
Flat XXXX, Building Name
Next To Landmark
Area Name
PO Box XXXX
Dubai
UAE
In most cases that never fully fits in the length of the fields, or they do something silly like requiring a postcode but limiting it to 5 digits (luckily my PO Box number is only 4 digits in length, but in reality they are [0-9]*). Anything I order from eBay has "NOTPROVIDED" on it as I left out an optional field they think should always be included :D
Edit: Area names have their own fun: There is a road going from one end of the country to the other which in Dubai is called Sheikh Zayed Road (it has a number and different names in other emirates :D), but that is also the name of an area along part of the road.
I think this is the key point. Sure, you can come up with some clever and unique system to accommodate the one percent of your user base who isnt well served by standard forms, but that 1% is already used to adapting their unique information into a standard format.
Web forms for things like name and address are a sort of ad-hoc standardization of a nonstandard data type.
The main thing is not to make every field required. I've got nothing meaningful to fill in at state, nor at address line 2. Too many sites make too many false assumptions about addresses.
I have never seen anywhere require "Address Line 2." It's only used as a specifier to the address when there are multiple units at the address (office buildings, apartments, and the like).
Great software is that which solves your business problem.
If not "punt to a human", what's the solution? We've already seen that giving users a free-form text box is a cure worse than the disease. Do you analyze every country's address scheme and make a dynamic form that covers all the cases? (worse IMO - it's not going to cover all the cases, and it's going to be even more infuriating for users when it goes wrong. See the Jersey example in another comment) Some wizard solution that I can't think of? Saying this approach is "lazy" is all well and good, but do you have a positive proposal?
At least it helps if you don't block on empty fields then - I keep getting annoyed when sites demand I enter "state/province" for international shipping when my country doesn't have that concept.
Or demand that I enter 6-digit postal code when we only use 4. Or not being able to handle non-ASCII chars. And things like that - helping people is fine and useful, but blocking a user because you set up assumptions valid only for your locality is a huge annoyance.
If your country doesn't have the concept of separate city/country, (Singapore doesn't) - you can just enter "Singapore, Singapore, Singapore"
Or UK, London, London.
Totally agree that systems should not presume to known (often incorrectly) the format/content of such fields, outside of areas where they can. (I.E. Validating Postal Codes in regions like Canada, United States, etc..)
> I keep getting annoyed when sites demand I enter "state/province" for international shipping when my country doesn't have that concept.
And uses a select box of US states, so even if your country did have such a concept (and used it for mail, which may not be the case) you couldn't give it.
Yup, I’ve done that far too often, I even have a bookmark to a small script that just replaces the next input box I click on with a freeform text input.
We tried the same basic move — one open-ended address field instead of a set of more specific parts — in an attempt to simplify our sign-up flow. We too have since reverted to a more conventional multi-part form.
First thing we discovered: We might have been happy with one big box, but none of the payment services we use worked the same way. This more than cancelled out any usability benefit, because we could no longer reliably pre-fill the address fields on any form for card or bank details. Our customers would still wind up entering the specific parts of their address anyway, but now they effectively had to type the same address twice during the sign-up process as well! (Edit: There’s also a related issue that some browsers will remember and pre-fill fields that look like common address parts automatically, which to my knowledge no browser does for an open-ended address.)
Second thing we discovered: Same as 'FooBarWidget, given a freeform text field, some customers will give you beautifully formatted multi-line addresses, some will stick everything on one line, some will stick just the first line on that one line, some will assume you meant e-mail address(!) and so on.
More recently, we also discovered a third issue because we’re in the EU: I can see no reasonable way to automatically parse any common address format that is sufficient to comply fully with the new VAT place-of-supply rules, but to have a chance of even getting close in the 99% case you at least need to have a separate country indicator.
I do sympathise with the frustration of having to break down addresses into different fields. If the big bureaucracies like payment schemes and governments had more practical rules for working with customers in different locations, one big box really is all we should need, though getting customers to enter something valid in it is still a tricky issue. But since those more practical rules seem unlikely to happen any time soon, there is little either we or our immediate service providers can do but follow the dubious but widely accepted conventions anyway.
Did you need it for delivery of something? Was that made very clear to the user? I can't believe so many people, wanting to receive something through the post, would wilfully screw up their address - maybe there's more to your use-case than meets the eye?
Simple clerical errors rarely invalidate a contract. I'm not a lawyer though so I don't actually know.
I would have done address line 1, address line 2, line3, etc. I think people got confused by your form because they are used to typing in 1234 Sample Street <tab> expecting to be asked the rest of the information further down. The other option would be on form submit to show what they have put in and say "make sure this is your full address [CONTINUE] [EDIT ADDRESS]."
Don't know about the US, but here in the UK having an incorrect address in a contract may make it trickier to enforce a court decision against a company as certain kinds of documents used in the court process are only valid if served to the Registered Office of the company.
Why would the address on the contract matter? If the contract lists 'ABC' as their address, you still need to serve papers to their registered office which may have always been XYZ, or may have changed after the contract was signed - so in any case you have to ignore the address on the form and use the official one that you look up from the registry.
The only case where I've seen address used as a disambiguator is when treating multiple private individuals with the same name, but in that case also you want some official ID, not the address which may change frequently (and may contain a different John Smith than the one who lived there a year ago).
Well, if putting down the wrong address on a contract is enough to invalidate the contract, then people would be "accidentally" fudging their addresses all the time. :)
Really, I am no legal expert but I did once sue someone in small claims court. They wanted to know what I did to verify the other party's address, not just taking their word for it.
I cannot imagine how such a law, dealing with international addresses and all the issues identified in the article could ever be practically applied, but I guess YANAL.
Did you try pre-filling the address field with an example address (John Doe, 123 Example Avenue, Hobbiton 1234) to make it clear what is required? (Although it seems like placeholder text only works with textarea fields since HTML5...)
Side by side examples would be better, because the example is still there for double checking after you've filled in the data. Pre-filled obliterates the example.
Indeed, I've been on the receiving end of somebody taking this kind advice to heart once, and things not working out too well.
At that job the we had a legal obligation to let anyone in the country to opt their building out from a certain database, by entering the address on a web form. We'd then send a snail mail verification code to that address, and enact the opt out on entry of the code.
This was covered incredibly well in the media, and the number requests was in the millions (don't know how many of those actually turned out to be valid). I suspect the people who'd made the web form had read this exact rant about addresses, since contrary to how things were normally done, they'd just put in a big textarea for the address. Now, this was completely unnecessary even by the standards of the "falsehoods" article, since it was a country with very well established address conventions, and since by definition no addresses from other countries should be entered. And as might be predicted, it caused some problems.
First, just as you note, people didn't really understand what they needed to enter into a textarea like that. They didn't do as bad a job as in your case, but you'd have things like people leaving out zip codes, leaving out the city, putting their name on the first line (even though the name had been asked for separately), entering all address components on the same line, entering addresses in different countries, and so on. And unfortunately the geocoding service used to let them check whether the address had been interpreted correctly (for the purpose of "this is the address that should be expunged from the db") was very good at finding the right location even with badly malformed addresses, and no other input validation was done. BTW, it's quite likely that without this geocoding step the amount of bizarrely formatted or just outright invalid addresses would have been higher.
More importantly, even ignoring the data quality issues, the services used sending out millions of letters in bulk would not accept free form addresses in general. No, they needed the address broken out in separate fields, exactly in the way they would have already been stored if we'd had the kind of structured input form that everyone uses.
My part of the story was then to clean up the mess, a task I got despite being in a totally different group, since I happened to work on the address extraction parts of the geocoder at the time. A disaster always takes precedence over real work :-/
Writing the code to do the right thing 99% of the time took a few days, and I don't want to know how much time was spent by someone manually on the remaining 1% that were flagged by the program. I somehow doubt that anywhere near as much time was saved on punting on the web form.
Knowing that addresses may not conform to any arbitrary rules should lead to disabling automatic validation (or downgrading it to nothing more but suggestions, "are you sure that's correct?" hints).
Pretty much sums it up. Instead of a simple form and some "I have an unusual address format" check box that gives a more free form field we have people abandoning all restrictions.
And being burned by the total anarchy tried, there is the usual discussion about localization not being worth it that simplifies to "I don't believe those not like me should get my attention".
80% of the users ended up only filling in their street address, not their postal/zip code, city and state/province, even though they're from countries where (most?) addresses satisfy that format.
We ended up reverting to the previous form where we explicitly asked for postal/zip code etc.