Tài liệu Web Application Design Patterns- P12 ppt

DATE FORMAT Problem Using a date format common in one region can be confusing to users from other regions.. For example, the date format used in the United States mm/ dd/yy or mm/dd/

translation then can be easily accommodated without affecting page out ( Figure 10.3 )

elements such as buttons and dropdown lists may get clipped or appear

in multiple lines, giving the page an unprofessional appearance Similarly, translated data in narrower columns may cause information in a table cell

to spill over to adjacent cells, or information may end up in several lines, making tabular data diffi cult to read For secondary data, it may be accept-able to truncate or expand the data based on the browser window’s width ( Figure 10.4 )

Designing visual elements that allow for text swell makes their reuse possible, regardless of the language to which the application is localized ( Figure 10.5 )

understood (see the ICONS pattern in Chapter 12), they are usually plemented with a text label Labels placement and icon design should also be accounted for with text expansion to avoid potential design issues

DESIGN MESSAGES TO ACCOMMODATE VARIABLE TEXT

Variable text, also referred to as concatenated strings , refers to text that is

con-structed using both static and variable text fragments and is usually presented

in sentence form For example, Figure 10.7 (a) shows Google’s search results

page with the message “ Results 1 – 10 of about 1,620,000,000 for website ”

Variable texts in this message are the number of results being shown (1 – 10), the total number of search results (1,620,000,000), and the search query (web site) A similar message on Google India in Figure 10.7 (b) has a different order

of variables It fi rst displays the total number of search results (194,000), the

Japan in Figure 10.7 (c) has a different order of variable text starting with the

FIGURE 10.4 As the browser window expands, Gmail shows more text in message rows without affecting page layout For narrower browser widths, Gmail truncates data and shows

an ellipsis at the end

317Extensible Design

FIGURE 10.5 The “ account ” box on Blogger.com uses a box with rounded corners When

translating from English (a) to Spanish (b), more space is required to accommodate the

translated information Because of the box’s extensible design, it can easily accommodate

additional vertical space without affecting the layout

TIP

Allowing for text expansion is important even for web

applications that are not going to be localized When

ignored, page design can break down or content may become

diffi cult to read for users who prefer larger text

(a)

FIGURE 10.6 Flickr shows icon labels when a page is in English (a) but removes them when

showing the page in other languages (b) Instead, they are shown as tooltips This may be

because the labels are embedded in the images requiring a different set of images for each

language In addition, because the translated labels require more space, it may be diffi cult to

fi t all the icons in the available space

(b)

search query (web site), the total number of search results (1,150,000,000), and then the number of results being shown (1 – 10)

If messages are coded so that a variable text fragment is simply inserted in a static message, it would be almost impossible to localize the message To make localization easier, therefore, it’s important that code accommodates changing the sentence structure and reordering of the variables Possible solutions are

to either have the entire message translated or have a different way of ing information, usually in a nonsentence form by separating the label and the variable text (e.g., Total number of search results: 200) (Hurst, 2007)

AVOID EMBEDDING TEXT IN IMAGES Avoid including text in images When text is embedded in images, localization requires a new image to be created with translated text Instead, consider over-laying text on background images ( Figure 10.8 )

FIGURE 10.7 Search results message on (a) Google United States, (b) Google India, and (c) Google Japan

(a)

(b)

(c)

USE CULTURE-NEUTRAL IMAGES

When using images and icons, use universally recognized objects and avoid

using images that are ethnocentric and/or may be considered offensive in other

cultures For example, to represent email, use an image of an envelope instead

of a rural mailbox, which is readily understood only in the United States In

addition, avoid using hand gestures in icons and images, as they may be

consid-ered offensive in some cultures For example, using an “ okay ” sign (index fi nger

thumbs-up gesture (a sign of “ all good ” or “ okay ” in North America) is

consid-ered highly offensive in Iraq and other Islamic countries (Koerner, 2003)

Even symbols commonly considered to be “ neutral ” may not be so The check

symbol (a cross in a square box) means “ correct ” or “ okay ” in many

coun-tries But in Japan and Korea, a circle is used instead of a check mark to mean

“ yes ” ; in fact, the checkmark indicates “ no good ” or “ fail ” Finally, avoid using

maps that include controversial regional or national boundaries (e.g., showing

national boundaries on maps of India and Pakistan)

Extensible Design

5 In Turkey it’s a sign for something homosexual In China, it can mean “ zero ” or the number

three; in Japan and Korea, it can refer to the shape of a coin and means “ money ” For more

infor-mation, see The OK Hand Gesture Around the World—Learn the Meaning of Hand Gestures (2008);

www.articlesbase.com/travel-tips-articles/the-ok-hand-gesture-around-the-world-learn-the-meaning-of-hand-gestures-624739.html

FIGURE 10.8 The “ Sign Up Now! ” button on WordPress.com is an overlay of the text “ Sign

Up Now! ” on top of a button image (a), making it easy to reuse the button’s original image as a

background image and use translated text for other languages (b, c)

(a)

(b)

(c)

USE CULTURALLY RELEVANT METAPHORS

In North America, using a shopping cart is a valid metaphor for purchasing items because it easily translates to users ’ real-world experience In Europe and Asia, however, a shopping cart icon could cause confusion because users are more familiar with shopping baskets than with carts E-commerce sites should change labels and/or images when serving customers in those countries ( Figure 10.9 )

USE PLAIN LANGUAGE Avoid confusing nonnative speakers by using plain language and refraining from slang and colloquialisms in text In addition, be sensitive when using

used by non-American users North American culture is very informal pared to many other cultures, as evidenced by its low Power Distance Index

com-in Hofstede’s cultural dimensions (see www.greet-hofstede.com/hofstede_united_

states.shtml ) In Asia, such informality would be considered inappropriate, as

people are usually addressed by their last name Greetings used by Amazon or Flickr are more appropriate for web applications with international audiences ( Figure 10.10 )

In general, to make localization easier, avoid the following when developing web content (Hurst, 2007):

■ Slang or jargon

FIGURE 10.9 Amazon uses the label “ basket ” for its e-commerce site in the United Kingdom (However, the icon still resembles a shopping cart.)

FIGURE 10.10 Greetings used by Flickr (a) and Amazon (b) are more appropriate for international audiences

Related design patterns

The patterns identifi ed in Chapter 11 — SEMANTIC MARKUP, UNOBTRUSIVE

STYLE SHEETS, UNOBTRUSIVE JAVSCRIPT, and so forth — are also relevant for

internationalization, as they help make web applications easy to localize

DATE FORMAT

Problem

Using a date format common in one region can be confusing to users from

other regions For example, the date format used in the United States (mm/

dd/yy or mm/dd/yyyy) would be confusing to European users because they are

familiar with dd/mm/yy or dd/mm/yyyy formats and to Japanese users who

use yy/mm/dd format

Solution

Use the ISO 8601 recommended yyyy-mm-dd date format when showing dates,

or use a format that eliminates confusion between the month and the year in a

date ( Figures 10.11 and 10.12 )

Why

Although web applications designed to be used exclusively by a country or a

region can depend on its native date formatting standard, users from other

Date Format

FIGURE 10.11 Sun uses the yyyy/mm/dd format for displaying dates (a slight variation from

the ISO recommended yyyy-mm-dd format)

FIGURE 10.12 PayPal uses a date format of the abbreviated month, dd, yyyy to make the

month and year obvious

regions may fi nd it confusing if it doesn’t match their local conventions For example, the date “ 02/04/03 ” may be interpreted as

ing dates easier (see also www.w3.org/International/questions/qa-date-format )

However, the ISO date format is diffi cult to read, as it is quite different from

issues, use a more readable format that spells out the month and makes the year obvious (e.g., February 4, 2003, or 4 February 2003)

How

Designers have two options to show dates:

recommended format of yyyy-mm-dd is the solution most commonly adopted by web applications with a diverse user base, where:

uses a name for the month and four digits for the year So the date can

be written as January 2, 2008, or 2 January 2008 This approach is more natural to users, since it is easier to read However, it occupies more space and, because it may affect sorting performance, is less computer friendly

BE CAREFUL WHEN ABBREVIATING MONTHS Abbreviating letters for months in dates (e.g., Jan 2, 2008, or 2 Jan 2008) may

be problematic for users in some countries For example, in French, the fi rst

three letters of June and July are the same — juin and juillet , respectively

CONSIDER USERS ’ LOCALE PREFERENCES WHEN SHOWING DATES

However, this method of showing dates may be inappropriate if the content

is not localized and therefore it is possible that the date format will not match

the language of the page For example, if a page is presented in German,

show-ing dates in the North American mm/dd/yyyy format may be confusshow-ing (even

when users ’ locale preference is English), as users may be unclear if the page

uses the mm/dd/yyyy format or dd/mm/yyyy format

USE CALENDAR POP-UPS FOR DATE SELECTION

To minimize date input errors, consider using pop-up calendars They help in

several ways First, they prevent data-entry errors caused by differing date

for-mats (mm/dd/yy versus dd/mm/yy) Second, because users can see both the

month and day, they can be sure that they have chosen the right date When

using pop-up calendars, show the calendar as soon as the date fi eld has received

focus to encourage users to pick a date from the calendar; however, do not

pre-vent them from entering the date via the keyboard In addition, when using a

pop-up calendar, ensure that the month is clearly shown ( Figure 10.13 )

Related design patterns

Using a locale-neutral format requires more horizontal space than the U.S

for-mat of mm/dd/yy or mm/dd/yyyy Therefore, it’s important that pages use an

Date Format

FIGURE 10.13 This pop-up calendar from Flickr, although it uses mm/dd/yyyy format (even for

different languages), makes it easy to select a date from the calendar (a) The month in the

pop-up calendar is localized to the selected language (b)

(a)

(b)

EXTENSIBLE DESIGN to accommodate additional space requirements In tion, consider using the GLOBAL GATEWAY pattern to capture users ’ country and language preferences

TIME FORMAT

Problem

Like date formats, time formats vary from one region to another Although each time format shows hours, minutes, and seconds, their presentation order and separators often vary in terms of a 12- or 24-hour format; the character used to separate hours, minutes, and seconds; leading zeros; the display of time zones; and the use of daylight savings times

Solution

Whenever possible, show times in users ’ local time zones and use local tions for showing time — that is, either the 12-hour AM/PM system or 24-hour system ( Figure 10.14 )

If time cannot be represented in users ’ native format, use ISO 8601

hh:mm:ss extended format, where:

an added leap second)

Why

Users are likely to be most familiar with the local convention for their time zone and may be uncertain about the time when presented with other conven-tions In addition, when time is presented in a different country’s time zone, users may not know how to convert it to their local time zone or may make errors when converting it

show time using the event or activity’s time zone as the point of reference For

example, when showing fl ight status, use local time zones from where the fl ight

will depart and where the fl ight will arrive ( Figure 10.15 )

ALLOW USERS TO SPECIFY THEIR TIME ZONE PREFERENCE

When registering with an application or setting up a user profi le, ask users for

their preferred time zone ( Figure 10.16 )

For tasks such as scheduling meetings or setting up events, when showing local

times, indicate the time zone and offset from GMT (Greenwich Mean Time) or

UTC (Coordinated Universal Time or Universal Coordinated Time) ( Figure 10.17 )

because of users ’ familiarity with it

Related design patterns

The localized DATE FORMAT pattern usually accompanies the TIME FORMAT

pattern, because most applications that show time or require users to select

Time Format

6 GMT is based on the rotation of the Earth, whereas UTC is based on cesium-beam atomic

clocks The two times are usually the same, or no more than a second apart, as leap seconds are

occasionally applied to UTC

FIGURE 10.15 When showing fl ight status information, departure and arrival times should be

shown using local departure and arrival times regardless of the time zone from which users are

viewing the data (www.fl ightview.com)

FIGURE 10.16 When creating a meeting or an event in ReadyTalk, users are asked to indicate

both the time and time zone in which the meeting will occur

times usually show dates or require users to select dates In addition, showing time zones and time zone offsets requires additional space, making use of the EXTENSIBLE DESIGN pattern as well

NUMBER FORMAT

Problem

Conventions around the world for representing numbers vary in terms of group and decimal (i.e., fractional) separators, precision required, units of measure, and so forth

in formats they are most accustomed to seeing

How

When showing numbers, the whole (or integer) portion of a number is usually split into groups by a separator The way the number groups are created and the separator is used varies around the world ( Figure 10.18 ) In the United States, numbers are shown in groups of three, separated by commas (e.g., 1,000,000);

in India, numbers are shown in one group of three and then in groups of two, separated by commas (e.g., 10,00,000); and in Japan, large numbers are created

by grouping digits in 10000s separated by ideographic characters that represent powers of 10000 (e.g., 1 0000 0000)

FIGURE 10.17 When editing account information, Twitter allows users to specify their time zone Although it shows “ GMT-08:00, ” it clarifi es the time zone by indicating “ Pacifi c Time ” and the countries in which it is applicable, “ (US and Canada) ”

Like grouping separators, the separator between the whole and the fractional part

of a number — known as a decimal point, decimal separator, and other terms —

also varies from one country to another It can be a decimal point (i.e., a period),

comma, or another character ( Figure 10.19 )

USE UNITS OF MEASURE FAMILIAR TO USERS

Use units for weights and measurements to suit the target country’s conventions

as well For example, using pounds, feet, and inches (English or British system)

will not be effective in countries that use the Metric system, where the

corre-sponding units of measure are kilograms, meters, and centimeters, respectively

Similarly, showing temperature in Fahrenheit will be confusing to users who are

only familiar with the Centigrade system Therefore, if an application is likely to

be accessed by those familiar with different conventions, show units of measure

and temperature in both Metric and English systems or allow users to switch

from one measurement unit to another ( Figure 10.20 )

Because users may be unfamiliar with the terms “ English ” and “ Metric ”

sys-tems, when feasible, use explicit and familiar units of measurement such as

°F and °C Similarly, it is better to ask users to choose units of measurement,

such as centimeters, meters, feet, yards, and so forth, instead of asking them to

choose between English and Metric systems

SHOW PHONE NUMBERS IN FAMILIAR FORMATS

Phone number formats also vary from one country to another in the total

num-ber of digits in the phone numnum-ber and separators ( Figure 10.21 ) Therefore,

when possible, follow local conventions for showing phone numbers

Number Format

United States 1,000,000,000 Groups of 3, separated by a comma (,)

Germany 1.000.000.000 Groups of 3, separated by a period (.)

Switzerland 1’000’000’000 Groups of 3, separated by an apostrophe (’)

France 1 000 000 000 Groups of 3, separated by a space

India 1,00,00,00,000 First group of 3, then groups of 2, separated by a comma (,)

Japan 1 0000 0000 Groups of 4 separated by ideographic characters

FIGURE 10.18 Examples of grouping separators in different countries

United States 1,123.45 Decimal separator is a period (.)

France 1 123,45 Decimal separator is a comma (,)

Switzerland (German) 1’123.45 Decimal separator is a period (.)

Switzerland (French) 1 123,45 Decimal separator is a comma (,)

FIGURE 10.19 Examples of decimal separators in different countries Multilingual countries

such as Switzerland use different decimal separators for different languages A comma is used

as the decimal separator, except when the amount is in Swiss Francs, in which case a period is

used, and either an apostrophe or space is used for the thousands separator

An alternative is to use ITU-T E.123, which is the International Format that recommends the following (see also Figures 10.22 and 10.23):

§ 2.1: The international number should be printed below the national number, with corresponding digits lined up one under the other to facilitate understanding of the composition of the international number

§ 2.5: If it is desirable to write only the international number, it should be

Australia 61 (0403) 416 7216 New Zealand 64 021 525-582 United Kingdom 44 07700 954 321 United States 1 (954) 555-1234 France 33 06 87 71 23 45

FIGURE 10.21 Local phone number formats

FIGURE 10.22 ITU-T E.123 recommendation for formatting national and international numbers

FIGURE 10.23 Phone and fax numbers presented

in this example are

in an international format

FIGURE 10.20 Weather information from USA Today (a) shows temperatures in both °F and °C

Weather.com (b) allows users to switch between “ English ” and “ Metric ” systems because it not only changes units of measure for temperature but also for wind, pressure, dew point, and visibility

(b) (a)

Related design patterns

Like other patterns, using localized NUMBER FORMAT requires additional

space, and it’s important that pages use an EXTENSIBLE DESIGN to

accom-modate additional space requirements In addition, consider using GLOBAL

GATEWAY to capture users ’ region and language preferences and present

num-ber formats accordingly

CURRENCY AND CURRENCY FORMAT

Problem

Web applications (e.g., e-commerce applications) that show the value of

prod-ucts and services to users in regions around the world need to present prices in

local currencies However, not only are currencies different around the world,

but their formatting in terms of the symbol and placement are different as well

Solution

Show users currency in their native formats In addition, where users may

encounter prices in a currency other than in which they wish to transact, allow

them to change it by specifying either country or desired currency ( Figure 10.24 )

Currency and Currency Format

FIGURE 10.24 Fontshop shows prices in U.S dollars ( $ ) (a), but allows users to select a

different country from the country selection menu (b), which changes the currency, in this case,

to Euros ( €) (c)

(a)

(b)

(c)

Why

Showing users price information in their local currencies and formats helps them because they know exactly how much they will pay for products (or ser-vices) and they do not have to rely on exchange calculators or other ways of converting prices to get correct amounts

How

Web applications that support multiple currencies must take into ation corresponding currency symbols, codes, and formats This is because of the diversity in currencies and number formatting schemes used by different countries For example, the currency symbol for the British pound (ISO code: GBP) is £ and for Japanese yen (ISO code: JPY) is ¥ In addition, the placement

consider-of the currency symbol varies from one country to another ( Figure 10.25 ) User interaction for changing currency is very similar to that of changing the lan-guage (see the LANGUAGE SELECTOR pattern later in this chapter) Depending

on the number of currencies supported by an application, users may select the appropriate currency from either a dropdown list or a set of links ( Figure 10.26 ) When users change currencies to see prices in their local currency or a different cur-rency, show the exchange rate along with the currency conversion ( Figure 10.27 )

To avoid potential confusion about the currency, show users the ate currency symbol ( Figure 10.28 ), the ISO currency code, or both, as shown below In addition, show the appropriate group and decimal separators based

appropri-on users ’ locale preference

MAKE THE CURRENCY SELECTION PERSISTENT

Do not require users to choose their desired currency every time they access the application and as they navigate the application pages Make users ’ currency selection persist using cookies or as a preference tied to their login not only within the same session but also when they return to the application later

Related design patterns

Prices are typically shown as numbers Therefore, it is important that prices are not only shown in appropriate currencies and their formats but also follow

FIGURE 10.25 The currency symbol and its placement differ among countries