views:

128

answers:

3

I'm looking for thoughts on two different ways of entering a property address (i.e. the address of house or business, not an e-mail address) on a web site. What are the pros and cons of separate fields versus a single flexible multi-line entry field? Or multi-line with a separate postal code entry?

Most sites use separate fields and, presumably, store these into separate fields in a database. In other words, input is often some variation of:

House:       [input field]
Street 1:    [input field]
Street 2:    [input field]
Town:        [input field]
District:    [input field]
Postal code: [input field]

However, the above is a bit clunky to enter for fast typists and it's also a bit restrictive in places that have a more free-form address. It's fiddly to edit if you have to "insert" or "delete" a line because you have to copy every field up or down, or retyping the whole thing may be faster.

An alternative is a free format multi-line input (with optional scrollbar):

Address:     |multi-line input field|
             |                      |
             |                      |
             |                      |
             |                      |
Postal code: [input field]

And how to store the address? If multi-line, store all the lines in a single database field? Or split into separate fields and recombine into a multi-line string when editing?

If split fields, what are the fields you use and what are their widths?

+1  A: 

I prefer the split fields, because then it is trivially obvious what the breakup is, and it will also help people who have previously entered information into form-saver type apps. A fast typist knows to press 'tab' to navigate between fields.

In both cases you need to store the address in a 'parsed' form, because you may need to do things with it. (Check the suburb, etc).

Noon Silk
What if you don't need to check the suburb or any of the multi-line input? I kept the postal code separate because this does often need to be checked or is a required field.Also, different countries have very different address formats. How do you deal with that?
Mike Scott
You can render different controls for different countries, if you wish, depending on their selection earlier, or domain, or accept-language, or whatever. Strict input is something I live by, and althought you don't need to check it now, you may in the future. Also, I'd do it just because it's basically a de-facto standard. And users love consistency.
Noon Silk
OK, so what fields and what field widths? I've added that question to the main text...
Mike Scott
Field widths? Up to you. What fields? Depends which country, trivial enough to discover. For a standard implementation perhaps look at how amazon/paypal ask the questions.
Noon Silk
Sure, field widths are up to the developer, but I'm asking what typical values other developers use, e.g. for street, town, etc? Does anyone have a strong opinion?
Mike Scott
No, I have no strong opinions. Long enough to enter what is typically required. It should fit with your design and be common sense.
Noon Silk
+1  A: 

I would choose a single multi-line input field. Addresses in different countries are formatted differently and have different components: for example, there's no State in many countries (expressed as N/A). The ZIP code may be 5 or 9 digits, or can be 2 groups of 3 alphanumerics, etc., so taking that into account can be complex.

But everyone can enter their address in a natural form given a multiline textbox.

MaxVT
I do agree that web sites with a "State" input and "N/A" or "Non-USA" option are somewhat provincial in a global internet, yet so many do it that way.
Mike Scott
+2  A: 

I prefer to use separate fields because this yields structured information while a single fields gives the address but with unknown structure. The obvious advantage is that a single field allows to enter addresses not matching the expected format - for example foreign addresses and post office boxes.

While thinking about your question I got the following idea - a hybrid solution. There is a single input field, but while the user types the input is analyzed and split and this analysis result it shown to the user - subtle highlighting with the field name next to it, something similar to a tool tip. You can have different formats for different address types and countries. The analysis could be based on the overall structure of the address but also on the name of states, countries, or the format of postal codes. Regular expressions could do that but one could also consider a custom description format. Maybe XSD, XML or similar description languages could be (ab)used, too.

The user should be able to change the format by selecting it from a list via a context menu or something like that, change single fields that have not been correctly analyzed, or even completely re-tag the whole address. This would become quite a complex control and I am not sure how well user seeing this for the first time could deal with this control. I could for example imagine that user would be tempted to change not correctly detected fields immediately and not wait until they finished typing a chances for correctly analyzing the address are better then after the first line.

Daniel Brückner
This sounds like a cool idea but it would take a lot of work and require a lot of testing for international scenarios - you'd want it to get it correct most of the time or it would be more of an annoyance than anything else.
Mike Scott