They don't call it the World Wide Web for nothing. A single click can take you to a site on another continent and a business can attract customers from hundreds of countries without ever going to a Frankfurt trade show where they book you into a hotel two hours down the autobahn.
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
Because of the myriad of issues in international usability, I recommend doing international usability testing with users from a few countries in different parts of the world. No guidelines yet published are sufficiently complete to guarantee perfect international usability, so an empirical reality check is always preferred. Luckily, the Web makes international usability testing relatively easy.
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.
 |
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
In many ways, the ideal international user interface is one that is available in the user's preferred language. Eventually, language choice will be handled by content negotiation between the user's client and your server so that the user will only need to specify a list of preferred languages once and for all as a client setting. At the moment, content negotiation is not sufficiently widely used to be a reliable solution, so many websites use manual options for language selection.
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
A special problem is the search of multi-lingual information spaces. If all of the information has been replicated in every language, then there is no need to search more than one language. In this case, the search interface should know of the user's preferred language and only display hits in that language.
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
For rich or large hyperspaces, I recommend providing a special version that can be downloaded and printed as a single document. Any file that is intended for printing must be able to accommodate the two most common page formats: A4 and 8.5x11 (U.S. Letter). To do so, the width of the page must fit on an A4 sheet and the height of the page must fit on an 8.5x11 sheet, since A4 is the narrowest format and 8.5x11 is the shortest format. It is recommended to leave a margin of at least half an inch (13 mm) for all four sides of the page to ensure that it will print on all printers and to facilitate photocopying. With half-inch margins, the printable area is 7 1/4 inches (18.5 cm) wide by 10 inches (25.4 cm) tall; with one-inch margins (preferred), the printable area would be 6 1/4 inches (15.9 cm) by 9 inches (22.9 cm).
Design Guidelines
See also my 61 design guidelines for supporting international users and the 230 tips and tricks for a better usability test (of which 14 tips relate specifically to international testing — but the remaining tips will help improve such tests as well).
See Also: Use of (^_^) instead of :-) as a Japanese emoticon.
Share this article: