Issue |
Article |
Vol.28 No.1, January 1996 |
Article |
Issue |
The first part of this article is a wander through some of the issues in internationalization, nationalization, and customization of user interfaces. We will begin by making some of the base terminology clear, because user interface, ease of use, and usability discussions often get easily lost in terminology confusion. We have borrowed and modified some of the ideas and terminology here from Russo and Boor's INTERCHI '93 paper ("How fluent is your interface? Designing for international users"). After the article, we present some observations on the first ACM/IFIP/ASD symposium on designing interactive systems in a report provided by Alistair Sutcliff, secretary for IFIP Working Group 13.2.
For a company interested in developing systems that can be marketed outside in many countries, questions of "internationalization" generally refer to a process for "making possible" the adaptation of a product to many different national groups. "Nationalization" is the process of actually adapting a product developed for one national group (e.g., for the U.S.) to make it acceptable for another national group (e.g., for France). The term "product" here can refer to hardware (e.g., display screen, keyboard, mouse), software (e.g., word processor, operating system) or combination of the two without changing the basic meaning of internationalization. Internationalization can be thought of as a process for enabling different national versions of a product. Nationalization would then be seen as a complimentary process of adapting for a specific national context of use.
This can be seen as a subset of "customization." Customization in an environment in which some product already exists refers to a process for adaptation of a product developed for one group (e.g., Hertz) to make it acceptable for another group (e.g., Avis). For both customization and nationalization the goal of the process is to create a product to meet the requirements of particular users.
Is there a name for the process that would "enable customization" (in a sense similar to saying that internationalization is the process aimed at enabling nationalization)? While we have tended to focus some attention on issues specific to nationalization and many companies have some type of nationalization specialists, we do not have a specific name for "making a product customizable." If a product is intended for many groups, the requirements of the many groups become part of a single design effort. In this case, meeting requirements is just called "design." It is similarly true of taking an application from one domain and customizing it for another. The process is just called "designing to meet requirements." We don't have a name for it, but clearly the general analog of internationalization is an important process (e.g., by what process do we go from a single clinical information system to one that can be adapted to multiple health care institutions).
With this in mind (that "customization" is the more general adaptation process, that "nationalization" refers to customization for a specific set of "national" concerns, and that "internationalization" is a process to enable the possibility of nationalization), the questions are:
First, what are "national" concerns for computer systems? In the past, this adaptation has been seen as primarily as an issue of national language adaptation. Such national requirements are easily seen and understood by all. National language differences are important enough and well enough understood to be called for in design process documentation -- internationalization, at a minimum means "design with attention to different national languages." For many products this is accomplished through use of "international symbols" instead of words in the product interface (e.g., on/off switches). For screen layouts this can mean allowing extra space for prompts or using interface tools that enable easy rearrangement of dialog elements. There are books (e.g., "Global Software," Taylor, 1992) which address such issues.
More broadly though, the intention is to be able to adapt the product to the intended "culture" -- that is to the "behavior typical of the group" (from Webster's Collegiate) -- not just to a different language. The language one speaks is certainly one of these behaviors, but there are many others behaviors as well. The way people respond to and use space (e.g., in conversational distances, in office layout), treat time (e.g., in assumptions about what an appointment for 2pm or dinner at 8 actually means), and interpret signs in their environment are all a part of culture. Furthermore, treating nations as composed of a single culture is a dangerous over simplification for the purpose of internationalization.
As long as products are viewed as "culturally neutral" (i.e., their use is in a domain that is not affected by culture), viewing internationalization as just enabling national language translation is a safe simplifying assumption. However, the more a product goes outside of neutrality to touch on the work or general culture, the more awareness of the cultural impact becomes an internationalization issue. It is a simple fact that computer products, the operation of which could once be viewed as isolated from culture, are more and more integrated with the work, educational, and daily lives of all. While we could once ask a few to adapt to a product, we cannot so easily ask an entire culture to adapt a work or lifestyle to a system. To be successful, products must be able to adapt to cultures (a process generally easier than asking whole work cultures to adapt).
What process can we use to enable cultural adaptation? There are some areas beyond national language where guidelines are beginning to appear (e.g., international standards for icons, use of color), but for the most part we must simply be alert to the product impact by working with and listening to the users. This doesn't mean that products can't introduce change -- people will change if they can see the benefit to doing so.
A secondary concern for internationalization has generally been meeting requirements posed by national (or international) standards. Such standards (e.g., International Standards Organization (ISO) standards or German National (DIN) standards), can have substantial impact. If a product is not developed with knowledge of such national requirements, it can become financially impractical to adapt it. In general, requirements posed by national or international standards have had a greater impact on hardware products (e.g., for a period of time US companies were faced with not being able to market PC's in Germany because German standards called for keyboards with certain ergonomic features that could not be accommodated within the original design). This might change however as ISO standards for software elements of human-machine dialog are completed in the next year.
In summary, the internationalization issues that we should enable adaptation for include language, culture, and standards. We understand language issues fairly well from past product experience. Standards are evolving, and we need to participate in and understand their directions. The general issue of enabling cultural adaptation in systems is not well understood, and will require expanding our notion of internationalization.
Finally, while enabling nationalization is important, we should keep in mind that it is best viewed as a subset of enabling customization. If we expand the notion of internationalization from enabling national language based adaptation to culture based adaptation, we would seem to be encompassing a process which "enabled customization" in general and not just on a national level. Differences in tools between "work cultures" are generally greater than differences in tools between "national cultures." Efficient tools for activities (such as carpentry, word processing, or surgery) spread across national boundaries more easily than many aspects of culture do. At the heart of developing products that can be international, is first developing products that fit the task requirements. For most of the contexts enabling task related customization is simply a much more difficult and encompassing than enabling national customization, and should be viewed as the process that will drive effective internationalization.
Issue |
Article |
Vol.28 No.1, January 1996 |
Article |
Issue |