Comment by apendleton | Hacker News Reader

Comment by apendleton | Hacker News Reader

Parent Full thread

Funny. This is the one to which I had the most negative response. Zipcodes are terrible for inferring anything geographically interesting. A single zipcode is just a collection of USPS postal routes; nothing more, nothing less. They don't have to be contained within a single city, or even a single state, nor do they have to be contiguous, and they can overlap with one another. New ones are also added all the time, and no publicly available databases of them handle any of these problems well. Most applications that try to use them for anything end up running across edge cases that show users incorrect data, often without ever realizing it. It's especially unfortunate because so many startup-y people live in urban areas where zipcodes cover small, regular geographic areas, and have no idea they're potentially creating terrible user experiences for people who live elsewhere.

For a particular case study of sorts, see: http://sunlightfoundation.com/blog/2012/01/19/dont-use-zipco...

I did a form that worked wonderfully... you entered a zip/postcode (first, before country and such).

The form would look it up in a background ajax call. It wouldn't tell you this or block your actions. If it found a match in our DB, it would populate the city, country fields, not make a mess, and leave you free to edit the form if it was wrong. Your flow would be the same either way.

I think not interrupting the users flow was a big part of it.. it didn't make people go "What? How do I change that? What happened? That's not right".. you just kept filling it out like normal... with some fields pre-filled if you were lucky.

Google Maps has my postal code wrong for 2/3 places I've lived.

ZIPs are almost always fine at a state granularity, and pretty good for cities. If the form is street/city/state/zip, you can autofill State correctly from ZIP 99.9% of the time.

Do you have data supporting the 99.9%? I suspect that's high; there are buildings within five blocks of where I'm sitting that have a zipcode that crosses a state line, and I don't think it's the only state-crossing zip in my area (Washington, DC, for what it's worth). In any event, even if it's accurate, it doesn't take that much traffic for a .1% error rate to start to add up to non-trivial number of users, especially because that .1% is going to have a noticeably-jarring experience, as opposed to the alternative (collecting all fields) which everyone is already completely accustomed to.

Well, this list shows 293 ZIPs that cross state lines [0], this FAQ says there are ~43,000 ZIPs in use [1] so that puts it closer to 99.3%.

But think about it, if you're taking an address to ship something, getting the ZIP right is what matters. If your package has 45201 on it, it doesn't matter if it says Cincinnati, OH or Cincinnati, KY.

[0] http://web.archive.org/web/20110112211559/http://maps.huge.i...

[1] http://www.carrierroutes.com/ZIPCodes.html

But if you're collecting a billing address (probably more common, since many places bill but don't ship, e.g., for digital goods, but not that many ship without billing), and are trying to expedite filling out the form by guessing the city and state from the zip, I doubt the payment processing would succeed if you got the city or state wrong. All depends on the situation, I guess.

Actually, should work as long as the zip code is right.

AVS[1] doesn't even look at the city/state. It only checks the ZIP (5 or 9 digit) and the numbers in the street address.

[1] http://en.wikipedia.org/wiki/Address_Verification_System

Reply on news.ycombinator.com