useit.com Alertbox Aug. 1996 International use

Jakob Nielsen's Alertbox for August 1996:

International Web Usability

The unprecedented international exposure afforded by the Web increases the designer's responsibility for ensuring international usability. International use is not a new phenomenon: most computer companies have half their sales overseas, and several books have been published with general advice for making user interfaces more international. Let me just mention the latest: Elisa del Galdo and I had our new book, International User Interfaces, published by John Wiley & Sons last month.

Most of the guidelines remain the same: don't use icons that give your users the finger (or the foot, or other gestures that are offensive in their culture), don't use visual puns (e.g., a picture of a dining table as the icon for a table of numbers), don't use baseball metaphors (except, obviously, at baseball sites), translate fully if you do translate, and so on. This column looks at some of the issues that are specific to the Web.

A major problem is the fact that Web sites attract many international customers. We should all have this problem,you may say, but some companies are not interested in overseas business. Make it clear up front if you are only interested in serving a local market to avoid wasting both parties' time. Also, many companies have significantly different product offerings across countries, and it can be quite confusing for a customer to access, for example, Mercedes-Benz' main site only to discover that some of the models are not for sale outside Germany. Always make it clear if different models, prices, or procedures apply in different countries.

The Web and the Internet allow real-time interactions, with celebrity chat sessions and with Olympic or World Cup results posted as the events happen. In announcing any real time event, you cannot simply say that it will happen from 2:30-4:00. First, is it 2:30 in the morning or the afternoon, and, second, what does that translate to in my own time zone anyway? It may be obvious to you that nobody would put on an event at 2:30 in the morning, but if that happens to correspond to 11:30 AM in my country, I might not think so. Any times listed on a web page should always at a minimum make it clear whether they are given in the AM/PM system or the 24-hour system (and if AM/PM, then these suffixes should be given) and which time zone they refer to. Time zone abbreviations (e.g, EDT) are not universally understood, so supplement them with an indication of the difference to GMT. Many users don't understand GMT either, so optimal usability would involve translating the time into local times in a few major locations (e.g., "the press conference starts 1:00 PM in New York (GMT -5), corresponding to 19:00 in Paris and 3:00 the next day in Tokyo").

International Usability Testing

It is possible to test Web designs internationally without ever leaving home. Since users can access the Web from everywhere, they can access your site without you having to go to their country to set up the test. One option is to place telephone calls to the users and ask them to think aloud as they navigate the site. Assuming that you can identify users in other countries who speak your language well enough for a telephone interview, this is a very easy way to conduct international testing. The two downsides are the need to get up early in the morning and the difficulty in following the user's navigation from a purely verbal description.

A good alternative is to have staff from your local offices in various countries conduct the test themselves, even though they are not user interface specialists. We have done so at Sun with some success, and you can see the instructions I gave to the local offices for further information about how this can be done.

Draft of "user cafe" for the Internet Access PlusPack subsite.
Shown at 80 percent of full size.

The best choice, though, is to travel to the foreign country yourself. Of course, this is expensive, but again the nature of the Web comes to the rescue. It is possible to conduct informal tests during trips that are planned for other purposes since you can pull up a Web page any place you can get to a computer. For example, I was at a meeting in Sweden recently while the rest of the team continued working on a new subsite design back in California. Not only could I email back comments on the design as it progressed, but I also took the opportunity to run it by a few locals. The figure shows the draft design I tested. One of the results was that people didn't understand the difference between the Information button and the Documentation button. As shown by the example, international usability testing often reveals problems that could well exist for domestic users also. Other problems related to recognizing the espresso machine, though most people understood the general cafe concept which had been one of my main worries.

Language Choice

To choose between a small number of languages, I recommend listing the name of each language as a word, using each language's own name for itself. For example: English - Français. Lists of more than 7 foreign words are hard to scan, so for lists of between 8 and 21 languages, I recommend using visual symbols to supplement the names. For lists of 22 languages or more, scanning is hopeless, and the only solution is a long alphabetical list (in which case non-Latin languages should be listed twice: once in Latin characters in the proper alphabetical order and once in the true character set at the end of the list). The best visual symbol for a language is probably a flag. Icons playing on national stereotypes are possible and can be fun, but risk being offensive (not all Americans wear cowboy hats).

If language choice is supported by a site, I recommend providing a link to the choice on every single page since users often go directly to pages from search services or bookmarks without passing through the home page. Some sites put up a language choice page before the user can reach the home page, but I recommend against this if it is possible to determine a default language that will be used by a very large proportion of the users (the Louvre Museum in Paris is a good example: fair enough to start in French). Clicks and download time can be saved by going straight to a page for the main language as long as the home page has a very prominent (and internationally understood) entry for language change. Also, the pages for the various languages should have their own URLs so that users can bookmark the proper entry point and bypass language choice if they visit again.

Multi-Lingual Search

Unfortunately, it is often not possible to translate all documents, so many sites require searches of several languages if the user needs complete coverage of the available information. Currently, multi-lingual search requires the user to manually enter synonyms of the desired search terms in all the requested languages. This is obviously an unpleasant task, and users often forget to search for translated terms, even if they understand several languages. It would be better to have the computer automatically perform multi-lingual searches by understanding the meaning of the search terms in several languages. Doing so is easier than the general problem of natural language translation (for example, the term "rock" would not normally refer to music if used on a geology site) and there are some research systems that have performed reasonably well on multi-lingual searches.

Printing

See Also:

• Next month: The rise of the sub-site.
• Use of (^_^) instead of :-) as a Japanese emoticon; access requires registration.
• List of other Alertbox columns