Culture and Usability - Cross Cultural Issues in HCI, IIT Guwahati

Culture Vs Usability in Enterprise Applications

Sameer Chavan
Manager User Experience, Oracle India Pvt Ltd, Hyderabad.
sameerhere@yahoo.com, Cell: +91 9849652447
Member: ACM, SIGCHI, UPA

Dhayan Kumar
Interaction Designer, Oracle India Pvt Ltd, Hyderabad.
Ddhayan@yahoo.com Cell: +91 40 55052042,
Member: ACM

Abstract
This paper explores how cultural issues are address in current Oracle Web
Applications. Oracle web applications are translated in 32 languages and sold in
many countries. Interaction issues related to Color, images, text and organization
of design elements are addressed carefully in Oracle Applications in terms of
Internationalization and localization.

Culture-
Different definition & theories of culture have been proposed by ethnographers &
anthropologists which defines Culture in terms of knowledge, belief, art, morals,
law, custom, and habits acquired by humans as a member of society
Different Cultures create different expectations in the humans which require
designing systems that satisfy different cultures. Consumer products such as
mobile phone are highly affected by culture compared to business applications
like Oracle.
Generally, culture differs not only in language, symbol, image, color, and format
of date and time, but also emotion, personality, perception, cognition, and
thinking style.

Hofstede’s mode is used commonly to evaluate cultural. It consists of several
variables, by which groups of people can be evaluated and classified. Such a
model of culture allows for a more empirically view on culture as variables can be
present in any given culture in various strength and therefore can be measured
and used to distinguish one culture from another. His cultural model includes the
following variables:
Uncertainty avoidance: It measures a nation's preference for strict laws
and regulations over ambiguity and risk. Greece is the most risk-averse
culture, and Singapore the least. Protestant and Chinese culture countries
rank relatively low; Catholic, Buddhist, and Arabic countries tend to score
high in uncertainty avoidance. Ironically, high uncertainty avoidance

cultures tend to have a less efficient infrastructure than low uncertainty
avoidance cultures.
Power distance: It measures how much a culture has respect for
authority. The Arabic-speaking nations, Latin America, Russia, and nearly
all of Asia (especially India and China) are high in power distance. Most of
Europe, Canada, Australia and Israel are low in power distance. Japan
and Mediterranean-Europe fall in the middle range.
Masculine and feminine cultures: it describes the degree to which
masculine values like competitiveness and the aquisition of wealth are
valued over feminine values like relationship building and quality of life.
Japan is the world's most masculine society, with a rating of 95, while
Sweden is the most feminine society, with a rating of 5. Other "masculine"
cultures are USA, the German-speaking world, Ireland, United Kingdom,
Mexico and Italy. "Feminine" cultures are the Netherlands, Spain,
Thailand, Korea, Portugal, the Middle East, and West Africa.
Collectivist and individualist: Individualist cultures, such as those of the
United States and Western Europe, emphasize personal achievement at
the expense of group goals, resulting in a strong sense of competition.
Collectivist cultures, such as those of China, Korea, and Japan,
emphasize family and work group goals.

Enterprise applications
Enterprise applications are those which are accessed simultaneously by many
users and are hosted on servers. They mostly have multiple user roles, security
access and integration with other applications. They help companies to maintain
and access enterprise data like finance, employee, sales, production, etc. Major
Enterprise applications fall under Enterprise resource planning (ERP), customer
relationship management(CRM), Human Resource Management (HRMS) &
supply chain management(SCM). These are mostly horizontal applications used
in any industry. But there are Industry vertical Enterprise applications too. Like
Banking, Insurance, Universities, Hospitals, Government applications, etc
targeted for specific industries. These vertical applications may access some of
the horizontal applications to complete their tasks.

Cultural issues for Enterprise applications
Enterprise applications does have to consider cultural issues in interfaces design
like color, images and text which may affect people with particular religion or
country or class. But there are more broader issues in terms of
internationalizations and localizations that need be address in Enterprise
applications. I18n and L10N indirectly addresses issues arising due to different
cultures.
In software development, after a product has been internationalized,
"localization" refers to the process of making it ready for a specific market. So
you can refer to a product as being "internationalized" if it has been developed to
meet most of the needs of an international community, but not yet customized to
a specific region. The customization to a specific region is called "localization

Internationalization for oracle applications.
Internationalization is the process of adapting Oracle products for global use.
Internationalization requirements vary from one country to another, depending on
language, formatting conventions, and cultural values.
If an application is not compliant with Internationalization requirements, it will be
much more expensive to translate it into some languages, and prohibitively
expensive or impossible to translate into others. The net result is that the
application may have an extremely limited market outside the USA, and thus
hinder the overall marketing effort for Oracle Applications worldwide.

Overall Approach
Support for national language and corresponding character set, such as
Japanese and Arabic.
Internationally acceptable use of images and colors. Some images, such as a
hand with different fingers extended, may be interpreted differently depending on
culture.
Support for national format conventions for dates, time, decimals, currency,
names, and addresses. Formats may include or omit certain fields, and require
different separators.

Oracle provides Internationalization support at multiple levels:

Translation and Localization Issues
A single language may vary from one country to another. For example, English
spelling and certain terms vary between the US and Great Britain, with many
former British Commonwealth countries, such as Australia, following British
standards.
A single country may have more than one language. For example, Canada has
both English and French as national languages, with legal requirements for
communications in both languages.

Page layouts must allow translated text to expand by an average of 100 percent,
and up to 150 percent for short words (less than 5 characters long) and narrow
columns.
Words in some languages, such as German and Finnish, are typically longer
than their English equivalents. When placed in narrow columns, such as Content
Containers, these longer terms cause additional line breaks, leading to major
increases in vertical space, and added horizontal space, which causes extra
scrolling.
Some languages may not have equivalent terms to those used in the original
English version, so those terms need to be translated as multiple words. For
example, there is no single word for "privacy" in Indonesian.
Some countries, such as Sweden, regard the active voice as impolite, and use
longer passive voice constructions.

Readiness of Text for Translation
o Help text is also more readily translated if it conforms to Oracle style
standards, which promote clarity, brevity, and consistency. If translators
have difficulty understanding content, they will have even more difficulty
translating it.
o Longer does not mean better. In most cases, longer means "more
expensive to translate" and "less likely to be read". High word counts can
result in a document not being translated, which is a disservice to users
worldwide.
o Label text and instructions may be translated by different people even
though they appear on the same page. As a result, any instructions that
reference label text may be translated differently. To avoid such errors, do
not reference label text in Instruction Text, Tips, and Hints unless
absolutely necessary to explain a complex range of options to new users.

To avoid problems in translation of UI text:
o Verify that all use of terms conforms to modern English usage.
o Avoid references in Help text to national organizations, telephone
numbers, and addresses, unless specifically required, because these
must be localized.
o A single term should only have one meaning within an application. For
example, the English word "job" can have multiple meanings depending
on context, such as a position in a company or a database management
task. Those two meanings would be translated differently in most other
languages, but translators have no way to know that separate translations
are required.
o Write complete sentences, with proper capitalization and delimiters such
as periods and colons, to make the meaning clear to the translator.
o Do not use Latinate abbreviations. For example, use "that is" not "i.e.",
and use "example: 15-Dec-2004" not "e.g. 15-Dec-2004".
o For compound actions, use "or" instead of a slash, and "and" instead of an
ampersand, unless constrained by space. Both translators and users may
fail to understand the difference. For example, "View or Update" is
preferred over "View/Update", and "Create and Add Another" is preferred

over "Create & Add Another". Also, do not use the construction "and/or":
"and" and "or" are mutually exclusive.
o Use complete phrases in labels. For example, use "Replacement Text"
instead of "Replace with."
o Do not rely on capitalization to indicate semantic differences; some
languages do not have capital letters.
o Product names may also need to be translated, depending on the market.

Character Set Support
Applications must be able to display different character sets to support languages
such as:
Japanese
Chinese
Arabic
Russian (Cyrillic)
Greek

Bi-Directional (BiDi) Language Support
Applications should support bi-directional (BiDi) languages, such as Arabic and
Hebrew, which read text right to left, but read numbers left to right (within the
same body of information). This support is provided through style sheet settings,
so it is essential not to hard code any element that must be translated into a BiDi
language.
BiDi languages require that all horizontal directional UI images, such as arrows,
be flipped to match the reading direction.

Layout and Style Issues
o Font Families: Developers can avoid using hard-coded fonts, but use CSS
style classes instead, so that style sheet can then be customized by
locale.
o Font Sizes: Certain font sizes are not available or legible in all languages.
For instance, Asian fonts must be rendered in larger point sizes.
o Alignment: When aligning textual content, applications can use 'Start'
alignment instead of 'Left' alignment, and 'End' alignment instead of 'Right'
alignment. This ensures proper translation to all languages, including bi-
directional languages. 'Right' alignment is generally reserved for numeric
content.
o Horizontal and Vertical Space: Horizontal and vertical spacing can
dramatically change when an application is translated to a different
language, especially when that language is character-based or bi-
directional.
o Embedded Images and Fields: Applications may not embed images or
fields for variables within sentences, or concatenate fields and labels in a
sentence-like structure, such as "Add {AddressObject} From {Country}"
o Languages have different grammars, which cause major
rearrangements of translated sentences, thus making it impossible

to predict where to place the images or fields in relation to the
labels.
o Some languages, especially Romance languages such as French
and Spanish, have both masculine and feminine forms of articles,
adjectives, and pronouns, and these parts of speech must agree
with the gender of related nouns. If a field displays a word, it is
impossible to predict its gender when translating associated label
text.
o Fields and Field Order: Depending on locale settings or country selection,
some fields in forms and tables may be added, omitted, or change order:
o Name and address fields may change fields and field order to match
national requirements.
o Some languages, such as Japanese, include additional phonetic fields
(a.k.a. "Alternate" fields as aids to pronunciation).
o These changes should be implemented by individual development teams
based on the localization needs of their customers.

Untranslatable Sentence Formed from Fields and Labels

Un
translatable Instruction Text with Embedded Images

Contrast of Generic US and Japanese Address Forms

Cultural Values
Some colors, symbols, and images may be interpreted differently in different
cultures
Problems with Colors
o Oracle limits extensive color usage to avoid culturally sensitive colors. In
general, blue is the most acceptable color across all cultures:
o Black: Signifies death or evil in many European cultures.
o White: Signifies mourning in Chinese culture.
o Red: Signifies blood in some cultures, and is generally used for warnings.
Some cultures may still associate red with Communism. Depending on the
country, this could be perceived either favorably or unfavorably.

Problems with Images
When creating images and icons for use in applications there are three key rules
to enable internationalization:
o Avoid placing text in images, as Oracle Applications will not translate the
text.
o Verify that the image is not culture-specific. For example, an image from
American football may have no meaning or even negative associations in
some cultures.
o Avoid using images as metaphors, unless you can verify that the
metaphor works internationally, across different languages (this is
uncommon).
The following types of images should be avoided or used with caution in
applications that target multicultural users:
o Hands: Hand and finger gestures have a wide range of interpretations
across cultures.
o Faces: Vary in shape and color from race to race. If faces must be shown,
they should include a group of mixed races, consisting of at least one
Caucasian, one Negroid, and one Asian.
o National: Including flags and recognizable coins or currency, unless the
application shows multiple flags or currencies.

o Religious: Including crucifixes or elongated crosses, crescent moons or
sickles, six or five-pointed stars, figures seated in cross-legged positions
or with hands forming gestures, and so on.
o Gender: Avoid showing only male or female images. American and
European users may react negatively to male-only images; users from
some other countries may react negatively to female-only images. If
images of people are required, provide a mix of genders.

Formatting Conventions
Many format conventions vary from one country to another. Some of these, such
as date, time, currency, decimal separator, and other numeric formats, are
controlled by user preference and locale settings. Locale settings modify the
display of data to match language, and national and regional requirements.
For example, many European locale settings substitute commas and periods as
decimal separators in numeric formats. User preferences include choices
between a minus sign and angle brackets to display negative numbers, choices
between 24-hour and 12-hour time formats, and comma or period for numeric
formats.

Common Formats
Common formats like label/data and tabular elements, such as names;
addresses and telephone numbers should have a common layout and common
formatting from application to application, as well as meeting internationalization
requirements. Applications may deviate from standard formats where they have
documented business or functional needs to do so, but such variations should
not extend beyond that required by customers, and should adhere to
internationalization requirements.
For instance, in an HR application users may need to enter their personal
addresses; in a CRM application users may need to enter customers' addresses.
The formatting of this information should both be similar between these
applications, and be ready for translation without modifying the page.

Name Format Preferences
Formats for concatenated names are governed by the Name Format preference
of the user viewing the name. The two name format options are Global or Local.
o The Global setting displays all concatenated names in an internationally
viewable character set and sequence. The resulting concatenated name
formats are identical to U.S. English formats, though a customer may
choose to mandate another country's name formats for its global
operations.
o The Local setting displays all concatenated names in the formats from the
country in which they were created. This setting is expected to be used
mainly by users who deal mainly with staff in their own country, and are in
countries where the local names are different from the global names. For
example, if a user in the U.S.A. sets the name format preference to Local,
any names that were created in China would appear in Chinese
characters, using the sequence in which those names are normally

displayed in China. However, if a name created in the U.S. appears on the
same page, it would be displayed with the international character set,
using English language syntax.

Concatenated Formats in Different Locales
Greeting, Display, and List formats may vary considerably depending on locale.
The English language syntaxes may be used for other languages, especially
Western European, but this is a locale-specific decision.
o When concatenating names in greeting format, such as "Welcome Mary
Stuart," a sequence that is welcoming in one country may be strange or
impolite in another. For the U.S.A., the standard sequence is "Welcome
{Known As|FirstName} {LastName}"; other countries/cultures may require
the sequence "Welcome {LastName}" instead.
o When concatenating name attributes in Display and List formats, different
locales may require both different attribute order and different separators.
For example, in the U.S.A. a name may be concatenated in List format
with a comma as "LastName, FirstName", whereas in Japan the sequence
is "LastName FirstName" without a comma.

When concatenating name attributes in legal Display and List formats, one locale
may need to include name components not required in another. For example, a
U.S. English application needs to include suffixes if they exist to meet national
statutory requirements, whereas in France, suffixes are not required.

The following examples illustrate the variations in Greeting, Display, and List
format syntaxes for certain locales (not a complete list):

• Japan
o Greeting Format
 Syntax: [Greeting] {LastName}{Esquire}
 Note: The term "Esquire" refers to the word added to the end
of the Last name, usually "san" in Japanese.
 Examples: "Welcome Suzukisan"; "Welcome Miyamotosan"
o Display and List Formats
 Syntax: {LastName} {FirstName}
 Note: No middle initial or delimiter between names
 Examples: Suzuki Ryoji; Miyamoto Mushashi
• China: All three formats are identical
o Syntax: [Greeting] {LastName} {First Name}
o Note: The First Name (Given Name) usually consists of more than
one Chinese character. When translated phonetically, the two
words are often concatenated together. In China, the two words are
concatenated without space. In Taiwan, the two words are
hyphenated. In other locales, sometimes the two words are not
concatenated but are still be treated as one name rather than First
Name and Middle Name.
o Examples: "Welcome Dong Guohong"; "Welcome Kwan Sai-Hung";
"Welcome Leung Chau Ha"

• Korea
o Greeting Format
 Syntax: [Greeting] {LastName}{FirstName}[Esquire]
 Note: No space between Last name, first name, and
Esquire. The Esquire varies depending on age and gender.
 Example: "Welcome KimKyae-Youngnim" (for ); "Welcome
KimBogennim" (for )
 Syntax: {LastName}{FirstName}
 Note: No space between Last and First name.
 Example: "KimKyae-Youngnim"; "KimBogennim"
• Arabic
o Greeting Format
 Syntax: [Greeting] {FirstName} {LastName}
 Example: "Welcome Ahmed Ali"; "Welcome Maher Al-
Nubani"
 Syntax: {FirstName} {LastName} OR {LastName}{FirstName}
 Note: Both syntaxes are supported -- some countries that
use Arabic script, such as Egypt, sort phone books by first
name; others sort by last name.
 Example 1: "Ahmed Ali"; "Maher Al-Nubani"
 Example 2: "Ali Ahmed"; "Al-Nubani Maher"


Locale-Specific Address Format Issues
Depending on locale or country selection, both form and tabular layouts can
change considerably:
o Number of Attributes: Some address attributes are country-specific. For
example, five and nine digit zip codes are used in the U.S. whereas four-
digit postal codes are used in Australia; some countries are divided into
states, whereas others, such as Japan, are divided into prefectures. Some
countries, such as France, omit the region name (department) because
the first two letters of the postal code specify it.
o Order of Attributes: The order of address attributes may also change
depending on the country. For example, in France, postal codes are
placed before the city name.
o Required Fields: Fields may be mandatory in some countries and not in
others. For example, in the U.S.A. if an address is required, then a zip
code is a required field, whereas it may be optional in other countries.
o Phonetic Field: Some ideographic character-based languages, such as
Japanese, require a phonetic field to help interpret character-based
addresses.

Generic Updateable Japanese Address Form

Telephone Number Formats
o Each country may have multiple valid phone formats, with varying
numbers of digits, and different delimiters. Consequently, the phone
format field is dependent on the selection made in the "Country Code"
choice list. For example, many European countries use periods to delimit
sections of phone numbers, whereas dashes are more common in the
U.S.A..
o The "Country Code" choice list is the first label/choice pair. A "Go" button
follows the choice of country codes, unless PPR is used. When selected,
the items in the phone format label/choice pair redraws based on the
selected country code standard (NLS standard).
o The "Extension" field is optional.

Phone Format

Currency Formats
o Depending on context, monetary information may appear standalone on a
page, in a section of a page, in a subsection, or within a table cell.
o Monetary formats follow the numeric formats specified in user preference
and locale settings. For example, in the U.S.A., dollars and cents are

separated by a period; in many European countries they are separated by
a comma. Conventions for thousands separators also vary with locale
(U.S.A. uses a comma).
o Do not use the U.S. abbreviations "K" and "M" as these are not
translatable.
o Do not use currency symbols such as "$". Instead use full currency
designators, such as "US Dollars", or currency abbreviations, such as
"USD", together with Key Notation, for the following reasons:
o Lack of 1-to-1 parity of a currency symbol to the currency of a
particular country. For instance, the dollar symbol "$" is not unique
to the United States, but is also used by other countries such as
Canada and Brazil.
o Performance issues using GIFs to display the currency symbols.
o Translatability problems, as not every currency symbol character is
available in certain language's font set.
o Code overhead to keep choice list of currency code in synch via
PPR with the symbol.

Currency in View-Only Format in Form and Table Layouts with Key Notation and
Scaling

Multiple Currencies in Updateable Table Layout with Tip and Scaling

Culture and Usability - Cross Cultural Issues in HCI, IIT Guwahati

More Related Content

Similar to Culture and Usability - Cross Cultural Issues in HCI, IIT Guwahati (20)

More from Sameer Chavan (15)

Recently uploaded (20)

Culture and Usability - Cross Cultural Issues in HCI, IIT Guwahati