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?
相关问题
- bash read timeout only for the first character ent
- How to prevent a UIView from consuming user input
- Why is the following code not allowing me to get u
- Compile sass file inside browser
- Validation for Irish Eircode
相关文章
- Can keyboard of type UIKeyboardTypeNamePhonePad be
- Ruby on Rails: file_field, how do I remove the upl
- Get user input from IDE/Console in selenium webder
- jQuery: password field with readable label?
- Wait set time for user input C# console app
- gets not waiting for user input in expect script
- google apps script: html - form submit, get input
- Java ArrayList, taking user input of multiple type
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.
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.
Definitely split the input. If you can help it--and depending upon your business requirements--it may be wise to perform address verification at the point of entry. This will allow you to know that your addresses are going into your database clean and allow you to do a number of other things such as fraud prevention. Having a verified address can help reduce shipping costs if you're shipping physical goods to your customers and can help reduce credit card merchant fees by ensuring the correct ZIP Code is submitted during AVS verification.
In the interest of full disclosure, I'm the founder of SmartyStreets. We offer CASS-certified address verification services. Users can upload a list for scrubbing (CSV/Excel/etc) to our website or use our address verification web service API called LiveAddress.
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.
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.
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.