Address entry as a single textarea [duplicate]

Question

I am building a ecommerce checkout flow and am looking for best practices for the billing/shipping entries. Every site I use and every one I've looked at for inspiration has the address entries as a separate field for each part of the address. I don't understand why I don't see any sites that allow the user to enter their address in a single free-form textarea box? I'd imagine a single textarea would be much quicker and simpler to use.

I'm seriously considering using the single textarea for my checkout flow but a concern is that it will be different to the common multi-box approach and possibly confuse the customer or at the very least make them stop and think?

Answer 1

TL;DR: Use a single text field, store as a single string, show an address label preview.

---

Separate fields have served limited purpose, such as safely identifying the country, town or zip code area someone lives in. They also allowed to enforce some constraints, such as providing a fixed list of countries. They also - in theory - allowed to "reduce the number of changes made" if a customer record changes. On the more esoteric end, it could help determining left side of the road from right side, by looking at even / odd numbers¹.

This is wrong today for two reasons:

• The world
  for reference, see "Falsehoods programmers believe about adresses"²⁾

• Google
  Online map services do a continuously better job at understanding a plaintext address, and can answer all the queries you might want to (such as which country, which town, which is our closest delivery center factoring in typical thursday afternoon traffic conditions)

---

Note that these are actually two issues:

• Should data entry offer a single multiline field, or multiple fields?
• Shoud the backend store address as a single field, or as multiple fields?

However, I'd argue both benefit or at least are not harmed by a single field.

Rationale

One perceived benefit of multi-field is validation.
Indeed it may protect you against missing significant parts (Chechov's "Wanka" comes to mind). Yet with all the adressing schemes out there, only a human can decide whether any part of the address has meaning individually. For automated processing, address has significance only as a whole.

In my contrieved opinion, showing an address label preview with the usual formating, style and background ("this is how we would address a package to you. Does this look right?") should be enough to prime users to verify the address is correct.

Another option would be using an online map service to show the location you understand from the address entered.

Single field advantages

A single field looks more approachable than half-a-dozen individual fields. Multi-field might border indimidating if you want to cover all possibilities (Now what do I enter in building extension?)

While "address" is rarely requested in first signup, the appearance of a complex form may affect conversion and finish rates.

Input can be expected to be faster, as many users still switch between mouse and keyboard when selecting a new field (casual observation).

A single field allows copy & paste of the address as a whole for advanced users.

@phresnel brings up common errors in data entry, that are usually corrected by the delivery company - further making quesitonable the quality of the data entered.

On the backend, a single field reduces complexity, even if marginal. Moreover, it drives home the point that the address should be handled as a whole, should be considered opaque unless you really do know what you are doing.

Slowing down overzealous developers from attempting validation that almost always will turn out incorrect might be considered a tangible benefit, too.

History

We did have good reasons for separate fields. Early automated processing tools might expect fixed locations for certain fields. We did not have powerful and easily accessible "address to location" conversions, and had to rely on individual field when querying e.g. for sales by country.

Good reasons for multi-field:

You might not have access to internet servives, you might need to be compatible with restrictive processing equipment, your users might rely on aut-form-fill tools that have problems with single-field-adresses. You might be catious and and want to be prepared for a future need of separate fields.

---

¹⁾ this actually was suggested to me some 15 years ago as a good reason why a street number should be a separate field. I don't know if this ever had practical use.

²⁾ While you are at it, also see the equally excellent "Falsehoods ... about names". The conclusions from that would be even further reaching.

Answer 2

This is an interesting question. Thanks for asking.

I had the exact same idea last year, and after some research and even an A/B test, I chose to stick with the field-set approach. This is based on my own experience with an online shop that actually ships fashion items. So this is about shipping address; not the billing address.

1. Users who place online orders are used to the address formats. They know street address 2 field is usually not a required field, and they can use their UK 6-char alpha numeric postal code even if the US "ZIP code" field with space for 5 digit input field. Giving them a text area can sometimes confuse them whether they should write precise instructions or just their city name. Large text areas can sometimes lead to significant conversion losses.

2. In a developer point of view, it's not hard to give a country-specific address field (set). See the xNAL standard. We put the country select list on the top (with geoIP resolving and some guess work), and create a precise address field below the country field. Most of our customers filled the form correctly, and our reports and delivery work is much easier. You could figure out the exact city, state and other information using Google Maps API or such reverse geocoding service, but that's extra work and accuracy is not guaranteed.

3. Browser autocompletion. Just double click the "City" free text box next time you see an address field. Chances are, your browser has history for that field so you can quickly select it. Now double click a text area: No autocomplete suggestions. Safari and some others (probably with addons) can store the addresses in a structural format.

4. Correct tab navigation. Following the xNAL, we have correct tab navigation to allow advanced (?) users to jump to the next address field. Street, city, state, and then postal code.

5. Verification purposes: If you can't ship to some area, you can instantly verify the address input upon submission. Besides, IMO, users would feel you are serious about shipping when they see an address field-set.

Answer 3

From a UX standpoint, the most important question is whether the user's presaved "auto-fill" will fill in your form. You really need to check whether your single text area will work with such features. If it won't, you've potentially lost a user/customer/petition-signer/whatever. Especially with the prevalence of phone/tablet based users, entering an address manually is a huge hassle, and I've quite often rethought my choice to buy/sign/whatever and just hit the back button when auto-fill doesn't work.

Answer 4

I'd imagine address separation boils down to the following:

• Backend storage, useful for a variety of reasons like reporting
• Validation of individual elements of the address to ensure correctness (without, imagine the parsing you would have to do)
• Label printing

The last thing you want is someone's credit card information on file, processed, with no way to ship them their product. This alone may be a reason to separate the fields - so shipping and billing match.

Also note that many forms now can be built to leverage some form of auto complete, so your proposed approach would likely not trigger any of this form auto-completion, which would be a detriment to your users' experience. That, and as you said, the out-of-left-field nature of your practice, may make a shopper look elsewhere.