US-centric. I typed a Mexico postal code (it’s five digits) and got routed to somewhere in Maine. So - yeah the whole “I can tell you’re in the US just by the zip code” premise is entirely flawed.
The best times are when US ecommerce sites try to confidently lint foreign addresses, even when they allow shipping there.
I've had them tell me I need 5 digits for my postal code in Norway, which uses 4 digits. I selected Norway in the shipping web form.
Or when they tell me special characters aren't allowed, yet the "special characters" are just letters in the Norwegian alphabet. My address contains ø. These aren't even unicode, they're in the extended 8 bit ascii set. Why are you linting these!?
These happen all the time. Thankfully our postal system recognises this and allows some substitutions (å=aa, ø=oe, æ=ae).
Or some strange concept of state. Well there is some upper divisions, but postal service does absolutely nothing with them and they are never part of any address.
It’s irritating when they make country, region, and city all mandatory. Why yes, I live in the city of Singapore, in the region of Singapore, in the country of Singapore.
Should be titled "Put the Zipcode and country first".
Would be simple enough to have someone type the zip or postal code first, then move the countries that are known to have that zip code to the top of the drop down (still in alphabetical order), and all the other countries below that (also in alphabetical order).
Leave all the fields editable, i.e. the postal code only suggests, ranks, or prepopulates.
Seems like that would handle all the edge cases, including those where a zip code doesn't refer to one and only one city, or where a zip code has changed or been added to a country.
I'm definitely not, but the lazy method is just to cache the data your customers provide, or curate some data for the countries you are most interested in.
That gets around countries that consider their postal code database a licensed dataset.
From UI side, I’d probably not autofill, but add autocomplete (e.g. using <datalist>¹). This way you can still have browser autofill the user’s address if saved (do also set the autocomplete² props correctly!), and suggest one or multiple variants you have in your database, and let the user fill it out manually still, without having to find and click “My address isn’t here”.
Because most websites won't have two separate fields for "ZIP code" and "postal code". Even if they knew that ZIP Code is a trademark (I didn't until you mentioned it), they would (wisely) know that putting in two fields would just confuse most people. So they put in one field. Many sites label it as "ZIP code / postal code", but some just label it as "ZIP code". But the intent is clear: put in the multi-digit string that identifies your address, whether your country calls it a ZIP code or a postal code.
Put country first. Postcode doesn’t make sense without one. Prepopulating one based on location is generally okay, but don’t assume it will always be the same.
That assumes the existence of a reliable, free postcode API of all addresses on the planet.
I did a very brief search, and none of the commercial offerings I could test recognised the postcode of the Eastern European neighbourhood I was born in. Also, like half of African countries don't have postcodes. It's just not a good system.
Only if you're limiting yourself tok those two countries. A lot of countries use the entirety of a 4 or 5 digit range for their codes. Any given 5 digit number is likely a valid ZIP code in at least half dozen countries.
The form stopped accepting input at five characters. I could not enter a "zip code" for my country even if I wanted to.
Even if they fixed that, there are other issues. (You pretty much need to cross-reference it with a database, which assumes said database even exists.)
Yup. I typed my French ZIP code (code postal) and this guessed a US city...
But the author has a point. Combine it with some approximate country-level geolocate of the web client and this would work perfectly 99% of the time modulo edge cases like VPN users.
In the mid-1990's, I requested information from a major multinational corporation (IBM) that had a significant presence in my country. They somehow managed to mangle the six characters of a Canadian postal code, which alternates between letters and digits, into a five digit zip code. Making it even more perplexing, the envelope was addressed by hand and came from New York state. Some Americans seem to think that the rest of the world is a mirror of them, and will go through unusual contortions to maintain that belief. (To be fair: there is another level above that which is Anglo-centric, which allows for just enough variation between English speaking nations.)
I have seen websites that more-or-less takes the author's advice though. They are country specific. They are backed by the postal system's database. They present a list of addresses that match up with the postal code. They do not work very well when a particular address does not have a postal code. And yes, that happens.
Yeah, post codes are a huge pit of an implementation. Each country has their own way of presenting and formatting them, as well as additional validation rules (e.g. valid postal districts). This should be amazing (and is), but if you maintain such a validator you'll have a continuous stream of bugs where clients were able to make a mistake they shouldn't have been able to (often breaking downstream where it is hard to recover) or where you refuse to accept somebodies very real address and they are very personally upset (rightly so).
That said, the obvious solution is <country> <post code> where <country> is prepopulated from geo-ip or browser signals or similar.
Yes, it is US-centric. You all act like that many commercial websites are just like automatically doing international business. I am not even allowed to do business out of my state. I don't even need that filled in. You can see my website anywhere, but you can't be my client unless you're in my state. So I don't care.
Any company able to do business in multiple jurisdictions, well, that's just the kind of extra thing they can handle.
For an enormous amount of sites and for an enormous amount of users this is an improvement and the general reaction here is nitpicking and this self-evident charge that it's US-centric. So what. The principle would apply in most places.
In Costa Rica, there are no addresses but there are (now) post codes. You would have to take that into account to do business there. If this doesn't apply to you then it doesn't apply to you.
It's not like the internal US market is small. This solves a problem for a lot of people in a lot of cases.
The problem is this reduces usability for others. Yes, there are many local to a country sites, but there are also large scale global ones. In both cases, you're not really gaining anything other than some clever autocomplete that could be far more precise if the site offered the correct fields so that whatever autocomplete tooling I use can put the data in for me.
The page itself specifically says "and country", however that too doesn't work. Other non us countries may have the same postal codes, or in my case mine is 4 digits, and I had to figure out that "oh, this is us only and it doesn't work at all for me", which was just entirely a waste of time.
The UI pattern is still stupid. You should be able to quickly enter forms like this on a keyboard.
When I look for a part for my car, I pick “Honda”, “Model Year”, “model”, “trim”.
With address forms, if I type “U” in a keyboard aware field, it defaults to “US Minor Outlying Islands”. Places that try to accommodate will put the US and Canada first.
If you asked country, first, you could utilize the postcode method. Some sites try to autocomplete street address which I personally find annoying as my street is a common streetname.
Meanwhile, here in Bristol, a whole bunch of sites insist on using a drop down for the county and list "Avon" which doesn't even exist. It should be Bristol or possibly City of Bristol.
I think the county list is set in stone because Royal Mail refuses to update them (for some idiotic reason they still control the postcode database, which I guess lots of websites use and therefore use the old county names / boundaries). For example, it's still Humberside, even though that hasn't existed for decades.
Yep, I recall that Royal Mail is one of the websites that has the "Avon" issue. I don't know why they don't just update it to make it accurate as they update their PAF files for postcode lookups every three months with new postcodes. "Avon" is strange as it's still used in some contexts, such as the police force is known as Avon & Somerset
Small distraction, entering the year first is preferred for vehicles, as manufacturers changed names (Nissan/Datsun) or were discontinued (Saturn, Pontiac) after known years.
A tangent, but I've always wondered what is the most efficient way to order the drop-down menus for year, make and model. Assuming your a retailer for hard to find car parts, e.g. rockauto, how do you order those menus such that someone has to do the least amount of scrolling? Year cuts down a number of defunct or newer manufacturers but Make cuts down the number of years for that same group.
I went year-make-model many years ago when I did an autoglass website.
The filtering value is big as you said, and the model year as a first filter is easy to type in, and probably gets you reasonably close if you're off-by-one. Accidentally picking an '05 Sonata instead of an '04 probably has similar parts, but if you pick Honda instead of Hyundai, you're way off in Wonderland.
I can live with lack of auto complete if i don't live in the blessed country. What's bad is when it rejects a perfectly valid address.
E.g. trying to enter a Canadian postal code in a US zip code field fucks a lot of things up. Very frustrating for Canadians trying to buy gas in Washington when the pump asks for a zip.
