Localizing address fields

28 Jun 2005 - 9:22pm
9 years ago
9 replies
1164 reads
Cynthia Toryu
2005

Hi there,

I'm looking for advice on localizing address fields. I'm designing a UI that
could potentially be used by folks in a large number of countries. The
target user profile is a small business owner who uses a computer to get her
job done, but is not technically savvy.

Different countries use different terms to represent similar information.
For example, the U.S. uses "zip code", but all other countries seem to use
"postal code." Similarly, the U.S. uses "state" where other countries use
"province," "region," or "prefecture."

To reduce development effort, we're thinking of using "or" to combine
different country's terms in the field labels. For example, for all
countries, we might use "Zip or postal code" for the postal code field. For
a subset of countries, we might use "region or province" for the
state/region/province field.

Here are my questions about this approach:

* Does anyone know of strong cultural reasons to avoid combining
terms, particularly for audiences in the U.S., U.K., Germany, France,
Canada, or Japan? For example, I've heard that Europeans are annoyed by
forms using "Zip code". Would they also be annoyed by forms using "zip or
postal code?"

* Does anyone know of strong usability reasons to avoid combining
terms? I would think the "or" will slow down users down when they are
entering the information, but that might be an acceptable tradeoff as long
as it doesn't increase errors.

* Is it better to replace the "or" with a "/"? I always thought good
writing should avoid using "/". However a lot of address forms use
"Zip/postal code", so I am wondering if people have gotten used to this.

* Does combing the terms make the field label more difficult to
translate?

* Would it be acceptable to use "Postal code" for a U.S. audience?

I'd appreciate any other advice you might have on this topic.

Thanks,

Cynthia Toryu

--

ctoryu at comcast.net

508-647-9463

Comments

28 Jun 2005 - 11:20pm
Anonymous

Hi Cynthia,
This might be lame, but why don't you consider having "Country" as the
first and selection and change the rest of the lables change appropriatly,
depending on the selcected country name. The idea is to make the UI native
to the users, so this would achieve the goal nicely. Another thought that
comes to mind is, to have only the common address fileds (street, house
number etc.) displayed on the screen initially and as soon as the user
selects the country name, rest of the fields show up with appropriate
lables. If you are working on a website, there are many technologies that
can achieve this result e.g. Ajex, Flash, JavaScript...
Regards,
Vikram Singh
[De-centralizing the central issues]@newMedia
National Institute of Design,
Paldi, Ahmedabad - 7

29 Jun 2005 - 3:51am
J A Sefton
2005

> have only the common address fileds (street, house
> number etc.) displayed on the screen initially and as soon as the user
> selects the country name, rest of the fields show up with appropriate
> lables.

In my experience this can be dangerous - users can be confused and
disorientated by fields suddenly appearing/disappering when other
fields are selected.

This route also assumes that your users are using modern browsers with
javascript turned on (although, having read your target audience, this
is probably quite likely).

As someone from the UK, I have no problem with "Zip or Postal Code",
although I would think it was cleaner and better if it was native to
my locale (ie just "Postal Code").

Would it be possible to have a country selector when users first went
to the site (ie on the homepage)? This could then set a cookie which
could be used to localise the site where required. After all, if
you're write a multinational site, localisation issues probably aren't
going to be constrained to just the form page.

Regards

Adam

On 6/29/05, Vikram's Mail <friendhpk at gmail.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Hi Cynthia,
> This might be lame, but why don't you consider having "Country" as the
> first and selection and change the rest of the lables change appropriatly,
> depending on the selcected country name. The idea is to make the UI native
> to the users, so this would achieve the goal nicely. Another thought that
> comes to mind is, to have only the common address fileds (street, house
> number etc.) displayed on the screen initially and as soon as the user
> selects the country name, rest of the fields show up with appropriate
> lables. If you are working on a website, there are many technologies that
> can achieve this result e.g. Ajex, Flash, JavaScript...
> Regards,
> Vikram Singh
> [De-centralizing the central issues]@newMedia
> National Institute of Design,
> Paldi, Ahmedabad - 7
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

29 Jun 2005 - 4:27am
nuritps
2010

Hi Cynthia,
I went through similar problems as our web application main issue is
searching for companies and we have users in the US and Europe
We have a different interface for these two (although still both in
English), I know the European were complaining (and could not understand)
also when we used POB as opposed to P O Box ....

Using "or" is a possible solution but obviously less usable than using the
native wording... Just think of the time to read the labels and the
difficulty to scan them (which is one of the reasons why we align labels to
the left, to enable scanning)...
About translation... As much as I understood from our German translator zip
code and postal code will be translated the same so you won't have to use
the combined option. If you plan on bundle translation or any other form of
semi automatic translation, it will be a problem...

Don't know if it is relevant for you, but there are also differences in the
address structure (in the UK you may have a name for a building instead a
number) and in France there is also the Cedex/Cedes fields...

Good luck,
Nurit

: : nurit.peres at ams-sys.com
: : http://www.ams-sys.com

Here are my questions about this approach:

* Does anyone know of strong cultural reasons to avoid combining
terms, particularly for audiences in the U.S., U.K., Germany, France,
Canada, or Japan? For example, I've heard that Europeans are annoyed by
forms using "Zip code". Would they also be annoyed by forms using "zip or
postal code?"

* Does anyone know of strong usability reasons to avoid combining
terms? I would think the "or" will slow down users down when they are
entering the information, but that might be an acceptable tradeoff as long
as it doesn't increase errors.

* Is it better to replace the "or" with a "/"? I always thought good
writing should avoid using "/". However a lot of address forms use
"Zip/postal code", so I am wondering if people have gotten used to this.

* Does combing the terms make the field label more difficult to
translate?

* Would it be acceptable to use "Postal code" for a U.S. audience?

I'd appreciate any other advice you might have on this topic.

Thanks,

Cynthia Toryu

--

ctoryu at comcast.net

508-647-9463

_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org (Un)Subscription Options ...
http://discuss.ixdg.org/ Announcements List .........
http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org Home .......................
http://ixdg.org/

29 Jun 2005 - 7:11am
Peter Boersma
2003

Cynthia Toryu said:
> I'm looking for advice on localizing address fields.

Are you sure?
If the functionality calls for use of the fields in a complex way (e.g. find
restaurants close to me) I can see why you want a formalized structure for
the addresses.
If, on the other hand, addresses are entered to allow for printing on an
label of a box (e.g. in any e-commerce setting), why don't you trust the
users to enter the address in either a series of unlabelled(*) fields or
even one big textfield?

Peter

(*) For accessibility purposes, you may want to choose to use several
similar labels for the address lines, e.g. Address line 1/2/3/4/5.

--
Peter Boersma | Consultant User Experience | UserIntelligence
mailto:peter at peterboersma.com | http://www.peterboersma.com

29 Jun 2005 - 8:19am
Jerry John
2004

so you need to come from the technology point of view too - your focus is on
a person that is not too computer savvy, if he is not sure of what he
wants - then could i interest you in using a Wizard for this - i did have a
related problem and so i used a wizard to help me identify the information
by asking him a crisp set of questions; you could first ask him the country
information like Vikram suggested and when he click next or what ever you
wanna call it; load the relevant information;

this approach would take care of Sefton's problem which i totally agree ...

- jerry

PS: why use a postal location search anyways ;)

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Vikram's Mail
Sent: Wednesday, June 29, 2005 9:50 AM
To: discuss at ixdg.org
Subject: Re: [ID Discuss] Localizing address fields

29 Jun 2005 - 9:14am
Tom George
2004

I think this is one place where technology dictates rather than serves.
We tend to assume that it's convenient or possible for the user to
split the address up into (arbitrary) parts that are necessary for the
software. And then click all over our drop downs and lists and wait for
screens to refresh to enter what would otherwise have come off their
fingertips in about 15 seconds.

If your talking International, addresses seem to resist formal
structure, and even North Americans have any number of styles for
writing addresses. Where to put the unit/suite #, mail stop, name of
the building. Some people abbreviate, some don't. Sometimes you know
the postal code/zip. Sometimes you don't. Sometimes people use their
metropolitan area name instead of the municipality name (vanity
reasons).

I think the best thing would be to give someone a big white space and
tell them to write the complete address (as best they know it). Let
your application try and parse the address (non-trivial, I realize) and
then, if there are ambiguities, prompt them to clarify.

I wonder if the various address cleansing service providers offer any
web services that could make this feasible and affordable for a finite
project?

Didn't Outlook do something like this? Heck, there are card scanners
out there that do a pretty good job off getting a complete address
using OCR.

-Tom

29 Jun 2005 - 10:54am
Juan Lanus
2005

Cynthia,

If you are still unsure about taking Peter and Tom's suggestion, take
a look into this:
http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/PostalAddress.html
It's a quite complete specification for postal addresses. I think it
will help you decide.

It was mentioned that your users are not "technically savvy."
But can they fill a label to mail a letter or a package home? I'm sure
they are. Now, hoy will you print that lebel after the user filled it
with chinese, cirillyc or kanji characters? Your system must be aware
of this issue.

Suerte!
--
Juan Lanus
TECNOSOL
Argentina

29 Jun 2005 - 11:21am
nuritps
2010

I agree that the formal structure is a problem but as you said parsing the
full address is not trivial either, not at all.

We have some experience with data cleansing companies and we are also doing
some of it our self. Most of these companies aim at "real" mailing, so it
may help using it if your objectives are similar (ours are not). Anyway even
the more established companies in the field do not succeed if the data
entered is very messy, just as an example , if there is a spelling mistake
in the city name then it will not recognize the postal code, or if a company
is located in an industrial zone with no street name then parsing is
problematic...

I'm afraid there is no easy solution :)

Nurit

----------------------------
I think this is one place where technology dictates rather than serves.
We tend to assume that it's convenient or possible for the user to split the
address up into (arbitrary) parts that are necessary for the software. And
then click all over our drop downs and lists and wait for screens to refresh
to enter what would otherwise have come off their fingertips in about 15
seconds.

If your talking International, addresses seem to resist formal structure,
and even North Americans have any number of styles for writing addresses.
Where to put the unit/suite #, mail stop, name of the building. Some people
abbreviate, some don't. Sometimes you know the postal code/zip. Sometimes
you don't. Sometimes people use their metropolitan area name instead of the
municipality name (vanity reasons).

I think the best thing would be to give someone a big white space and tell
them to write the complete address (as best they know it). Let your
application try and parse the address (non-trivial, I realize) and then, if
there are ambiguities, prompt them to clarify.

I wonder if the various address cleansing service providers offer any web
services that could make this feasible and affordable for a finite project?

Didn't Outlook do something like this? Heck, there are card scanners out
there that do a pretty good job off getting a complete address using OCR.

-Tom

_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org (Un)Subscription Options ...
http://discuss.ixdg.org/ Announcements List .........
http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org Home .......................
http://ixdg.org/

29 Jun 2005 - 5:24pm
Ted Boren
2005

Everybody else has brought up great things to think about, especially the
comments on context of use. If the system really has to parse the address out,
then freeform text won't work... but if not, then why not use freeform text? If
parsing is needed and you decide to localize forms, be aware that not only the
labels but the order of fields is different for some countries.

In terms of actual data, in 4 years of usability testing Microsoft mapping
software & websites, I never had any American users misunderstand or be
frustrated by "postal code" or "post code." It should work fine for an American
audience.

Good luck,

Ted Boren

>>> "Cynthia Toryu" <ctoryu at comcast.net> 6/28/2005 8:22:53 PM >>>
Hi there,

I'm looking for advice on localizing address fields. I'm designing a UI that
could potentially be used by folks in a large number of countries. The
target user profile is a small business owner who uses a computer to get her
job done, but is not technically savvy.

Different countries use different terms to represent similar information.
For example, the U.S. uses "zip code", but all other countries seem to use
"postal code." Similarly, the U.S. uses "state" where other countries use
"province," "region," or "prefecture."

To reduce development effort, we're thinking of using "or" to combine
different country's terms in the field labels. For example, for all
countries, we might use "Zip or postal code" for the postal code field. For
a subset of countries, we might use "region or province" for the
state/region/province field.

Here are my questions about this approach:

*Does anyone know of strong cultural reasons to avoid combining
terms, particularly for audiences in the U.S., U.K., Germany, France,
Canada, or Japan? For example, I've heard that Europeans are annoyed by
forms using "Zip code". Would they also be annoyed by forms using "zip or
postal code?"

*Does anyone know of strong usability reasons to avoid combining
terms? I would think the "or" will slow down users down when they are
entering the information, but that might be an acceptable tradeoff as long
as it doesn't increase errors.

*Is it better to replace the "or" with a "/"? I always thought good
writing should avoid using "/". However a lot of address forms use
"Zip/postal code", so I am wondering if people have gotten used to this.

*Does combing the terms make the field label more difficult to
translate?

*Would it be acceptable to use "Postal code" for a U.S. audience?

I'd appreciate any other advice you might have on this topic.

Thanks,

Cynthia Toryu

--

ctoryu at comcast.net

508-647-9463

------------------------------------------------------------------------------
This message may contain confidential information, and is
intended only for the use of the individual(s) to whom it
is addressed.
------------------------------------------------------------------------------

Syndicate content Get the feed