Do zipcodes change for example? Can your drop-down quickly go out-of-date? You'd need a way to manually enter a city so people are able to tell the system an address. Do you want to bother making an auto-updating zipcode feature just for a form?
Is it going to confuse people because nobody else has bothered to make this superfancy selection feature thing?
Is this USA only? There are postal codes/zipcode-equivalents in other countries.
It starts to feel it's likely not worth the time and effort to try to be smart about this particular feature. At least not if I'm imagining this us some generic, universal address web form that is supposed to be usable for USA-sized areas.
To me it feels similar to that famous article about what you can and cannot assume about people's names; turns out they can be way more complicated and weird than one might assume.
Although maybe zipcodes don't really go that deep in complexity. But on the spot I would not dare to assume they are.
This is where the real problems start - postcodes exist the world over.
Speaking as someone that has dealt with countries that have postcodes, but no states, so it's just Street Address (if applicable) | City (if applicable) | Country | Postcode
Inputting a "zip code" first would result in every country being in the drop down.
In Australia, addresses too are wild, they should be considered "free form"
https://blog.melissa.com/en-au/global-intelligence/australia...
Gives this as an example address The Smith Family
'Willow Creek' Station
via Winton
QLD 4730
What kind of app are you building? Maybe you're selling something. You probably want users to get through your check out form as fast as possible before they change their mind or get distracted or frustrated.
Or you're building an app for data entry and people are filling in lots of addresses every day. They would appreciate you saving them time.
Either way, spending a day or two to polish up your form can be worth a lot.
Not saying its trivial to get all the edge cases right, but I'm pretty sure we can do better here.
But sure, if you can do it right (e.g. "Put the country first"), then by all means do so!
But in TFA's example it does not (my zip has 3 possible city names; TFA's example shows only 1).
These are reasons you cannot deduce the Zip from the city, not the opposite. A ZIP+4 actually encodes all other information for a US address.
Let me uh just grab my utility bill...
I have a 4 digit postcode, I have to look it up every time I have to fill in an address form for delivery.
I've had people screw 1 digit up in that postcode and their items (a laptop in one case) went to the completely wrong city.
A code sounds foolproof, until you realise most people don't engage with them for most of their lives - you don't tell the uber driver the zip/post code you are waiting in, and travelling to, nobody does.
edit: just to add - Magic numbers are bad. Software engineers know that a number that's undocumented in code is unmaintainable, a zip code is worse.
> A code sounds foolproof, until you realise most people don't engage with them for most of their lives - you don't tell the uber driver the zip/post code you are waiting in, and travelling to, nobody does.
When the above comments said +4, they meant knowing the second half of the nine digit zip code.
Basically everyone in the US knows the first 5 digits. It's really easy to memorize them. If you can remember your city, you can remember your zip code. And in the US you use it all the time, so it stays memorized.
> edit: just to add - Magic numbers are bad. Software engineers know that a number that's undocumented in code is unmaintainable, a zip code is worse.
That complaint about magic numbers is completely off base. Magic strings are just as bad in software. "Beverly Hills" and 90210 are equal sins on the magic front.
What's the 5 digits for Yonkers New York (edited because I originally had NYC)
> That complaint about magic numbers is completely off base. Magic strings are just as bad in software. "Beverly Hills" and 90210 are equal sins on the magic front.
For the same reasons, that's why it would be: Beverly Hills, Los Angelos County, California, USA, 90210
Nobody sends packages where the destination is an entire city. If someone gives me an address inside Yonkers, it'll have the zip code in the address. I've never had to look up a zip code in my life.
> For the same reasons, that's why it would be: Beverly Hills, Los Angelos County, California, USA, 90210
Which reasons? That has nothing to do with magic numbers, except that a 'magic full mailing address' is still bad, you don't shove that into the middle of your code either. If you're looking at the "made a typo" reason then that's where showing the address after putting in the zip code will give you the same verification but faster.
ZIP Codes 10701, 10702 (post office), 10703–10705, 10707 (shared with Tuckahoe, NY), 10708 (shared with Bronxville, NY), 10710, 10583 (shared with Scarsdale, NY)
If you put in any of those numbers it can prefill the city name, with enough accuracy that you don't need to change it.
Did I imply anywhere that cities only have one zip code before you asked about Yonkers? I said if you can remember your city name you can remember your zip code. That doesn't imply you would use a list to get from one to the other.
I picked up the implication that you thought my response could be improved, so I tried to guess what your criticism was and respond to that. If it feels "way off" because I framed it as disagreement, then I dunno, that feels like the right framing? Unless it's something else I did? I could have made it clearer I was guessing but that doesn't seem way off.
I don't know how to link to the correct question but there is why did my code change.
That would be a funny argument if it were the one being made.
Proof: a post office has its own zip code, for PO Boxes.
The +4 is the last four digits of the post office box.
If the Post Office has more than 10,000 boxes, the +4 will be duplicated.
This was news for me. I know the few zip+4 I memorize never change.
I think the source for the parent is AI slop. See [1].
> Due to an increase in population or to the improve postal operations, the US Postal Service® will occasionally add a new ZIP Code or change ZIP Code boundaries.
The plus four digits encode:
> [67] : Sector or Several Blocks
> [89] : Segment or One Side of a Street
Note that this contradicts the parent.
You can do relatively complex forwarding that would only appear to the end users if they can decode the barcode.
Is that an issue? Who cares that new york city has 20+ zip codes? Just fill autofill "new york city, new york".
>for example, some zip's are just for Post Office Boxes.
Again, is it bad except for some joker who wants something sent to an invalid address?
The fact that "A city can also exist in multiple zip codes. And there can be multiple cities with the same name in the same state" is a good point IN FAVOR of asking for the zip code first (NOT to avoid it) because you certainly can't do it the other way round.
And if you just leave it to the user to free-type all that info in, you have to verify it after... Users are going to make typos, and the USPS will kick your butt if you don't correct it (and credit card payments won't go through, either). So it may be less work for web-form creators, but pushing the verification down stream just makes it all worse for the company using it.
I.e. using something like https://ipinfo.io/json and then typing in a full postcode and street name + number should work well in most cases.
If you're on cell service.. yeah probably less accurate. Not sure if it makes the form harder to fill out if you have to change some of the fields.
What I've started doing for my personal app though is I've added a "guess" button. It fills in the form using heuristics but it's opt in. Fills out like 10 fields automatically and I've tuned it so it's usually right, and when it isn't correcting a few is still quicker.
Our country-level data (which is free) is 10-15 times larger than the free/paid country-level data out there. We constantly hear that the size of the database is an issue. The size is a consequence of accuracy in the first place. So, it is a balancing act.
By perfectly, I meant it got my city and zip correct, but I looked up the lat/lng and its a 5 min drive away. So pretty dang close!
Not sure how you got it that close if its only supposed to point to the nearest data center.
I am curious about your experience with us so far.
Autofill solves all of that with an implementation cost that approaches zero.
Sure but a zip code belongs to only one city and one state, right?