views:

582

answers:

6

My current app needs to store address information for a user. I'm currently debating whether to use the customary street address / city / state / zip textboxes and dropdowns or to go with Google's method of simply having everything on one line. Any thoughts on the pros/cons of storing address information in either of these manners?

+10  A: 

You should split it up. It will make it far easier to do reporting down the road. What happens if you want to pull up all the residents of a state or zip code, or city? If you use all one field, you will be stuck and wish you had split it up.

Also, users will forget to put in all the information you need if you don't prompt them for it.

Georg Zimmer
+5  A: 

Judging by the user-input tag on your post, I assume you are referring to how the user enters the data, and now how you are storing the data in your back-end database.

Presumably your database will still need to store this information as separate fields, if you want to be able to sort and analyse the information (e.g. for reporting and statistics purposes).

In this case, I think it would depend on how confident you are that you could parse the addressing information properly into its individual fields.

One hybrid option would be to allow the user to enter the address as a single line, and then do a best-effort parsing of the information into the separate fields. This is similar to how Outlook manages addresses for contacts - you enter all of the information into a single memo field, and then it splits it up for you. You can then correct if it interpreted any of the fields wrong.

LeopardSkinPillBoxHat
In my opinion, the hybrid method is the way to go. Unless I'm having something shipped and need to be sure the address gets parsed correctly, I _hate_ it when poorly designed sites force me to split my address myself.
albertb
+2  A: 

I tend to split it up, allows searching to be done for a specific section of the address and you can limit the addresses you want to handle by knowing the formatting i.e. Only ship to east coast addresses.

Jiminy
Agree that this has less to do with how you handle the input as it has to do with searching later on.
Riri
+3  A: 

I would be very much against just having a single text field where users enter their address. You'd be surprised how many people will leave out their zip code or some other important info if you don't have a specific field for it. Also, as others have mentioned, it make reporting much easier to report on this information later if all the data is pre-parsed. As other users mentioned, programs like outlook will parse this information, but only because the source of the data is often the signatures of emails, which is something that is never in a consistent format.

Kibbee
+2  A: 

1) You should split it.

2) May I recommend you read this before you attempt to do international address input?

Claudiu
Do not depend on that article. The writer understands the issues but gets half of the details wrong.
Windows programmer
@Windows programmer: Which half? @Claudiu: +1 for mentioning different address formats
Treb
+1  A: 

I concur with Kibbee. I was even surprised to see people don't even read the field's labels, inverting first and last name, postal code and city, etc.
No, you can't determinate if a postal code is valid, in a Web application targeting international customers...
Some countries have alpha characters in postal code, various lengths, no state info, etc.

PhiLho
Although it is possible to attempt to validate postal codes for some countries, there's no guarantee your datasource will have the correct codes itself, so it should be a guideline and not a rule. My town split from one zip code into two; mine stayed the same, but several sites thought it changed...
Dave DuPlantis
... and it was very frustrating to have to contact the few that wouldn't let me correct it and explain that THEY had the zip code wrong.
Dave DuPlantis