Approach I have used for U.S. with some success...
Objective: Deliver complete address with minimal keystrokes.
Constraint: User can type whatever they want.
Approach: One text box for address. Reevaluate with each new key entered. Use lots of indexed tables (zip codes, cities, states) for verification. Reformat when they leave the box. Provide help, autofill, undo, dropdowns, and error message feedback.
Some of the logic:
- 5 consecutive integers: verify zip code. Autofill city and state. If multiple cities, dropdown for choice.
- 2 alphas and a space: verify state.
- 3+ alphas: verify city. Dropdown for State.
You kinda get the idea. There's probably a lot more optimization that could be done. It's worth it because it's used in so many places.
This is going to be wrong for some of your users, because some ZIP codes cross state boundaries. So you'd need to let them correct the guess in that case. It is unusual for one zip code to be in two states, but it does happen. [1]
It's also going to be wrong for military addresses, as I understand it. [2]
Here's a ruby version, smaller more compact and easier to update (probably more correct too):
def state?(zip)
case zip[0]
when 0 then states = ['CT','MA','ME','NH','NJ','PR','RI','VT','VI','AE']
when 1 then states = ['DE','NY','PA']
when 2 then states = ['DC','MD','NC','SC','VA','WV']
when 3 then states = ['AL','FL','GA','MS','TN','AA']
when 4 then states = ['IN','KY','MI','OH']
when 5 then states = ['IA','HN','MT','ND','SD','WI']
when 6 then states = ['IL','KS','MO','NE']
when 7 then states = ['AR','LA','OK','TX']
when 8 then states = ['AZ','CO','ID','NM','NV','UT','WY']
when 9 then states = ['AK','AS','CA','GU','HI','MH','FM','MP','OR','PW','WA','AP']
else return null
end
return states
end
I used to work for a company that had a large number of constantly-AB tested web forms that required an address, and we tried auto-filling the state (and state/city) from ZIP, as well as only asking for ZIP and it actually dropped our conversion rates, in every case.
Our data could have been inaccurate in some cases (but I seem to remember testing a few hundred addresses vs google's geocoder and getting correct results).
The demographic wasn't very tech focused, so it could be that they were either weirded out, or (in surprisingly many cases) just didn't know their zip code.
Anyway, just make sure to test this before blindly assuming that it increases usability in your case.
Addresses are mainly important for store checkout. A good way to grab the zip code first is to ask when calculating tax and shipping in the cart. When they check out, just default to the zip and state, then ask them to verify on the last step.
A good way for the server to detect user error would be to use IP2location. Unless they're using a proxy or VPN, you could add something that would ask the user to double check if their IP location was more than 100 miles from their zip code. But the user could always override that warning.
I've often thought about this. In the US, addresses are traditionally written in the format:
[City], [State] [Zip]
The state (and often even the city; there are free datasets for this though they're not perfectly reliable and more expensive) can be inferred from the zipcode, so it seems logical that we ought to prompt first for the zip and then help users along by filling the state on their behalf. I suspect his is not done because people are so used to the City -> State -> Zip pattern, asking them to fill the zip first just breaks their expected flow; a "surprise" that makes them think.
I used to work on a case management system for legal aid attorneys that did these lookups and we had to explicitly train them to enter the zip code first (changing field order or tab order didn't help) -- otherwise, they'd never have used it; and some of them still refused to use it, but those who did appreciated the time savings.
When I think about it, I'm thrown off by this pattern whenever I see it, too.
It's also interesting to think about text input versus dropdown select if you decide to go for manual state entry. I prefer just typing in the abbreviation, but I'm not sure that's suitable for a wide audience.
In the UK, a lot of sites just ask you for your postcode and house number. The postcode allows pretty much everything else to be looked up. I assume there's a fallback to full address in all of these sites, but I've never had to use it. It's a great timesaver.
A UK postcode covers about the same area as the 5+4 digit US zip rather than the 5 digit one. You can get a whole town or more in one 5 digit zip code.
I'm not sure many people actually know their full 9 digit zip. Certainly not many of my customers have bothered entering it.
This is even easier for Canada, since the first letter in a Canadian postal code identifies the region (usually a province or territory, but sometimes smaller areas, and in the case of X, two territories).
For a few apps, I've used census data to derive city and state from zip code.
It seemed like a disruptive flow to me too, until I asked for zip without showing any other address fields. On change, the address and prepopulated city and state fields slid down above it and address got focus.
This is hardly used in the US because a lot of things depend on the city and county of a property. And sometimes one zip code overlaps several counties or cities. Besides, everybody insists on using the city/state/zip entry pattern.
Unless you only want to get a users home location make sure to allow them to search by city/state since most people don't know zipcodes for places they're researching for travel/work.
Objective: Deliver complete address with minimal keystrokes.
Constraint: User can type whatever they want.
Approach: One text box for address. Reevaluate with each new key entered. Use lots of indexed tables (zip codes, cities, states) for verification. Reformat when they leave the box. Provide help, autofill, undo, dropdowns, and error message feedback.
Some of the logic:
- 5 consecutive integers: verify zip code. Autofill city and state. If multiple cities, dropdown for choice.
- 2 alphas and a space: verify state.
- 3+ alphas: verify city. Dropdown for State.
You kinda get the idea. There's probably a lot more optimization that could be done. It's worth it because it's used in so many places.