4 ms·

I've argued many times for making address one big text field. Let people who live in the country, who own the address, format it how they know it should be for

I've argued many times for making address one big text field. Let people who live in the country, who own the address, format it how they know it should be formatted.

Deestan 17y ago
Me too! I've been arguing this for years, and I have yet for someone to reply with a good reason why it shouldn't be handled this way. Bad reasons given: - Safeguard against users who can't be relied on to format their own address properly. Fix 1: Don't worry about that. Fix 2: If you really want this, leave the rest of us an option to use a freeform address instead. - "Out webshop database has these fields." Fix: Change the database, then.
- zeeone 17y ago
  The only reason I can think of is for internal statistics. For example the website owner can run a report on their customers broken down by a state or country. Nowadays with GeoIP, this is obsolete.
  - imajes 17y ago
    what if the destination/shipping is different to the billing, or where you buy it from? Using geoip here is mostly irrelevant and incredibly dangerous if you want to get a strong opinion of who your customers actually are, as opposed to where they are buying it from.
- jamesbritt 17y ago
  '"Out webshop database has these fields." Fix: Change the database, then.' Or let the app first sort out the raw input, make sure it makes sense, then pass it on to the database. I can see wanting to have fine-grained table fields. But I don't like seeing the schema drive the model or the UI. A single textarea really is a strong idea (and like others here have been advocating it fr a few years with mixed results). Seems like these are the sort of mundane tasks computers should be good at. Let humans be quirky and let computers sort it out. Prompt for confirmation as needed.
- dpifke 17y ago
  "Out webshop database has these fields." Fix: Change the database, then. Much harder when the "database" belongs to a third party such as UPS or Paypal.
- kpanghmc 17y ago
  There are several legitimate reasons for requiring users to enter in their address in separate fields. The two main ones are: 1. If you need to integrate with third party systems who require you to break up the address. In case you've never tried, parsing addresses is very hard -- if not impossible -- depending on how many formats you need to support. All it takes is one third party library that requires you to break them up to make your life miserable. 2. If you need to categorize your users by country, state, zip, etc. For example, if you need to handle different tax laws for different states or if you need to generate reports on how many users you have from country XYZ.
  - Goosey 17y ago
    Are there any promising open source libraries to fill this niche? Or startups offering it as a service API? Honestly this seems like a problem that could be solved once and we all would benefit... And like any good problem, there is probably a profit to be made from it.
    - pyre 17y ago
      It seems like it would make it that much easier if it were a text box and a country selection (rather than just a text area, so you can reliably know the country). Since most countries that I'm familiar with have a limited number of ways of representing an address. The larger variation seems to be between address formats of different countries.
  - WingForward 17y ago
    Is parsing the addresses on the back end harder than providing the same number of support formats on the front end?
    - kpanghmc 17y ago
      Parsing on the backend, even when only considering United States addresses is incredibly difficult and error prone. There are apartment numbers, rural routes, PO boxes, circles, streets named after compass directions (i.e. North, South, East, West), streets whose direction names appear before or after the street itself (e.g. N. Main St. vs Main St. N.), military addresses, and the list goes on and on. It's a terrible system really, and the only solution that I've been able to rely upon is having the user parse their own address and supply it to me. At least that way I don't have to spend hours looking through regex statements and edge case detection logic to figure out why a street address was parsed in a particular way.
- lkjhgvbnm 17y ago
  Because chapter one in the databases for dummies book used address as an example, with fields for address, town, state etc. Then you stick them altogether and print them on the envelope, thus covering chapter2 = report generating.
zeeone 17y ago
Which would make so much more sense in the first place. I don't even know why did they make them in separate fields in the first place. To give you a huge listbox of all states to choose from?! Oh, wow!
- Retric 17y ago
  While accepting generic address is nice, if you actually use the address for anything actually knowing the Country and Zip+4 for the US gives you a lot of power for things like advertizing campaigns. Also, the chances of a user entering bad data when given an unformatted field increased dramatically. My suggestion is to give the option to enter generic information but don't let that become the default.
  - pyre 17y ago
    Or: * allow the user to enter a free-form address, normalize it and then prompt the user for confirmation that the normalization was correct. * Allow the user to edit fields on the confirmation page. * Log any differences between the normalization and what the user changes for further refinement of the normalization process. * Don't require fields that may not be relevant to all addresses that you plan to capture. * Allow some sort of contact avenue on the address confirmation page so that they can complain when the interface doesn't allow them to properly enter their address. (If people hit a brickwall while trying to submit their address, they are more likely to just give up if they have to hunt down contact information. At the very least, if there is an easy way for them to complain, you get some sort of feedback even if you lose them as a customer.)
    - lkjhgvbnm 17y ago
      Why are you normalizing it? Is there some huge performance advantage in having the state field be an Id into a states table? Perhaps it would make updates easier if they ever rename Washington? Why not normalize the name? There must be lots of Johns in your DB
      - 17y ago
elai 17y ago
Or you can just make the state field optional, add an address2 field, let zip codes be a free form string and phone-numbers a free form string. What cases would not be covered then?
wvenable 17y ago
I recently made some parts of my web application worse in this regard in order to be compatible with more US payment processors and some regulations. I don't think I'll have a huge problem with international users yet, but if it needs more code to satisfy them then I'll add it when necessary. Unfortunately, one big text field doesn't cut it when every other system you interact with requires separate fields.
ubernostrum 17y ago
Freeform address boxes can make some things more difficult: http://news.ycombinator.com/item?id=1234105 http://news.ycombinator.com/item?id=1234105

I've argued many times for making address one big text field. Let people who live in the country, who own the address, format it how they know it should be formatted.

Deestan 17y ago

Me too! I've been arguing this for years, and I have yet for someone to reply with a good reason why it shouldn't be handled this way. Bad reasons given: - Safeguard against users who can't be relied on to format their own address properly. Fix 1: Don't worry about that. Fix 2: If you really want this, leave the rest of us an option to use a freeform address instead. - "Out webshop database has these fields." Fix: Change the database, then.

zeeone 17y ago
The only reason I can think of is for internal statistics. For example the website owner can run a report on their customers broken down by a state or country. Nowadays with GeoIP, this is obsolete.
- imajes 17y ago
  what if the destination/shipping is different to the billing, or where you buy it from? Using geoip here is mostly irrelevant and incredibly dangerous if you want to get a strong opinion of who your customers actually are, as opposed to where they are buying it from.
jamesbritt 17y ago
'"Out webshop database has these fields." Fix: Change the database, then.' Or let the app first sort out the raw input, make sure it makes sense, then pass it on to the database. I can see wanting to have fine-grained table fields. But I don't like seeing the schema drive the model or the UI. A single textarea really is a strong idea (and like others here have been advocating it fr a few years with mixed results). Seems like these are the sort of mundane tasks computers should be good at. Let humans be quirky and let computers sort it out. Prompt for confirmation as needed.
dpifke 17y ago
"Out webshop database has these fields." Fix: Change the database, then. Much harder when the "database" belongs to a third party such as UPS or Paypal.
kpanghmc 17y ago
There are several legitimate reasons for requiring users to enter in their address in separate fields. The two main ones are: 1. If you need to integrate with third party systems who require you to break up the address. In case you've never tried, parsing addresses is very hard -- if not impossible -- depending on how many formats you need to support. All it takes is one third party library that requires you to break them up to make your life miserable. 2. If you need to categorize your users by country, state, zip, etc. For example, if you need to handle different tax laws for different states or if you need to generate reports on how many users you have from country XYZ.
- Goosey 17y ago
  Are there any promising open source libraries to fill this niche? Or startups offering it as a service API? Honestly this seems like a problem that could be solved once and we all would benefit... And like any good problem, there is probably a profit to be made from it.
  - pyre 17y ago
    It seems like it would make it that much easier if it were a text box and a country selection (rather than just a text area, so you can reliably know the country). Since most countries that I'm familiar with have a limited number of ways of representing an address. The larger variation seems to be between address formats of different countries.
- WingForward 17y ago
  Is parsing the addresses on the back end harder than providing the same number of support formats on the front end?
  - kpanghmc 17y ago
    Parsing on the backend, even when only considering United States addresses is incredibly difficult and error prone. There are apartment numbers, rural routes, PO boxes, circles, streets named after compass directions (i.e. North, South, East, West), streets whose direction names appear before or after the street itself (e.g. N. Main St. vs Main St. N.), military addresses, and the list goes on and on. It's a terrible system really, and the only solution that I've been able to rely upon is having the user parse their own address and supply it to me. At least that way I don't have to spend hours looking through regex statements and edge case detection logic to figure out why a street address was parsed in a particular way.
lkjhgvbnm 17y ago
Because chapter one in the databases for dummies book used address as an example, with fields for address, town, state etc. Then you stick them altogether and print them on the envelope, thus covering chapter2 = report generating.

zeeone 17y ago

Which would make so much more sense in the first place. I don't even know why did they make them in separate fields in the first place. To give you a huge listbox of all states to choose from?! Oh, wow!

Retric 17y ago
While accepting generic address is nice, if you actually use the address for anything actually knowing the Country and Zip+4 for the US gives you a lot of power for things like advertizing campaigns. Also, the chances of a user entering bad data when given an unformatted field increased dramatically. My suggestion is to give the option to enter generic information but don't let that become the default.
- pyre 17y ago
  Or: * allow the user to enter a free-form address, normalize it and then prompt the user for confirmation that the normalization was correct. * Allow the user to edit fields on the confirmation page. * Log any differences between the normalization and what the user changes for further refinement of the normalization process. * Don't require fields that may not be relevant to all addresses that you plan to capture. * Allow some sort of contact avenue on the address confirmation page so that they can complain when the interface doesn't allow them to properly enter their address. (If people hit a brickwall while trying to submit their address, they are more likely to just give up if they have to hunt down contact information. At the very least, if there is an easy way for them to complain, you get some sort of feedback even if you lose them as a customer.)
  - lkjhgvbnm 17y ago
    Why are you normalizing it? Is there some huge performance advantage in having the state field be an Id into a states table? Perhaps it would make updates easier if they ever rename Washington? Why not normalize the name? There must be lots of Johns in your DB
    - 17y ago

elai 17y ago

Or you can just make the state field optional, add an address2 field, let zip codes be a free form string and phone-numbers a free form string. What cases would not be covered then?

wvenable 17y ago

I recently made some parts of my web application worse in this regard in order to be compatible with more US payment processors and some regulations. I don't think I'll have a huge problem with international users yet, but if it needs more code to satisfy them then I'll add it when necessary. Unfortunately, one big text field doesn't cut it when every other system you interact with requires separate fields.

ubernostrum 17y ago

Freeform address boxes can make some things more difficult: http://news.ycombinator.com/item?id=1234105 http://news.ycombinator.com/item?id=1234105