Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have a web application where the user will need to fill many addresses (a few users entering the addresses of other people). It uses autocomplete to speed things up and to reduce duplication (the database contains nearly all streets in the city). Most often than not, the street the user is entering will already exist, but in the rare cases it doesn't the user can just type it regularly and the back end will create it anew.

I'm using a separate input field for each address part (enter or tab - and sometimes space - moves to the next), since even if the street is not known maybe the neighborhood is, and failing that the city will probably be, etc. I expect in the "common case" the user will type about 5 characters total and everything else (street, neighborhood, city, state, country, postal code) will get autofilled for him, so he can proceed to the number and complement (which will be different each time).

My problem is that, in my country, the "natural" order for addresses is:

St. Foo 123/456 ...

instead of:

Foo St. 123/456 ...

How should I set up the order of fields? I've seen in another question that it's not a good idea to change the display order, but if I keep the "type" (street, avenue, etc) first the user will waste time typing it all the time - when the "street" field could autofill it for him. However, when entering an unknown address, that field will have to be typed (so it can be correctly saved in the database), so he'd need to go back to it.

I thought about a few possibilities (with varying degrees of diffulty to implement), and I'd like some feedback on which would be best usability-wise:

  • The "street" field starts focused; if the user selects something in the drop down then the "street number" is focused ("type" is autofilled); if he tries to move to the next field instead (new street will be created) then the focus moves back to "type" instead of forward to "number".
    • ...and when moving away from "type" it skips "street" and goes to "number"; or:
    • ...and when moving away from "type" it returns to "street", and the next time he moves away it goes to "number".
  • The "street" field starts focused, and the focus cycle normally; if the user is entering a new street, the "type" field gets a red border, and the user decides when and how he'll go back to fill it.
  • I use a single field for "type" and "street", and try to perfect my autocomplete to account for the several combinations the user might type ("Av Foo", "Av. Foo", "Avenida Foo", "A. Foo", "Foo").

Any other suggestion is also welcome.

share|improve this question

2 Answers 2

up vote 4 down vote accepted

The last option, using a single field for type and street is likely the best. That said, let's go through the three options and see where the strengths/weaknesses of each are:

The "street" field starts focused; if the user selects something in the drop down then the "street number" is focused ("type" is autofilled); if he tries to move to the next field instead (new street will be created) then the focus moves back to "type" instead of forward to "number".

What happens, for example, in the case of a city where 49th Avenue and 49th Street both exist? If the user enters '49' into the street name field, what is then autofilled in the 'type' field? I'm not sure how you'd implement the 2nd half of this scenario ("if he tries to move to the next field instead (new street

will be created) then the focus moves back to "type" ") but this might cause an inconsistency for the user. Imagine they use the form once, to enter an already-known location (i.e, the focus will go from 'street' to 'street number'. Then they use the form a second time and enter a street name. The form will behave differently both times, and possibly be confusing.

The "street" field starts focused, and the focus cycle normally; if the user is entering a new street, the "type" field gets a red border, and the user decides when and how he'll go back to fill it.

This is problematic because, in the case that the user is (knowingly) entering a new street name, it gives the indication that he's somehow making an error (red typically indicates an error made, in forms), when in fact he isn't - he's just adding a new street name.

I use a single field for "type" and "street", and try to perfect my autocomplete to account for the several combinations the user might type ("Av Foo", "Av. Foo", "Avenida Foo", "A. Foo", "Foo").

Possibly the most problematic to implement, but also the best:

It allows the user flexibility in identifying a street via substring searches. Sometimes street names are confusing - i.e, in the street name "Cherry Hinton Road", someone might only remember "Cherry Road", "Hinton Road" or "Cherry Hinton". This also takes care of the 49th Avenue/49th Street problem I mentioned above.

It allows for flexibility in the placement of the 'type'. Because, while the standard address notation in your country may be Type. Name. Number, so often web forms are aimed at an American audience that people learn to use standards which are not their own. This will allow your users, even if they might be confused as to what format you want, to still use the form correctly.

It automatically associates the street type with the street name in most cases. One less form field to fill out, and again, accounts for people's potentially bad memory. If someone remembers a street as Foo St, but in fact only Foo Avenue exists as an option.. :)

share|improve this answer
    
"What happens, for example, in the case of a city where 49th Avenue and 49th Street both exist?" it will show both, and maybe even more if there's info from more than one city (though I'm customizing for each customer, who by its nature doesn't usually operate in more than one place). In other words, the drop down shows full street addresses ("St. 49, Neigh. - City (ST) - Country"), so the user knows exactly what he's selecting and how the other fields will be filled (and whether or not he needs to add a new street nonetheless). [But in general, your advice was very insightful, thanks!] –  mgibsonbr Feb 2 '13 at 9:53

The most flexible way is used by Google Maps. Try to enter your test sample with 49th and you'll see that it is like your third variant. Is it what you are looking for?

But there is another problem - such user friendly solution may become hard work for developers to implement it. Also, using simple well structured form may be simple in programming and cause quick delivery of your product to customers. Is it critical for your application to receive exact address? Or maybe you can get approximate and then run back-end procedure to correct it or find the most similar address from your database. I only want to say that sometimes struggling for accuracy not worth it. You decide what is most valuable for you.

share|improve this answer
    
The first version of the application was implemented using full structured addresses, but it's not critical that they remain this way. I'm refining it for usability, so some changes are possible, yes. I'm now tending towards sacrificing accuracy a bit in exchange for ease of use. About the Google Maps input, it's great for querying but if it were used for adding new addresses too things would quickly get messy... –  mgibsonbr Feb 2 '13 at 13:42
    
Yes, I agree about adding new address, you are right. So, maybe in case you need to add new address, you may output small popup with parsed and structured address and get possibility to user edit structured address. Of course this shouldn't be too often... –  Serg Feb 2 '13 at 14:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.