Same topic in earlier issue
Issue
Previous article
Article
SIGCHI Bulletin
Vol.28 No.3, July 1996
Next article
Article
Same topic in later issue
Issue

World-Wide CHI: Cultural User Interfaces, A Silver Lining in Cultural Diversity

Alvin Yeo

Introduction

Many software applications marketed outside the country of origin are internationalised and/or localised. In this article, I propose a strategy to localise the software by creating a Cultural User Interface (CUI) for each of the target cultures. A CUI is a user interface that is intuitive to a particular culture. The CUI takes advantage of the shared or common knowledge of a culture which could be defined by country boundaries, language, cultural conventions, race, shared activities or workplace. An application that is CUI-enabled allows the use of many different CUIs. These different CUIs are developed collaboratively with the target cultures, thus problems associated with localisation such as misinterpretation of elements in the CUIs, are unlikely to occur. A CUI can be used not only for one application but for a range of applications.

Most software developers have accepted the fact that it is worthwhile economically to internationalise their software. This trend is evident in the growing number of companies that provide internationalisation and translation services for software marketed outside the United States (US). Also, many resources are now available on internationalisation and localisation of software. These resources include books (Kano (1995), Fernandes (1995), O'Donnell (1994), Uren et al. (1993), Apple (1992b), Digital (1992), Madell et al. (1992), Taylor (1992), Nielsen, (1990)), mailing lists (INSOFT-L, intercultural.CHI), newsgroups (comp.software.international, comp.std.internat) and FAQs (ISO 8859-1 National Character Set FAQ, Programming for Internationalization FAQ, Globalizing Applications for Windows FAQ). Some examples of current articles written on these topics include Yeo and Barbour (1996), Karat and Karat (1996), Belge (1995), Chris Miller (1994), Hall (1994), and Nakakoji (1994). CHI Workshops have also been conducted (Kellogg and Thomas, 1993). Presently, there is an even further need for internationalised software that allows the use of non-Romanised characters given the popularity of WWW (see http://www.w3.org/pub/WWW/International/ ).

Current internationalisation and localisation of software has mainly focused on modifications of the language/character sets, collating sequence, the date, time, number and currency formats. As pointed out by Russo and Boor (1993) and Marcus (1993) there are many aspects that need to be addressed. One of these aspects is making provisions for the different perceptions of the diverse cultures.

In this article, I discuss the differences in perception of user interface elements across cultures. A proposal and justification for many individually unique Cultural User Interfaces (CUIs) will be put forward. Lastly, technical implications of this proposal and a strategy to develop CUIs will be discussed.

Different Perceptions

There are many factors that need to be addressed before a software package can be internationalised or localised. I have categorised these factors into overt and covert factors.

The overt factors are tangible, straight forward and publicly observable elements. The overt factors include date, calendars, weekends, day turnovers, time, telephone number and address formats, character sets, collating order sequence, reading and writing direction, punctuation, translation, units of measures and currency. Covert factors deal with the elements that are intangible and depend on culture or "special knowledge". Graphics/visuals, colours, functionality, sound, metaphors and mental models are covert factors. Much of the literature on internationalising software has advised caution in addressing covert factors such as using metaphors and graphics. This advice should be heeded to avoid misinterpretation of the meaning intended by the developers or inadvertently offending the target culture.

An example of misinterpretation is the use of the "trash can" icon in the Macintosh user interface. Thais might not recognise the American "trash can", because, in Thailand the "trash can" is actually a wicker basket (Sukaviriya and Moran, 1990). Some visuals are recognisable in another culture but they convey a totally different meaning. In the United States, the owl is a symbol of knowledge but in Central America, the owl is a symbol of witchcraft and black magic (Apple, 1992a). A black cat is considered bad luck in the US but good luck in the UK (del Galdo,1990).

One culture may find certain covert elements innocuous but another may find the same elements offensive. In most English-speaking countries, images of the ring or OK hand gesture may be understandable, but in France the same gesture means "zero", "nothing" or "worthless". In some Mediterranean countries, the gesture implies a man is a homosexual (Pease, 1981). Covert factors will only work if the message intended in those covert factors is comprehended in the target culture. Before any software with covert factors are used, the software developers need to ensure the correct information is passed by validating these factors with the users in the target cultures.

Cultures

In the examples given above, cultures appear to be associated with national boundaries. In this article, I take the following definition. Culture is defined as behaviour typical of a group or class (of people) (Webster,1995). Culture is conceptualised as a "system of meaning that underlies routine and behaviour in everyday working life" (Bødker and Pedersen, 1991). "Culture includes race and ethnicity as well as other variables and is manifested in customary behaviours, assumptions and values, patterns of thinking and communicative style" (Borgman,1992).

Why do cultures perceive things differently? The influence of childhood, upbringing, education, social aspects affect the way we interact with the environment. Each particular culture would share similar attitudes and behaviours, as well as think and act similarly in certain situations. Cultures may be defined by country boundaries, language or cultural conventions such as race or ethnic groups. Each culture has its own attributes and possesses certain "behaviour" typical of that culture. Cultures defined by political boundaries are easy to depict. An illustration of cultures within a country could be Switzerland where French, German, Italian, and Rhaeto-Romance are spoken. Thus, there would be a French-speaking, German-speaking, Italian-speaking and Rhaeto-Romance-speaking culture. In New Zealand, the cultures may be defined by ethnic groups, for example the Maoris and New Zealanders of European descent. A culture grouped according to cultural conventions may be the workplace. The workers in a company may belong to a culture as they share a common bond, that is, the culture (and its associated behaviours) that resides in their company.

Some of these cultural boundaries may not be very clear, as illustrated by the example in Bødker and Pedersen (1991). In the lobby of a company, a pump-valve sits on a pedestal behind glass, like a precious ornament. It seems that the company relied on the supply of the pump-valve from a sole supplier. Although the supplier was trustworthy and reliable, the company was uneasy with this dependence on that one supplier. The exhibited artefact was the first pump-valve from the company's new supplier. To the members of the workplace, the artefact symbolised "liberation from captivity". With the insight of the story and meaning behind the artefact, it became clear that members of the culture value "autonomy and independence" (Bødker and Pedersen, 1991).

A newcomer to the company may have assumed that the pump-valve was important because it may have been the first component manufactured in the company. The metaphoric significance of the pump had to be learned. Cultures are not mutually exclusive. A person may belong to a number of cultures (e.g., a Muslim who plays soccer would belong to an Islamic culture and a soccer-playing culture). Given that a person belongs to certain cultures, we would be able to predict with high accuracy certain things that the person knows. In the case of the Muslim soccer player, we would expect the person to know where Mecca is and what a soccer ball looks like. This knowledge of particular cultures cannot be assumed. I will present a strategy for acquiring information of the target culture in a later section.

Covert symbols usually have the same meaning to members of a particular culture. Thus, communication within these cultures using artefacts and symbols would be possible. There is less likelihood of misinterpretation of covert factors in a culture. This shared "meaning" among members of a culture forms the basis of a Cultural User Interface (CUI). In the next section, I put forward a proposal for the CUI and how a CUI for a culture could be developed.

Proposal

In this section, I will discuss justification for the existence of a CUI and also look at a strategy for implementing the CUI. Technical implications will also be discussed.

Software developers who intend to internationalise or localise their software will see cultural diversity of their target markets as an obstacle. We, on the other hand, see cultural diversity as an asset. Each culture has its own beliefs, behaviours and perceptions. Members of the same culture are likely to have the same "knowledge" of certain things, and would think and act similarly in certain situations. We propose that a Cultural User Interface (CUI) be created for each culture whereby we take advantage of the "knowledge" of a target culture. The cultures may be defined by, but not confined to, country boundaries, language, cultural conventions such as race, shared activities or workplace. These CUIs should also be developed in collaboration with members of the target culture to ensure that the CUIs are acceptable to the target community. These CUIs will cover all the covert and overt elements of the user interface.

To illustrate the notion of CUI, I will use CUIs from three cultures, the culture of a New Zealander, a Malaysian, and an American. We have a user interface through which the user is to select one of the hobbies he or she is most interested in. In this scenario, the CUIs store the text and icons for various hobbies. The text for the Malaysian (MA) culture will be in Malay, the text for the New Zealand (NZ) culture will be in International English and the US culture, US English. In the lists below, are items that can be used to represent the various hobbies. (A Malaysian, a New Zealander and an American were asked to suggest the items below).

Sports Equipment

(MA) Badminton racquets, shuttlecocks, soccer balls, table-tennis bats and balls, hockey sticks
(NZ) Cricket balls, rugby balls, netballs, yachts
(US) American footballs and helmets, baseball bats, basketballs

Gardening

(MA) Flowers like hibiscus, bougainvillea or roses; garden tools like hoe or trowel
(NZ) Flowers like roses or tulips; garden tools like push-hoes, lawnmowers, shovel or leaf rake
(US) Flowers like roses or garden tools like trowel, pruning shears or lawnmowers

Numismatics

(MA) Coins such as twenty or fifty sen coins depicting the Malaysian Parliament House
(NZ) Coins such as twenty cent coins depicting a kiwi or Queen Elizabeth II
(US) Coins such as pennies with Abraham Lincoln or quarters with George Washington

Stamp Collecting

(MA) Stamps with Malaysian state crests or the label "Malaysia"
(NZ) Stamps with a kiwi or the label "New Zealand"
(US) Stamps with the American flag and the label "USA"

CUIs can be further developed to include sub-cultures. The CUI may be for a female, who is a Catholic from New Zealand and plays netball. Given this profile, the commands such as abort, or kill may be avoided as this user may find the commands offensive. She would also know what a netball is. There is also a high probability that she would be able to associate an icon of logos of McDonalds, Pizza Hut, KFC, Burger King with something related to fast food.

The number of sub-cultures that a person can belong to is large. However, the selection of cultures would depend on the user interface elements that is to be developed. It is just a matter of choosing which cultures would be useful in communicating the required information to the target culture.

Technical Considerations

Before CUIs can be used, an application must be separated into a functionality component and a user interface component. Different CUIs can then be developed, and each of these different CUIs can be used with the same functionality component. An analogy we could use would be a bottle (functionality component) and its screw bottle cap (user interface component). You can fit many different bottle caps into the bottle just as you can fit many CUIs to the same application. The bottle has to be created and then all the different bottle caps (e.g. made of different materials) need to be created to fit that bottle. Likewise, many CUIs have to be created to fit the functionality component. In most applications, the user interface is indistinguishable from the functionality of the application. However, research has shown that the separation of the user interface from the application is possible. A recent example is provided by Klein (1995) whose Alpha UIMS allows an application to be separated into three components encompassing the application, display technology and user interface.

Another technique is to enable the application to accept different CUIs. The application would be modified to contain tokens. Each token corresponds to a unique interface element of the application, which may include menu item text, error messages or icons. A file contains all the localised tokens for a particular culture. Thus, when the application is running, different files (different CUIs) may be used to provide the user interface.

To illustrate this technique, let's say we have an interface of text messages M1, M2 and icon I1, I2. A file "Maori.cui" contains the Maori equivalent of messages M1, M2, and icon I1, I2. We can have many files that contains the messages and icons for different cultures. Whenever the application runs, the corresponding messages and icons (M1, M2, I1, I2) are shown. This illustration is an oversimplified scenario. The different files may be developed to contain all the covert and overt factors. There may be a component which enables bi-directional writing, or the input or displays of non-Romanised characters. There should be mechanisms to allow the selection of certain interface elements, for example an icon. Not everyone in the culture may be able to relate to the icons selected for the CUI. There is much research to be conducted in the techniques described above. Further implications of these paradigms may include rethinking of the methods we use to develop software.

Strategy for Developing a CUI

Let's assume that the application has been enabled to accept the different CUIs. The next step entails an examination of ways to develop the CUIs. The CUIs must be able to accommodate all the overt and covert factors described earlier.

The first step would be to identify all the elements (which include all the overt and covert elements of the user interface) that need to be localised to a particular culture. Next, the target culture must also be identified as well the level of breakdown of cultures. The level of breakdown determines where we set the cultural boundaries, for example at a national level (defined by countries), at the language and national level (e.g., English-speaking Malaysians) or at an even deeper level (e.g., a New Zealander of Maori descent who is familiar with Netscape icons).

Experts of the target culture need to be selected. Experts of the target culture will need to actively participate to decide what sort of elements will go into the CUI. User interface designers work collaboratively with the group of "experts" of that target culture. These experts are preferably denizen of that culture, who are adept in their language, and have had experience with computers. Experts with these attributes are needed as they may be required to translate certain concepts into their culture. Two or three experts need to be consulted as the expert chosen may be "contaminated" with different cultures. Nakakoji (1994) warns that some people (e.g., a Japanese who has lived in the US), may be considered to be from another culture. The designers will need to work hand in hand with the target community as what the designers interpret may be "against" the designer's own beliefs as opposed to the target cultures'. A method to study workplace cultures is suggested in Bødker and Pedersen (1991). Finally, usability tests need to be conducted on the CUIs, evaluated and modified (if required) until the target culture is satisfied with the CUI. From the outline above, we can see that considerable amount of effort and cost may be required to develop effective CUIs. However, we should not only look from the financial perspective as there are other beneficial consequences of developing CUIs.

Other Benefits of a CUI

From a social perspective, the development of CUIs can serve as a medium to bring nations together by increasing communication between the countries involved. For example, US software developers intending to pursue Chinese-speaking markets would necessitate the co-operation of the countries concerned. Software, such as CAL, requires large investments of time and talent. With the CUI-enabled software, there would be increased world-wide availability of state-of-the-art software as software companies increased the distribution of software, thus meeting the needs of a wider range of people. Many projects fail due to lack of acceptance by target cultures. With CUIs, such projects would also stand a better chance of success. Furthermore, communities less adept in software technology may be exposed to state of the art software; thus, the development of CUIs can also be an effective mechanism for the transfer of technology.

Griffiths et al. (1994) reports that people who can interact with computers in their own language, learn and progress faster. For example, Bulgarian children only painted and drew but did not write in software in English. However, by providing software in their mother- tongue, the children attempted to write creatively and explore all potential of the software (Griffiths et al., 1994).

Many people identify strongly with the culture they were brought up with. A particular community may feel "personally rejected and second rate if their language is not accepted into the magic circle of technology" (Griffiths et al., 1994). These communities may never develop the confidence to adopt information technology (IT). As such, significant contributions where IT is used would not materialise if these people cannot use them (Griffiths et al., 1994).

Furthermore, by focusing on "indigenous" cultures, we are indirectly preserving some of the diverse elements of culture. By doing so, we are also preserving "a wider variety of perspectives, potential insights and solutions to the world's problems" (Griffiths et al., 1994). This argument is also supported by a study carried out by the American Management Association (AMA) that "heterogeneous work groups create solutions to work and business problems that are more innovative and more effective than those developed by homogeneous groups" (HR Focus, 1993).

Glimpse of the CUI's Future ...

Let's say we have a software package called "Unicorn", and we are visiting Russia. Our fellow Russian colleague also has the "Unicorn" software. To use "Unicorn", we would just substitute our Russian colleague's CUI with our own CUI.

The CUI could be further developed into a personal user interface (PUI) based on our profiles which would incorporate our bio-data into the PUI. Bio-data such as gender, religion, educational background, hobbies, country lived in, marriage status, race, occupation, television programmes watched would be added. Depending on the contexts, the PUI will be able to select both the overt and covert elements of the user interface to allow the most effective human-computer interaction.

Acknowledgment

Many thanks to Dr. Robert Barbour for his comments on the article.

References

Apple Computer. 1992a.
Human Computer Interface Guidelines. Addison Wesley.
Apple Computer. 1992b.
Guide to Macintosh Software Localization. Addison Wesley.
Belge M. 1995.
The Next Step in Software Internationalization. interactions. ACM Publishers. Vol 2. No 1. p21-25.
Bødker K, Pedersen J S. 1991.
Workplace Cultures: Looking at Artifacts, Symbols and Practices. In Greenbaum J, Kyng M (Ed.). Design at Work: Cooperative Design of Computer Systems. Lawrence Erlbaum Associates. p121-136.
Borgman C L. 1992.
Cultural Diversity in Interface Design. SIGCHI Bulletin. Vol. 24. No. 4. p31.
Chris Miller L. 1994.
Transborder Tips and Traps. BYTE. Vol 19. No 6. p93-102.
del Gardo E. 1990.
Internationalization and Translation: Some Guidelines for the Design on Human Computer Interfaces. In Jakob Nielsen (Ed.) Designing User Interfaces for International Use. Elsevier, New York. p1-10.
Digital Equipment Corporation. 1992.
Digital Guide to Developing International Software. Digital Press.
Fernandes T. 1995.
Global Interface Design, Academic Press.
Griffiths D, Heppell S, Millwood R, Mladenova G. 1994.
Translating Software: What It Means and What It Costs for Small Cultures and Large Cultures. Computers in Education. Vol. 22. No. 1/2. P9-17.
Hall W S. 1994.
Internationalization in Windows NT, Part 1: Programming with Unicode. Microsoft Systems Journal. June 1994. p57-71.
HR Focus. 1993.
More Companies Are Drawing Strength from Diversity. HR Focus. Vol. 70. No 6. p2.
Kano N. 1995.
Developing International Software for Windows 95 and Windows NT. Microsoft Press.
Karat C, Karat J. 1996.
World-wide CHI: Perspectives on Design and Internationalization. SIGCHI Bulletin. Vol. 28. No. 1. January 1996. p39-40.
Kellogg W, Thomas J. 1993.
Cross-cultural Perspectives on Human-Computer Interaction: A Report on the CHI'92 Workshop. SIGCHI Bulletin. Vol. 25. No. 2. April 1993. p40-45.
Klein D. 1995.
Developing Applications with the Alpha UIMS. interactions. Vol 2. No. 4. p48-65.
Madell T, Parsons C, and Abegg J. 1992.
Developing and Localizing International Software. Hewlett Packard Professional Books.
Marcus A. 1993.
Human Communication Issues in Advanced User Interfaces. Communications of the ACM. April 1993. Vol. 4. No. 4. p101-109.
Nakakoji K. 1994.
Crossing the Cultural Boundary. BYTE. Vol. 19. No. 6. June 1994. p107-109.
Nielsen J (Ed.). 1990.
Designing User Interfaces for International Use. Elsevier, New York.
O'Donnell S. 1994.
Programming for the Whole World: A Guide to Internationalization. Prentice Hall.
Pease A. 1981.
Body Language: How to Read Others' Thoughts by Their Gestures. Camel Publishing Company, Avalon Beach, Australia.
Russo P, Boor S. 1993.
How Fluent is your Interface? Designing for International Users. Proc. INTERCHI '93 Conference on Human Factors in Computing Systems: INTERACT '93 and CHI'93. (Amsterdam, 24-29 April). ACM Press. p342-347.
Sukaviriya P, Moran L. 1990.
User Interface for Asia. In Nielsen J (Ed.). Designing User Interfaces for International Use. Elsevier, New York. p189-218.
Taylor D. 1992.
Global Software: Developing Applications for the International Market. Springer-Verlag.
Uren E, Howard R, Preinotti T. 1993.
Software Internationalization and Localization: An Introduction. Van Nostrand Reinhold.
Webster HyperText Interface. 1995.
http://c.gp.cs.cmu.edu:5103/prog/webster
Yeo A, Barbour R. 1996.
Software for the Rest of the World. Working Paper 96/2. Computer Science Department Working Paper Series. University of Waikato, New Zealand.

About the Author

Alvin Yeo is a post-graduate at the Computer Science Department, University of Waikato, New Zealand. His research interests include software internationalisation and localisation, and evaluation techniques in human-computer interaction. He is currently on study-leave from the Faculty of Information Technology, Universiti Malaysia Sarawak.

Author's Address

Computer Science Department
University of Waikato
Hamilton, New Zealand.
awy@cs.waikato.ac.nz

Same topic in earlier issue
Issue
Previous article
Article
SIGCHI Bulletin
Vol.28 No.3, July 1996
Next article
Article
Same topic in later issue
Issue