Colors, Buttons, Words and Culture:
Designing Software for the Global Community

Susan M. Johns
1997 CODI Conference
April 9-11,1997, Mesa, AZ
Pittsburg State University
Axe Library
Pittsburg KS 66762 USA
suzyq@mail.pittstate.edu

During recent beta testing of the new PAC for Windows, or PAC GUI, several questions arose concerning product design and product development. This presentation is perhaps more pie-in-the-sky wonderment than a critique of or direction for PAC for Windows, although the second presentation this hour, given by Lisa Godfrey and Stephanie Jones of Ameritech Library Services, will more directly address some of the design issues of PAC for Windows.

Nevertheless, one "graphical" issue that immediately struck me, which I use more as a means of illustration than as a criticism, is the very first banner screen of PAC for Windows, which will you note prominently displays the date of May 5.

Now, many of you probably know the significance of May 5. And probably equally as many here probably do not. This was one of the first questions I posed to Lisa, not only "What is May 5?" but "WHY did you chose May 5?"

We▓ll begin with the following cultural awareness quiz, for which I would like to ask all of you to participate, don▓t be shy, speak up, and help me out here!

Any significance to the following dates?

February 6 (Waitangi Day, or New Zealand Day)
April 12 (Halifax Day)
April 23 (St. George▓s Day)
May 17 (Syttende Mai)

What does knowing (or not knowing) the significance of these days tell you about yourself, and about those sitting next to you? Webster defines "culture", in this sense, as "the concepts, habits, skills, arts, instruments, institutions, etc. of a given people in a given period; civilization." However, alternate definitions which also seem to apply to our presentation to day are the definitions of "culture" as "the raising, improvement, or development of some plant, animal, or product", and "the training and refining of the mind, emotions, manners and taste."

How on earth does this relate to graphical product development for library automation?

Definition of Culture (Nakakoji)

Nakakoji defines culture as "the beliefs, value system, norms, mores, myths,and structural elements of a given organization, tribe, or society, more than mere language translation." As end-users and automation products become more global in scope, culture plays an exceedingly important role in the design, support, and implementation of our library systems.

Cross-Cultural Communication (Nakakoji)

becomes very important, particularly as we develop and use User interfaces for products with a global market. When outsourcing to other countries, we work and communicate with people we have never met in person. Work culture values and views differ from our own.

Many of us today, even though we may be residents of the contiguous United States, have only "met" each other on Dynix_l, our listserv. And so today, we meet each other in living color in all sizes and shapes and put names to faces we have never seen but have extensively exchanged ideas with over the past year.

Technology As Cultural Amplifier (Nakakoji)

"Although technologies transform culture and thought to amplify human productivity...a system▓s functionality... is often unconsciously affected by the underlying traditions of the system designer▓s culture." (Nakakoji)

It▓s often hard for us to realize our own biases until we stick our necks out and leave home base. I love being from Pittsburg, Kansas. For starters, 98% of the salespeople that call think I live in Pittsburgh, Pennsylvania. And, thanks to Judy Garland and The Wizard of Oz there are so many wonderful cliche▓ phrases I can use here. Hey, I▓m not in Kansas today, I▓m in Arizona. But you know what, whether you like it or not, I▓m bringing with me a *bias* that▓s part of me and my institution in Kansas. And during this conference I am now going to be influenced and exposed to cultural biases that you have packed in your suitcases and brought with you!

It▓s not that we have biases that are wrong, or more right than someone else▓s. But particularly in design, often a great tool doesn▓t quite work the way it was envisioned when it moves from one culture to another. What happens when the tools, the design, the look and feel, the icon, the color, the mechanics: what happens when they▓re designed for a local market and then are *transported* to a distinctly different culture and tried to be made to work?

(Sundial quote.)

Nakakoji presents and interesting tale of a small-scale interface research project (Teasley), designed to ascertain what a global, or maybe even a gender-specific user interface design might be. I shall call it for our purposes today,

The Tale of Three Interfaces (Teasley via Nakakoji)

The participants included:

54 Americans
35 English-speaking citizens of other nations
43 Males
46 Females

The Tale of Three Interfaces Designed For

Three interfaces were designed with three distinct target user "groups" in mind:

-- English-speaking European adult male intellectuals
-- Caucasian-American women
-- generic English-speaking consumers of an "international-style"

In creating this interface, the researchers started with several assumptions about their users▓ needs and preferences.

-- For the European males, they designed a product with low information density, using a classical approach to fonts and display.
-- For U.S. women, they avoided all brutal terms (kill, trash, abort), gave very detailed information presentations, and tried to soften the design with curvilinear shapes.
-- For the "internationals", the design included a very high information density, using terse terminology, and chose simple and clear lines of display and asymmetric typography.

The Tale of Three Interfaces Results

-- Design (1) was liked best.
-- Design (2) was liked least.
-- International consumers least liked (3), the interface designed with their assumed needs in mind.
Women preferred (1) over both (2) and (3).

The researchers also posed questions in the form of self evaluation to the participants. What were they thinking?

The Tale of Three Interfaces Self Evaluation

-- 40/88 thought (2) was designed for European males;
-- 41/88 thought (1) was designed for women

While this is but one single research project on a small scale, it does demonstrate a few things other than the obvious, that more research is needed. Teasley and Nakakoji concluded that

-- There are no generic cultural guidelines
-- Issues cannot be solved by using overly generalized characterizations of user populations
-- Unless representations are mathematical, there is always a risk of misunderstanding in human communication, and...

To these, I would add:

-- Do users know what they want?
-- Do users recognize what they▓ve designed (or requested)?
-- Is the user the best indicator the vendor has for developing the best design? The only indicator?

Now, before all the vendor reps hasten themselves to the door and say "Pffft, that▓s it, we▓re outta here, why are we sitting through a user conference with a bunch of users who don▓t know what they want?", let▓s discuss vendors for a moment. And let▓s discuss some of the demands that we as users place on them.

Don▓t Boil the Ocean (Frank)

-- Inter-galactic systems fail
-- Systems adressing all contingencies fail
-- All-encompassing systems fail

How many times have we just said "it doesn▓t do enough, it needs to do EVERYTHING? Or to put it in terms we deal with today in this room, I want what Australia has and the UK wants what I have, and why can▓t it be delivered by July 1997?"

Based on this perceived need and distress by their clients, it is often wise for vendors to:

-- Break projects into manageable chunks
-- Recognize parts that have greatest impact
-- Implement those parts quickly

Ha! Easy for me to say! I'▓m just the nagging user who needs everything yesterday.

We must also acknowledge a slightly different cross cultural development that goes on within the sphere of vendor versus customer.

Cross Cultural Development (Nakakoji)

-- Culture exists across professions.
-- End-users and developers share a certain type of cultural understanding
-- Should users be able to state their requirements clearly and precisely a priori when they simply do not have the knowledge to do so?

Of course, don'▓t tell us we don'▓t know what we▓re really asking for!

Further cross cultural development occurs even within vendor organizations, from management to programmer, or, for instance even within the Product Development Division, tremendous cross cultural interchanges occur between programmers and library analysts. From these "cultural" exchanges, we strive toward:

-- Software engineering and application domain knowledge work together
-- Develop knowledge among stakeholders
-- Exploit opportunities to establish successful cross cultural collaboration

Two examples that come to mind in this scenario; one, the predominance of male programmers versus female library analysts. Is this gender bias? Profession bias? Or cultural bias? What cultural exchanges and solutions are needed to get information conveyed accurately within a group such as this?

The second, is perhaps more perceived than real, but I▓ll use Alice Clay▓s post on Dynix_l the other day as an example. Alice found a gold mine. Alice found a utility program that solved frustrations that she had been collecting from the first day she loaded Release 140 two years ago. Alice, and a lot of other users, probably would like to see this utility turned into a feature, a menu option, the best thing since sliced pie. I don▓t know, to the programmer who wrote it, what is its significance? Just a tool? Just a quick fix to a support log? No doubt in Alice▓s mind this significant utility has been really undervalued for quite some time, and Alice in turn shared all the news with her friends and we have a happy Alice and a happy ending.

I want to make special emphasis of the last point. Exploit opportunities to establish successful cross cultural collaboration. Is this not why we are all here? I guess, I▓m exercising my own personal bias, that the product and vendor we are all using currently *wants* to be a global product and a global vendor. Dynix_l came online, and guess what: continents talk to one another ! We as users, I believe, have more in mind than simply acquiring everything that the other guy across the pond already has. We have found, by talking to one another, not only differences, but SOLUTIONS! IDEAS! VISION! COMMUNITY! Oooh, even FUN? That▓s why we▓re here today! How do we continue to promote and establish successful cross cultural collaboration? And how do we do it effectively to *help* rather than *hinder* our vendor of choice?

But we go back to our more global emphasis.

The International Need (Scheer)

-- Customers want systems and documentation that use their own language and meet their own cultural conventions
-- Some countries require products to reflect their culture and language
-- Internationally competitive companies must consider cultural preferences of their customers

The first, most obvious ego-centric question to anyone in Kansas is, well, you don▓t really need anything in a language other than English do you? One of the things that delighted me in a statistical sense was when New York Public came online and indicated what percentage of their collection for their patrons was non-English material. You don▓t have to be in Canada to have French material in your collection in your library, and you don▓t have to working in Mexico in order to need a Spanish public access catalog interface.

PeopleSoft Goes Global (Frye)

PeopleSoft is actually an "enterprise resource planning" product, that is, human resource management software coupled with financial, distribution, and manufacturing applications (Frye), not unlike a library system with patrons and a circulation, public access, and cataloging accounts. While the software differs, the global experiences are of interest to us. As the software was developed and marketed, the following issues arose:

-- Identify common processes around the world
-- Deliver languages and localizations
-- Add global complexity with manageable implementation

Their goals as a company were:

-- Shorter implementation
-- Customization times diminish
-- Ongoing maintenance is reduced

Analysis of their users, customers, and competitors revealed that:

-- Global customers have more in common than differences
-- Vendor must understand what is different and what is similar
-- Everybody (vendors) is "Embarking" (that is, their competitors).

Embarking? On what? *****?

What is Internationalization? (Scheer)

The process of providing a computer system that handles a variety of language, country, and cultural conventions.

Internationalization (I18N)

Internationalization attempts to eliminate cultural specifics, and design culture-independent user information and interfaces. (Nakakoji)

User information includes user manuals and documentation, menu labels, graphical representations, icons, error messages, even sound messages. (Nakakoji)

What is Localization?

-- A locale is an operating system database of language and country conventions.
-- Developing software to support multiple locales is Localization.
-- The folks at AT&T specifically use this terminology of "locale" (Scheer; also Miller)

Localization (L10N) (Scheer, Miller, Nakakoji)

-- Localization of product for each user culture (Mac trash can and the dustbin; recovery vs. re-retrieving)
-- Language, date and number formats
-- Graphical representations/icons
-- Color (red = danger/celebration/blood)
-- Physical flow of objects (screen repaints and refreshes)

System I18N

-- Uses multilingual products instead of monolingual or bilingual products
-- Allows switching between different locales and languages
-- Provides software that meets international standards

Think, if you will, of the problems back in the old days of IBM selectric typewriters. Remember how difficult it was to switch typing elements from italic to letter gothic? System I18N is not so much providing a standalone "translation" of a product (i.e., the "German" version, shall we say), as it is facilitating changing from italic to letter gothic in mid-sentence without having to lift your fingers off the keyboard. I can, currently, with Windows 95, play Tetris in French. I cannot, however, switch from French to English in mid-game, or simultaneously see my English and French instructions in a toggle-fashion to compare what▓s being said.

Let▓s reiterate the third point as well. Software that I might design in Kansas has to work in Glasgow. What Glasgow designs has to work in Ottawa, and what Ottawa designs has to work in Sydney. The only way this level of understanding, communication, and design is going to take place is if everybody is designing by the same rules, or standards. We▓ll come back to that in a minute.

System I18N Challenges (Scheer)

-- Treat English as just another language. Not *THE* language.
-- Use one program source for all languages to reduce costs for maintenance and documentation
-- Plan for extra disk space needed. To save space, ship only the languages purchased by a customer
-- What is the delay from when the package is available in the vendor▓s local country to when it is available in other languages?

Let▓s go back to our own product here for a moment. Let▓s talk zdaemons for a minute. They▓re great little pockets of code that make the z39.50 interfaces work, but hey, I▓m on an AIX platform. Do you know how much space on my machine is used to store the Alpha and the HP and all the other platform zdaemon files? Too much! :-)

Delays: We know currently what the delay interval is from the US to Australia, the UK, the Netherlands, Austria, wherever. How do we eliminate this or least drastically reduce it?

-- Monitor acronyms and mnemonics for negative meanings in different languages

Just when you thought it was a safe acronym, I learned in preparing for this presentation that LISA no longer means the Library and Information Science Abstracts. It now means, the Localisation Industry Standards Association, an organization set up in Geneva to assist global companies in understanding local standards and global differences in Switzerland and nearby countries (Preston).

-- Understand differences among U.S., British, and global English
-- Be aware of different dialects in the same language
-- Use care when sorting lists
-- Use numeric indexes instead of sorted alphabetic indexes whenever possible
-- Keep illustrations, tables, and figures simple
-- Verify translations back into English to see if they still make sense. ("Please shoe the computer again.")

Ah, now we get to the stuff that sets librarians on edge. Sorting lists and using numeric indexes over alphabetic indexes?? What is the world coming to now?

Okay, another cultural exercise. This room is filled with predominantly US-centristic Dynix system administrators. They nice, they▓re intelligent, I love ▒em all, but repeat after me: ZED 39.50. Again? ZED 39.50. Does it feel okay to you out there? Great, okay, now if I say ZEE 39.50 for the rest of this presentation, you▓ll excuse me, right, becase you now know it▓s just cultural baggage I brought with from Kansas, right?

Bill Kneedler, wizard of all things that have to do with operating systems and equipment and things that make my eyes roll out of their sockets, said to me in email one day, "you ARE going to talk about Unicode, right?" So I figured, hey, that▓s cool, a quick search on www.dogpile.com, and I should know what the heck he▓s talking about. :-) For the rest of you, I▓ve left a lot of technical programmer stuff out of this discussion, because I didn▓t think any of us wanted to learn more than we had to today about separated strings and objects and global states. If you *do* want to know all that and become a Unicode whiz, well, go get the 4.5 lb book, Unicode Version 2 that▓s listed on the bibliography. I assure you I had no room in my suitcase to bring it along as a show and tell item, because my luggage was already full with all those zzzzs.

If we start from the beginning, ascii, ISO 646 was the first attempt at standardizing character sets, however ascii was a U.S. standard based on 256 characters. Easy pie, US English. Very few characters, very little gender in the language.

History of Unicode (McClure and Hannah)

-- ASCII, a "U.S." Standard (ISO 646)
-- DBCS - double byte character system (some chars 1 byte, some 2 bytes)
-- Unicode - all chars 2 bytes (16 bits)
-- potential of 65,536 chars

English, for ascii, was easy. We have a small quantity of characters in the alphabet and acknowledged control characters and other miscellaneous representations of numbers and symbols. As more languages were added to the concept, ascii quickly became inadequate for languages having too many characters to fit into a single 8-bit format.

Eventually we ran out of bytes and still had more "symbols" in use around the world, thus the advent of the DBCS, and finally Unicode. By using 2 bytes for each symbol of an alphabet, we now have a potential of 65,000 "placeholders for symbols" if you will, under ISO 10646.

-- Unicode is a subset of ISO 10646, as are ASCII and Latin-1 (8-bit ASCII)
-- Unicode eliminates duplicate Han characters in Chinese, Japanese and Korean (CJK)
-- ISO 10646 stores chars in 4 bytes; Unicode stores chars in 2 bytes

Unicode is a *subset* of ISO 10646. ISO 10646 actually duplicates many of the CJK characters and stores characters in 4 byte chunks. There is some discussion still on how best to handle the CJK character sets, the least of these is how to map them to keyboards, switch keyboards, or abandon keyboards altogether and simply use voice recognition or pen pads; i.e., is it easier to draw the CJK character yourself than hunt for what control sequence it is on a non-standard keyboard?

Definition of Unicode (Davis)

"The Unicode standard is a fixed-width, 16-bit character encoding system that contains codes for every character needed by the major writing systems currently in use in the modern world, along with codes for a full range of punctuation, symbols, and control characters" (Davis et al.)

Emphasis on the word "standard". In some online databases of librarian creation, Unicode is mistakenly indexed under "programming language".

Unicode associates semantic information with each character that can be used to simplify text processing features. Each character can have an associated set of descriptive type properties identifying, for example:

Punctuation marks

-- Diacritic marks
-- Uppercase, lowercase, and uncased letters
-- Characters used to represent digits
-- Control characters
-- Semantic meaning inherent in character code

Unicode Problems (McClure and Hannah)

-- Universal standards for dates, measurements, and money
-- Simplified encoding of Chinese characters does not depict "classical" Chinese
-- Storage (twice as much?)
-- Transmissions (twice as long?)

Several problems remain, and these include the fact that there are still no universal standards for dates, measurements, and money. Now transmitting 2-byte characters means transmission of data may be twice as long, and storage of such data may be twice as large. Issues of whether to use 2-byte or 4-byte sizes for the CJK codes continue to be of concern, but well over half of the allocated 65,536 possible 2-byte "places" or "code points" are still "unallocated", allowing (hopefully) room for considerable expansion.

Unicode is not just being implemented by the library community. It is in PC and Macintosh based products already available around the world. I refer you to the bibliography entry on "The Unicode Consortium Language Page", which shows a rather comprehensive demonstration of a single page on the World Wide Web where you can simply click on a button and see a Unicode-based language version before your very eyes.

The biggest question in my mind as I prepared this presentation was really this: how on earth does the MARC record structure fit into this? Well, thankfully there are more forward thinkers and doers than I, because, there is a *ta-da*, UNIMARC format being refined even as we speak.

UNIMARC is defined as an:

UNIMARC Definition

-- implementation of ISO 2709 for the structure of records containing bibliographic data
-- intended to be a carrier format for exchange purposes, which does not stipulate form, content, or record structure of data *within* individual systems.

The UNIMARC book, published by the folks at IFLA, thankfully is not nearly as weighty as the Unicode book, but is equally as complex. For starters,

UNIMARC Problems

-- Software developers must rewrite their existing software
-- the MARC format (and there are some 25 or so country-specific MARC formats) uses a specific definition of extended ASCII
-- How do you convert 40 million MARC records without anyone noticing?

But, the advent of Unicode does give us much more flexibility to display, edit, index, and maintain in their correct language and format library materials that are not in English. Specifically,

UNIMARC Benefits (McClure and Hannah)

-- Allows addition of foreign titles without transliterating the data
-- Users able to search library catalogs in all languages rather than just by call number or ISBN (i.e, I might put in the term "United States" and actually retrieve records with "Etats-Unis" in the subject heading)
-- Assumes software/virtual keyboards or pen-based input devices needed to generate the international characters.

Remember, because Unicode can handle diacritics, punctuation, and other anomalies peculiar to a specific language or dialect, these are applied in a much different manner for indexes than we now currently use (experience, endure!) This is where the semantic intent and context-sensitive Unicode will aid library software design greatly; it is a benefit, however, that is at the expense of completely rewriting the software to allow for "locales" of rules specific to each language▓s materials. Unicode will be able to handle the following situations:

Sorting Conventions (Preston)

-- English: A-Z
-- German: Characters with an umlaut sort directly after characters without an umlaut
-- Swedish: Ö sorts last in the alphabet after Z
-- Spanish: double characters (ll and ch) that sort as single characters
-- Gender and inflection in language
-- Tense and case

Additional formatting and programming issues that Unicode will address, include:

-- Upper and lower case shortcuts, subtract 32 no more!
-- Wild card symbols in search/find boxes
-- Hyphenation of long words and word breaks

While data manipulation is of extreme importance to the library community, let▓s go back to the screen design for a moment. Unicode "locales" of various language versions need to also consider:

Menu Space (Miller)

-- 30-200% extra space depending on the number of English characters
-- Ex: "Preferences" translates "Bilschirmeinstellungen"
-- Boxes should be self-sizing and movable
-- This includes error messages, pull down boxes for options, input fields, dialog boxes, help definitions (Preston), even coded tables such as collection codes, item types, etc.

Message Catalogs (Scheer)

-- Files used to store program input and output strings
-- All program strings used interactively by the user should be contained in one or more message catalogs

Conventions and Format Differences (Miller)

-- Dates: May 12, 1959 is 12/5/59 5/12/59 1959-05-12
-- Calendars: Gregorian, Hebrew, Islamic, Japanese Imperial Era
-- Times: 8:32 p.m. is 20:32 20,32,00 20.32 KI 20.32
-- Numbers: 3,912.45 3.912,45 3 912,45
-- Currency: $2,456.78 2,456,78 DM 2.456$78
-- Don'▓t forget yen and pound symbols
-- Paper sizes: A3, A4, A5, JIS-B4 JIS-B5
-- Punctuation : << >> ; ║ ©

Work has been done in appropriateness of color in knowledge based expert systems (Nakakoji), and this coupled with more sociological and psychological studies on the differences of color across cultures gives developers and graphic designers a good base of data on which to build icons and screens with non-symbolic information appropriate to the purpose of the interface design.

Color, Music and Sound (Nakakoji)

-- Color combinations
-- Color balance (theme and secondary)
-- Color association (appropriateness based on abstract concepts)
-- Music and sound are more easily associated with a photograph than an icon
-- Music associations highly dependent on culture

We will turn color and icon issues over to the next part of the presentation, but one word about music and sounds, and that is to stress that sounds are *highly* dependent on culture and are even harder to define in terms of cultural taboos and benefits. Beeps, error notification, phrase jingles, and other forms of "sound" need to be cautiously applied, and more research is mandated to do this up "right". Many web pages, as an example, allow you to listen to a certain track of music while you shop or browse an online catalog. But to do this successfully on a global scale is something that will continue to develop.

Icons (Preston)

-- Trashcan icon can look like a postal box in Britain
-- If you use books, make sure they open in the proper direction for the target market
-- Email icon of a rural post box with a red flag has no meaning outside rural America
-- Colors within icons that may be insensitive
-- Try not to use text: think in terms of international driving symbols
-- Think: what is the symbol for ISBN other than ISBN?

The IFLA site at Stirling University, Scotland for Icon design, while the project is a few years old now, is interesting to see an attempt at creating and analyzing icon meaning. It▓s worth a visit.

All issues outlined in the last several minutes are issues to think about. In our use of web-based products, our own PAC for Windows software, and in other products and services currently available to us, an awareness of cultural issues we bring with us as users, as well as those projected by the designers and developers, are important to remember. Why do we react favorably (or unfavorably) to some designs? How are user preferences and ability to learn and understand information influenced by color, gender, semantics and culture?

While much research has been presented today, more research is needed and will continue as designers work with users in finding precisely that *right* space of seamless and stellar interface for our displays and data.

Our next presenters from Ameritech, will now present "icon bingo" and describe the processes used to design and select graphical representations in the new PAC for Windows product.

Bibliography

British Library and Biblioteca Nazionale, Definition of a Basic European Character Set (Workpackage Three), Final Report, Public Version, July 1993, http://www.konbib.nl/kb/sbo/proj/edbib/wp3.html.

British Library National Bibliographic Service, Towards a Common MARC Format, Proceedings of an open meeting held at the Library Association Headquarters, London, 21 July 1995, http://portico.bl.uk/nbs/marc/commarcm.html

Clay, Alice, Thank you, ALS, personal communication on Dynix_l, April 3, 1997.

Davis, J.E. and J. D. Grimes et al., Creating Global Softare : Text Handling and Localization in Taligent▓s CommonPoint Application, p. 227(17), in IBM Systems Journal 35(2), 1996. (#9606283014).

del Galdo, Elisa and Jakob Nielsen, International User Interfaces, John Wiley and Sons, 1996 (ISBN 0-471-14965-9).

Fowles, Ken, Unicode Evolves, p. 105-109, in Byte, March 1997.

Frank, Malcolm, Be Quick or Be Dead, p. 95-96, in Software Magazine, March 1997.

Frye, Colleen, PeopleSoft Goes Global, p. 62-66, in Software Magazine, March 1997.

Greenwood, T. G., International cultural differences in software, p. 8-20, in Digital Technical Journal 5(3), Summer 1993.

IFLA Information Technology Section, Feasibility of a Standard Icon Set for Bibliographic Information Systems, http://lorne.stir.ac.uk/iconstd/overview.htm and associated pages.

IFLA Universal Bibliographic Control and International MARC Programme, UNIMARC Manual, Bibliographic Format, 2nd Ed, K. G. Saur, 1994 (ISBN 3-598-11211-4)

Marchionini, Gary, Information Seeking in Electronic Environments, Cambridge University Press, 1995 (ISBN 0-521-44372-5).

McClure, Wanda L. and Stan A. Hannah, Communicating Globally : the Advent of Unicode, p. 19(6), in Computers in Libraries, v.15(5), May 1995.

Miller, Chris, Transborder Tips and Traps, p. 93-102, in Byte 19(6) June 1994.

Nakakoji, Kumiyo, Beyond Language Translation : Crossing the Cultural Divide, p. 42-46 in IEEE Software, November 1996.,

Nakakoji, Kumiyo, Crossing the Cultural Boundary, p. 107-109, in Byte 19(6), June 1994.

Nakakoji, Kumiyo, Brent N. Reeves, Atsushi Aoki, Hironobu Suzuki, and Kazunori Mizushima, eMMaC: Knowledge-Based Color Critiquing Support for Novice Multimedia Authors, http://www.ipa.go.up/STC/MMP/

Nielsen, Jakob, International Web Usability, in Jakob Nielsen▓s Alertbox, August 1996, http://www.useit.com/alertbox/9608.html.

Nielson, Jakob, Top Ten Mistakes in Web Design, in Jakob Nielsen▓s Alertbox, May 1996, http://www.useit.com/alertbox/9605.html.

Portaneri, Franck and Fethi Amara, Arabization of Graphical User Interfaces, in International User Interfaces, Elisa Del Galdo and Jakob Nielsen, editors, John Wiley and Sons, 1996, http://www.spartacus.com/langbox/staff/arastub.html

Preston, Holly Hubbard and Udo Flohr, Global from Day One, p. 97-104, in Byte, March 1997.

Russo, P. and S. Boor, How fluent is your interface? Designing for international users, p. 342-347, in Proceedings of INTERCHI'93, 24-29 April 1993, Amsterdam, Netherlands.

Scheer, Randall J., Internationalizing Unix Software Projects, p. 85-94 in AT&T Technical Journal, May/June 1995.

Shore, B. and A. R. Venkatachalam, The role of national culture in systems analysis and design, p. 5-14, in Journal of Global Information Management 3(3), Summer 1995.

The Unicode Consortium, Language Page, from the Tenth International Unicode Conference and Global Computing Showcase, http://www.reuters.com/unicode/iuc10/languages.htm

The Unicode Consortium, The Unicode Standard, Version 2.0, Addison-Wesley Developers Press, 1996 (ISBN 0-201-48345-9).

The Unicode Consortium, Welcome to the Unicode Home Page, http://www.stonehand.com/unicode.htm

---

---