Live data from Hacker News

Falsehoods programmers believe about addresses

mjt.me.uk

121–130 of 150 posts

Re: Falsehoods programmers believe about addresses

#121

Earlier quoted context omitted.

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 acc…

"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 a…

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).

Re: Falsehoods programmers believe about addresses

#122
I'm not sure how many of these falsehoods programmers actually believe. But one falsehood I've actually seen in the wild isn't included:

"(Direction) Street" is necessarily the same (or different) than "Street." Or even if they're different, users will understand the difference, at least on a local basis.

I had a GPS that would always omit any directions that prefixed a street name. I was occasionally thrown for a loop when it told me to turn on Beacon St in Boston, when it really meant North Beacon St, which is a nearby, but unrelated, street.

Re: Falsehoods programmers believe about addresses

#123
post #119

Earlier quoted context omitted.

I got in to an argument in school with my computer programming teacher. A BASIC course, we were having to design a system to accept an address, and I was treating my ZIP code as a string. IIRC, something like 50 INPUT "Your ZIP code?", ZIP$ Everything was reviewed via handwritten code and flowchart before we were allowed to type it in in the lab, and I was told "ZIP code is a number, but you're putting it in to a str…

The worst is when you store it as a string, having learned from others' mistakes, but then upon exporting to CSV... Excel kindly strips the leading 0 and you get a bug report that your software is screwing up the ZIP codes! Took a bit of searching before finding this: https://www.webdigi.co.uk/blog/2010/handling-leading-zero-in...

Excel is the bane of my existence. I give a lot of speeches about how to preserve data precision. However It seems to be largley in vain, as there is often a lot of back and forth when handling data between different groups, even programmers don't seem immune from screwing up a csv file with excel.

Re: Falsehoods programmers believe about addresses

#124
Maybe a good approach would be to use a format that somehow fits 99% of the addresses and a link on the bottom of the form with the text "Problems fitting your address in that form?". When the user clicks the link, all the fields of the form would be substituted by just a multi-line input field. Then you have a solution for the 1%.

Re: Falsehoods programmers believe about addresses

#125
post #70
post #63

A falsehood only distantly alluded to: That people have addresses at all, or can describe their residence in an unambiguous or clear way (even using GPS coordinates). I used to live in a place I couldn't even remotely give directions to. It was deep within a neighborhood of a poorer country, none of the streets had names, none of the buildings are numbered. I lived in an building where none of the apartments had numb…

Furthermore, just because you don't have an address doesn't mean you can't receive mail! At least as recently as a few decades ago, there were rural communities in the US where nobody had a street address; the postal service knew where everybody lived and would deliver mail given just a name and town. I'm not sure whether this arrangement still exists in the US, but I'm pretty sure it still does in Ireland and probab…

The push for 911 changed a lot of places by assigning street names, but the 911 folks are sometimes the only ones who know the names. UPS still delivers to some vague addresses on the reservation. Shipping to "House 311 behind the school" does tend to confuse a few Internet merchants.

Re: Falsehoods programmers believe about addresses

#126
post #107

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?) addresse…

Right course, wrong reaction. 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). Not to stop offering users any guidance.

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".

Re: Falsehoods programmers believe about addresses

#127

Is it common to believe that post codes don't start with zero? All of New England (ME, MA, NH, CT, RI, VT) have zero starting post codes. Plus apparently a part of New Jersey. Map here: http://en.wikipedia.org/wiki/ZIP_code Also, since it brought up naval vessels, here's the addresses of all US Navy ships: http://www.navy.mil/navydata/ships/lists/ship-fpo.asp Anyways, the post office does a wonderful job delivering m…

I got in to an argument in school with my computer programming teacher. A BASIC course, we were having to design a system to accept an address, and I was treating my ZIP code as a string. IIRC, something like 50 INPUT "Your ZIP code?", ZIP$ Everything was reviewed via handwritten code and flowchart before we were allowed to type it in in the lab, and I was told "ZIP code is a number, but you're putting it in to a str…

I remember when we did MS Access basics in my ICT class in what Americans would call middle school, and my teacher correctly mentioned that a telephone number is text, not a number. :)

Re: Falsehoods programmers believe about addresses

#128
post #10

There are so many misconceptions from developers, even more when building apps used worldwide. If you plan to accept data from different countries, free text with no validation is the only acceptable answer. I remember once we had to remove validation from names because some countries don't even have last names, and others have real names with two or even one characters.

free text with no validation is the only acceptable answer. Unfortunately, it's not an acceptable answer in practice. In my experience, users aren't clear what to do when presented with a free-form, multi-line text box in which they can enter their address. This results in frequent missing data – users aren't aware they need to include a postal code, or county, or country… This is probably because users are generally…

Two suggestions:

1. Use placeholder= to show sample text

2. Explicitly request certain details

Re: Falsehoods programmers believe about addresses

#129

Earlier quoted context omitted.

"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 a…

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…

>Most people there learn to try EIRE or 00000.

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.

Re: Falsehoods programmers believe about addresses

#130
post #108

Earlier quoted context omitted.

I got in to an argument in school with my computer programming teacher. A BASIC course, we were having to design a system to accept an address, and I was treating my ZIP code as a string. IIRC, something like 50 INPUT "Your ZIP code?", ZIP$ Everything was reviewed via handwritten code and flowchart before we were allowed to type it in in the lab, and I was told "ZIP code is a number, but you're putting it in to a str…

People really need to learn the difference between ordinal, cardinal, and nominal numbers... And what 'semantics' are.

Are ZIP codes actually number? I'd say they're really numeric strings, and should be handled as strings.
Post reply on HN