Common Formats Usage Guideline

RCUX Document Version 5.1.0 for Oracle® Fusion Middleware 11g Release 1 Patch Set 1 (11.1.1.2.0)
Last Updated 15-April-2011

FusionFX applications feature many common prompt/data and tabular elements, such as names, addresses, and telephone numbers. These elements should have a common layout and common formatting from application to application, meeting internationalization requirements.

Guideline Contents

• General Principles
• Name Formats (of people, including titles)
• General Name Format Principles
• Sequence of Name Fields
• Sequence of Read-Only Name Fields
• Sequence of Editable Name Fields
• Locale-Specific Name Format Issues
• Recommended Fields for US English
• Concatenation of Name Fields
• Greeting Format in US English
• Display Format in US English
• List Format in US English
• Name Format Preferences
• Concatenated Formats in Different Locales
• Address Formats
• General Address Format Principles
• Locale-Specific Address Format Issues
• Personal Attributes
• Letter Formats
• Telephone Number Formats
• Telephone Field Layouts
• Single Line/Single Telephone Field
• Single Line/Multiple Telephone Fields
• Multiple Line/Multiple Telephone Fields
• Date Formats
• General Date Principles
• Full Date
• Full Date and Time
• Separate Date Fields
• Year
• Month
• Week
• Day of the Week
• Number of Days
• Fiscal Quarter
• Periods in Educational Institutions
• Date Ranges
• Periodicity
• Time Formats
• Read-Only Time Formats
• Editable Time Formats
• Duration
• Time Zones
• Time Zone Display Formats
• Editable Time Zones
• Read-Only Time Zones
• Numeric Formats (including percentages)
• Use of "Percent" and the "%" Symbol
• Non-Numeric Range Formats
• Currency Formats
• Identifying Currency Abbreviations
• Currencies in Form Layouts
• Currencies in Table Layouts
• Credit and Debit Card Formats
• Weights and Measures
• Identifying Weights and Measures
• Math Operators, Functions, and Symbols
• Spreadsheet Operators
• Spreadsheet Functions
• Mathematical Symbols

Related Guidelines

Guideline	Section	For Information About
Language in UI	All	General requirements for use of language in UI.

Related ADF Elements

Refer to the ADF Faces Rich Client demos page to find demos and tag documentation for the ADF elements related to this component:

ADF Element	Notes
af:panelFormLayout
af:inputDate
af:panelHeader
af:table
af:showDetailHeader
af:showDetailItem

General Principles

Purpose:

Common formats provide a set of predefined component groups and layouts for commonly used form and tabular elements, such as names, addresses, and telephone numbers, resulting in a consistent user experience across applications.

Usage:

• Common format elements may be displayed as prompt/data pairs, or as column headers and cells in a table. Both types may be editable or read-only.
• Many common formats—such as date, time, and currency formats—should be 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 in numeric formats.
• User preferences should include a choice between a minus sign and angle brackets to display negative numbers, between 24-hour and 12-hour time formats, and comma or period for numeric formats.
• To enable sharing of data between applications and outside parties, common formats for contact information in Oracle products must comply with Oracle Fusion Customer Hub requirements.
• Applications may deviate from standard formats to meet documented business or functional needs, but such variations should not extend beyond that required by customers, and should adhere to internationalization requirements.
• For example, in an HR application, users may need to enter their personal addresses, and in a CRM application, users may need to enter customers' addresses. The formatting of this information should be similar between these applications, and be translatable without modifying the page.

Name Formats

Purpose:

Ensure correct name display regardless of locale.

Usage:

Name formats include all elements of a person's full name and other name attributes, such as preferred names, maiden names, and titles. Name formats are based on context, and on users' locale and name format preferences. They may vary considerably from one locale to another.

The following core name fields must be provided for data entry across all Oracle products in all locales, so that names can be shared across countries in international organizations:

• First Name: Also known as "Given Name."
• Last Name: Also known as "Family Name."
• Preferred Name: Name by which a person is known, such as "Mike", instead of "Michael." Used instead of first name. Also referred to as the "Known As" field.

The following name fields may be required in certain locales:

• Prefix: Particles that precede the family name, such as "de", "D'", "de la", "della", "von", "van", "Abu", "ben." Also known as "pre-name adjunct."
• Middle Name or Middle Initial (Note: These should be separate fields).
• Phonetic fields in ideographic character-based languages to help pronounce the characters.
• Additional fields used in languages with other character sets to enter core name components in the Roman character set, so they can be shared internationally.

The following name attributes may be needed by specific applications to meet business or statutory requirements. These attributes may or may not be used when the application is translated:

• Title: Brief social titles (often abbreviated), such as Mr., Ms., Herr, or Dr. Titles may also include specific social, academic, or military titles, such as Reverend, Professor, or Colonel.
• Suffix, such as Sr. or Jr., or III.
• Degree: Academic degrees such as B. S., M. A., Ph.D.
• Maiden Name.
• Alias: Used in place of entire name in some circumstances, such as a pseudonym.

Name Format

General Name Format Principles

• Name attributes may be displayed as prompt/data pairs, or as column headers and cells in a table. Both types may be editable or read-only.
• Depending on the application and the type of name data being entered, users may enter names manually, choose a name from a Select Choice list (for small sets of names), or choose a name from an LOV.
• The sequence of name fields depends on whether the fields are displayed in a table or a form layout, and the locale setting in which they are viewed. For details, see Sequence of Name Fields below.
• Use Hint text for text-entry fields that may not be obvious to users, but not for Select Choice lists, where users can select an option. See the Help Framework guideline for details on Hint text. Text fields that may require hint text include:
  • The Degree field for academic degrees—the recommended Hint text is: "Examples: B. A., M. S., Ph.D."
  • The Prefix field for particles that precede the family name—the recommended Hint text is: "Examples: d', de, della, van".
• Names from different national origins may be entered and displayed in an application. They may also be entered in one country or locale, and later displayed in another. When names from different national origins are displayed:
• The number and sequence of name fields displayed in a form or table layout are language and locale dependent. For example, a US English application will display text fields and table columns for name components in the US English sequence, regardless of the origin of name data to be displayed in those fields.
• If a name component from another locale is not available, the data is omitted. For example, it is uncommon to have a middle name or middle initial in Japan.
• When names are concatenated in a single field or table cell, the syntax for concatenation depends on the user's name format preference (either Global or Local). See Concatenation of Name Fields for details.
• If lists of names are to be shared across locales and applications, it is necessary that the three core fields defined above (First Name, Last Name, and Preferred Name) are available in ALL locales for data entry, regardless of whether individuals in a locale have all three name attributes. Otherwise, names of individuals working in other locales will not contain enough data to be distinguishable or to be displayed in greeting format when shared with another locale.
• For example, all three fields must be present in a Hindi (India) translation of an application, even though some people may only have a single name, and have no preferred name.
• In another example, if an American employee named "Robert Jones", who prefers to be called "Bob", is working in a branch office in China, it is necessary to have a Preferred Name field in Chinese applications in which to enter "Bob", as well as the First Name and Last Name fields.
• For languages such as English or French that use titles such as Mr. or Mme., consider including the Title field if the name will be used for written correspondence. This makes it possible to commence with a formal greeting of "Dear {Title} {LastName}", such as "Dear Ms. Jones" rather than the greeting "Dear [FirstName] [LastName]", such as "Dear Bridget Jones".

Sequence of Name Fields

The sequence of name fields depends on whether the fields are displayed in a table or a form layout, and the locale setting in which they are viewed.

Sequence of Read-Only Name Fields

Read-only names may be concatenated in a single field or table cell, or displayed in separate columns in a table.

• Concatenated names are shown in Display, List, or Legal formats, depending on both their location in the UI and the locale setting in which they were created. For details on these formats, see Concatenation of Name Fields below.
• When name components are displayed in separate columns in a table, they start with the person's Last Name to allow useful sorting, regardless of locale; if the Preferred Name field is included, it follows the other name fields. For example, in a US English table, the name column sequence could be: Last Name, First Name, Middle Initial, Preferred Name.

Read-Only Name Fields in a US English Table

Sequence of Editable Name Fields

Editable name fields follow different sequences in form and tabular layouts.

• Form Layouts: Editable name fields generally follow the sequence in which the name is read in the locale, with the Preferred Name field following the last field of the person's full name.
• In a short US English form, the name field sequence would typically be First Name, Middle Initial, Last Name, Preferred Name. In a long US English form, the sequence could be Title, First Name, Middle Initial, Last Name, Suffix, Preferred Name, with other fields (such as Maiden Name) placed afterwards. See the example form images below.
• Note that in certain cases, such as official forms, there may be other sequence requirements. The most common of these is to place the family name first.
• Editable Tables: Editable name fields should always follow the same sequence as read-only tables, starting with the Last Name column, and finishing with the Preferred Name column. See the example table image below.

Editable Name Fields in a Short US English Form

Editable Name Fields in a Long English-Language Form

Editable Name Fields in a US English Table

Locale-Specific Name Format Issues

Depending on locale, both form and tabular layouts of name data can change considerably.

• Number of Attributes: The number of name attributes—such as title, first name, middle name, and last name—change depending on the locale. For example, titles and suffixes are uncommon in Japan. Conversely, the Prefix field is required in France and other continental European countries to enter particles (such as de, de la, etc.) so that names in lists are sorted alphabetically by the last name rather than by the particle.
• Order of Attributes: The order of name attributes also changes depending on the locale. For example, in Korea, the family name precedes the given name. This applies to both the sequence of fields for data entry and presentation of concatenated name attributes in read-only fields. See Concatenation of Name Fields below for more details.
• Required Fields: Fields may be mandatory in some locales and not in others. For example, in the United States, a middle initial is often a required field to distinguish people with the same first and last names; however, this is uncommon in many Asian countries.
• One Word Names: Individuals in some countries, such as India and Indonesia, may only have one name. In this case, the name should be entered in the Last Name field to ensure that it is stored correctly for sharing with other locales.
• Consistency within a Locale: The fields used to enter name attributes should be consistent across the applications within each locale, but will differ from one locale to another. For example, name fields should be consistent in both the Japanese versions of HR applications and the Japanese version of Sales Online.
• Use of Core Fields: Certain locales may use the First, Last, and Preferred Name fields to enter data in their own character sets, and may provide other fields to enter data in international format. For example, in Japan, separate fields are provided for entry of name data that can be shared with the English language applications.
• Phonetic Field: Some ideographic character-based languages, such as Japanese or Chinese, require a phonetic field to help interpret character-based names that can be read in different ways.
• Combined Attributes in a Field: Depending on locale, certain name elements may be entered within a single field. For example, in the United States and United Kingdom, particles that precede the last name are typically entered within the Last Name field, so that names in lists are sorted alphabetically by particle rather than by last name.
• Sort Order: The sort order for a list of names may vary from one locale to another, depending on whether the locale separates the Prefix field. For example, the family name "de Vries" would be grouped with names starting with "v" in France, but would be grouped with names starting with "d" in the United States. Ordering should be case-insensitive.
• Separate Data Entry: Name data from multiple locales must be entered separately to ensure that the form or table contains the appropriate fields or cells, and that the fields are in the correct order for the locale. There are two recommended approaches:
• Use a separate form for each locale. For example, use one form to enter names in US English applications, and a different form to enter names in a Japanese application. This approach is recommended for most cases.
• Use a separate editable table for each locale. This approach is recommended for bulk data entry of records with five or less editable attributes.

Editable Name Fields in a Japanese-style Form

Recommended Fields for US English

In US English forms, many name fields may be omitted as appropriate, depending on the application. However, the sequence of included fields should be consistent across applications, even though the layout may vary. The recommended sequence follows the order in which a full European name is written, such as:

1. Title: Mr.
2. First Name: Charles
3. Middle Initial: L
4. Prefix: de
5. Last Name: Grasse
6. Suffix: Jr.

Common practice in US commercial correspondence is to omit titles, and sometimes suffixes, from addresses on business letters. A general rule is that these fields may be omitted when the name entered in the application will primarily be used in online communication, rather than in formal or legal correspondence.

Other optional name fields should follow the name fields listed above.

The following table details recommended usage of name fields in US English applications:

Field Label	Purpose	Usage	Notes
First Name	Given name.	Required text field.	Allow space for display of a minimum of 12 characters to reduce errors entering longer names. First names may contain spaces or hyphens, such as Jean-Paul.
Preferred Name	Name by which a person is known, either in general or within an organization. Used instead of first name in many contexts.	Required text field. Allows applications to provide "friendlier" welcome messages, and to identify people with the names by which they are known in an organization. People often prefer other names to their first names. Users from locales such as China that have a different name sequence often specify a preferred name that can be displayed before the family name in English language applications.	Includes standard contractions (such as Bob for Robert, and Betsy for Elizabeth), use of middle names, as well as other names. Hint text is required to make the purpose of this field clear, such as "Examples: Betsy, Bob, Liz".
Last Name	Surname.	Required text field.	Allow space for display of a minimum of 15 characters to reduce errors entering longer surnames. Last names may contain both spaces and hyphens.
Middle Initial	Distinguish individuals with common first and last names.	Optional text field, but recommended.	Allow space for a single character.
Middle Name	Distinguish individuals with common first and last names.	Optional text field alternative to middle initial. Required by some US government agencies.	Allow space for display of a minimum of 12 characters to reduce errors entering longer names.
Suffix	Used to distinguish individuals from family members with same name.	Optional text field.	Hint text is required to make the purpose of this field clear, such as "Examples: Sr., Jr., and III". Academic degrees should be entered in a separate field.
Title	Abbreviated or short social title (not Job Title), or honorific social, academic, or military title that precedes the name.	Optional Select Choice list. May be required in some applications to meet statutory requirements.	Examples include "Reverend" and "Colonel." Consider including this field if application data is used to generate form letters. If used in conjunction with organizational title (such as "Director of Engineering"), use the label "Position" for the job-related title.
Degree	Academic degree displayed after the full name and after the suffix, if it exists.	Optional text field. Primarily required in educational contexts.	Examples include B. A., M. S., Ph.D.
Maiden Name	A woman's family name prior to adopting a married name.	Optional text field. Commonly used in government forms, and to verify user ID.	Allow space for display of a minimum of 15 characters to reduce errors entering longer surnames.
Alias	Used instead of full name, such as a stage name or pseudonym.	Optional text field. Required by some government agencies.	Examples include "Marilyn Monroe" and "Sting." Aliases are not used in conjunction with surnames, whereas nicknames may be.

Concatenation of Name Fields

Name components that commonly require concatenation are as follows:

• First Name
• Preferred Name
• Last Name
• Prefix, such as "von" in Werner von Braun, or "de" in Alexis de Tocqueville.
• Middle Name
• Middle Initial
• Suffix

There are three general formats for concatenated names, depending on the type and location of the field in which the name appears. Each format may vary considerably depending on locale and whether the full legal name must be displayed:

• Greeting Format
• Display Format
• List Format

When concatenating names, the following requirements apply to some or all three formats:

• Use of Preferred Name requires that this name element be identified correctly in the database, so it is necessary to provide a separate field for input of the preferred name.
• Some people from countries such as India and Indonesia have only one name. Display only the single name unless a preferred name is specified.
• The Prefix field is not used in US English applications, but is included in the syntax to concatenate names preceded by particles (such as "de" and "Van") that were entered in the Prefix field in localized applications. This field is common in European languages.
• Concatenated names also appear when users are prompted to enter credit or debit card data. In this context, the concatenated name should match exactly what appears on the credit or debit card rather than one of the formats specified below. See Credit and Debit Card Formats for details.

Greeting Format in US English

Purpose:

Welcomes the user.

Description:

The standard US English Greeting format is as follows:

• US English Syntax: {Preferred Name|FirstName} [Prefix] {LastName}
• Examples: "Bob Jones" or "Martin de la Cruz"

Usage:

Greeting format is used only when concatenated names are displayed in the following read-only components:

• Welcome string (such as "Welcome John Doe"), when it does not appear in a header.
• Login stamps that specify the current user's name rather than a login ID.

Login Stamp with US English Greeting Format

Display Format in US English

Purpose:

Identifies people using the name by which they are known in an organization, and shows their names in the order in which they are normally read.

Description:

The standard US English Display format syntax is as follows:

• {Preferred Name|FirstName} [Prefix] {LastName}
• Examples: "Bob Jones" or "Martin de la Cruz"

Usage:

• Display format is used when concatenated names are displayed in the following read-only components:
• Headers (page titles and other levels of header)
• Page stamps
• Context Region
• Read-only prompt/data fields in form layouts
• Lists such as Notifications and Approvers, where rows are not sorted by person name
• Hints and messages associated with these components
• In cases where application pages have unusual space limitations to show name fields, the Display format syntax can be further shortened to: {FirstInitial.} {LastName}, such as "B. Jones".
• If it is necessary to identify people by their full or legal name, the Display format syntax may be modified. The requirements for displaying the full name vary from one country to another. For example, in the United States, applications may need to use the following syntax to meet statutory requirements in some contexts:
• US English Syntax: {FirstName} {MiddleInitial|MiddleName} [Prefix] {LastName} [Suffix]
• Examples: "Robert C. Jones III" or "Martin Rafael de la Cruz"
• Both standard and alternate representations of the name may be used on the same page as long as they are distinguished by their labels. For example, an application could use the labels "Name" and "Full Name" to distinguish the standard Display format from the complete legal name.

Header with Standard US English Display Format

List Format in US English

Purpose:

Identifies people in a list sorted by family name rather than by first or preferred name.

Description:

The standard US English List format is as follows:

• US English Syntax: [Prefix] {LastName}, {Preferred Name|FirstName}
• Examples: "Jones, Bob" or "de la Cruz, Martin"

Usage:

List format is used when concatenated names are displayed in name order in all types of lists, including:

• Select Choice lists
• Shuttles
• LOV choice lists
• LOV dialog
• Tables
• Tree Tables
• Hints and messages associated with these components

• In cases where application pages have unusual space limitations to show name fields, the List format syntax can be further shortened to: {LastName,} {FirstInitial.}, such as "Jones, B."
• When a read-only table contains names from multiple locales, each name must be concatenated within a single cell. Otherwise, name sequences could be inconsistent from one language to another, and column headings could be incorrect for some name attributes. It is recommended to provide a drilldown method to display the complete set of name fields on an object page, as shown in the following read-only table.

Read-Only Table with Concatenated Names in US English

• Editable fields should NOT be used in either form or tabular layouts to enter concatenated names, because:
  • Names from different locales have different sequences, making it difficult for users to sort and locate names from different regions, and to determine which name is the family name.
  • Users cannot be addressed in the more welcoming Greeting format.

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.

• The Global setting displays all concatenated names in an internationally viewable character set and sequence. The resulting concatenated name formats are identical to US English formats, though a customer may choose to mandate another country's name formats for its global operations.
• The Local setting displays all concatenated names in the formats from the country in which they were created. This primary use of this setting is for users who deal mainly with staff in their own country, and who are in countries where the local names are different from the global names. For example, if a user in the United States 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 United States appears on the same page, it would be displayed with the international character set, using US English syntax.

Concatenated Formats in Different Locales

Greeting, Display, and List formats may vary considerably depending on locale. The US English syntax may be used for other languages, especially Western European, but this is a locale-specific decision.

• 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. In the United States, the standard sequence is "Welcome {Preferred Name|FirstName} {LastName}"; other countries/cultures may require the sequence "Welcome {LastName}" instead.
• When concatenating name attributes in Display and List formats, different locales may require both different attribute order and different separators. For example, in the United States, 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 US English application may need to include suffixes to meet national statutory requirements, whereas in France, suffixes are not required.

Examples:

• Japan
• 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"
• 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
• Syntax: [Greeting] {LastName} {First Name}
• 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 treated as one name rather than First Name and Middle Name.
• Examples: "Welcome Dong Guohong"; "Welcome Kwan Sai-Hung"; "Welcome Leung Chau Ha".
• Korea
• 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"; "Welcome KimBogennim"
• Display and List Formats
• Syntax: {LastName}{FirstName}
• Note: No space between Last and First Name.
• Example: "KimKyae-Youngnim"; "KimBogennim"
• Arabic
• Greeting Format
• Syntax: [Greeting] {FirstName} {LastName}
• Example: "Welcome Ahmed Ali"; "Welcome Maher Al-Nubani"
• Display and List Formats
• 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"

Address Formats

Address formats include all elements required for correspondence. Common address fields include:

• Country
• Street Address Lines
• Apartment or Suite Number
• City
• State/Province/Prefecture (typically in a Select Choice list)
• Postal Code
• Alternate Address (phonetic field for ideographic character-based languages—not a second address)
• Address Type (with a Select Choice list containing items such as "Home" and "Work")

Editable Address Format for US English

General Address Format Principles

• Address attributes may be displayed as prompt/data pairs, or as column headers and cells in a table. Both types may be editable or read-only.
• Fields may be concatenated as needed in US English applications and in localized releases. For example, street, city, state, and postal code may be included in a single read-only field or table cell.
• Multiple "Address Lines" may be displayed, but it is recommended not to display more than two for US addresses; addresses in other countries may require an additional line. Note that too many address lines may confuse a user regarding the intention of the field, adding unnecessary or invalid data to the database. Each address line field must have its own prompt, which should be sequentially labeled (for example, Address Line 1, Address Line 2, etc.).
• For US address format, "County" may be optional. "State" should be a Select Choice list of valid two-letter state postal abbreviations.
• In addition to locale settings, all address fields are dependent on the "Country" choice list. The "Country" Select Choice list is the first prompt/data pair. When selected, the other prompt/data pairs redraw based on the selected country's address format standards.
• Do not use periods in abbreviations for country names. For example, use "US" and "UK", not "U.S." and "U.K."
• The Country Select Choice list and editable address formats should default to locale settings until another country is selected. Read-only address formats should retain country address order.

Read-Only Address Format for US English

Locale-Specific Address Format Issues

Depending on locale or country selection, both form and tabular layouts can change considerably:

• Number of Attributes: Some address attributes are country-specific. For example, five- and nine-digit postal codes are used in the US 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 local region name (referred to as a department in French) because it is specified by the first two letters of the postal code.
• 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.
• Required Fields: Fields may be mandatory in some countries and not in others. For example, in the United States, if an address is required, then a postal code is a required field, whereas a postal code may be optional in other countries.
• Choice List of Cities: Some countries, such as Japan, may provide a Select Choice list for the City field.
• Phonetic Field: Some ideographic character-based languages, such as Japanese, require a phonetic field to help interpret character-based addresses.
• Concatenated Addresses: When concatenating address attributes, different countries may require both different attribute order and different separators. For example, in France, the postal code and city name are separated by a space; in Australia, the state and postal code are separated by a comma; and in the United States, the state and postal code are separated by one or two spaces.
• Addresses in Read-Only Tables: When a read-only table contains addresses from multiple locales, all address attributes except Country must be concatenated in full within a single cell. Otherwise, address sequences may be inconsistent from one locale to another, and column headings may be incorrect for some address attributes. The Country attribute may also be concatenated with the address, if sorting by country is not needed.
• Separate Data Entry: Address data from multiple locales must be entered separately to ensure that the form or table contains the appropriate fields, and that the fields are in the correct order for the locale. There are two recommended approaches:
• Provide a country Select Choice list above an address form. The choice list displays a separate form for each locale. For example, enter US addresses in one form, and French addresses in another. This approach is recommended for most cases.
• Provide a country Select Choice list with a context-specific label above a read-only table of addresses. The choice list then navigates to a separate editable table for each locale. This approach is only recommended for bulk data entry of records with five or less editable attributes. Additional attributes may cause horizontal scrolling, and increase the risk of data entry error.

Generic Editable Japanese Address Form

Read-Only Table with Addresses From Multiple Locales

Use of Country Select Choice List To Add Addresses From Multiple Locales

Editable Address Fields in a Single-Language Table

Personal Attributes

Applications may need to collect or display personal data about individuals. In each case there must be a valid reason for doing so, as personal data is sensitive and may have both public relations and legal implications.

One common example is gender. The context must clearly require that users identify their gender, or must provide gender-specific facilities, such as scholarships that are only available to women. In other contexts, requesting gender information can be construed as intrusive, or even discriminatory. The same issue applies to race, ethnicity, and religion. Other less sensitive attributes, such as marital status, should also be omitted unless required by context.

Letter Formats

Some Oracle products create letters that are sent to customers or are used for government reporting. Teams may choose from a variety of greetings and closings appropriate for business letters, except where directed by government entities to follow particular formats.

• Some commonly used US business letter salutations include:
• Dear Sir:
• Dear Madam:
• Dear Sir or Madam:

• Some commonly used letter closings include:
• Sincerely,
• Respectfully,
• Yours truly,

Telephone Number Formats

A country may have multiple valid telephone formats, with varying numbers of digits, numbers of segments, and different delimiters. Also, telephone number formats vary between countries. For example, area codes are not used in some countries such as France, whereas they are commonly used in the United States and Canada. Consequently, the fields used for displaying and capturing telephone information may differ, depending on the selected country. For example, the country may be selected through a "Country Code" LOV choice list among other possible dependent fields.

• Although telephone number formats can widely vary, they typically share the following common elements:
• Country Code
• Destination Code (DC) or National Destination Code (NDC), sometimes referred to as Area Code or City Code
• Subscriber Number (sometimes referred to as Local Number)
• Extension (for each telephone number)
• The Subscriber Number is the core segment of the telephone number that exists in all telephone number formats. Country code is required when telephone numbers outside the default locale are exposed in the current view. Other parts of the telephone number are optional, depending on locale and business requirements. For instance, in France, the National Destination Code does not exist as a distinct number and is therefore not used. Also, the Extension field may be used only in applications that typically require capturing business telephone numbers that have PBX extensions.
• Telephone number segment labels may differ from their officially designated names based on locale; for instance, in the US and Canada, the National Destination Code would be labeled as Area Code.
• Product teams may provide additional, separate telephone fields to capture product-specific telephone information, which can include the type of telephone number or how the telephone number is used (for example, Mobile, Work, Home, Main, Preferred Time To Call, etc.).
• The telephone field should support alphanumeric values (for example, "1-800-CAR-SALES"). The alphanumeric value should be stored as a numeric equivalent, but its display may be controlled by a user preference, for instance, choosing to display alphanumeric where available.
• Numeric equivalents for alphanumeric telephone numbers intended for dialing should be available for all layouts. Also, whenever possible, users should be able to specify, through preferences, how the numeric equivalent should appear. For instance, the numeric equivalent may be appended after the alphanumeric telephone number and enclosed in brackets [].
• Telephone number delimiters and formats should be configured by localization teams, and provided as configurable preference options for end users. The following table lists valid formats for US English applications (other locales will have different formats):

US Format	Delimiter Type	Example
+xxxyyyzzzzzzz	No delimiters	+16505551212
+xxx-yyy-zzz-zzzz or +xxx-yyy-zzzzzzz	Dash	+1-650-555-1212 or +1-650-5551212
+xxx(yyy)zzz-zzzz or +xxx(yyy)zzzzzzz	Parentheses, Dash	+1(650)555-1212 or +1(650)5551212
+xxx yyy zzz zzzz or +xxx yyy zzzzzzz	Space	+1 650 555 1212 or +1 650 5551212
+xxx (yyy) zzz zzzz or + xxx (yyy) zzzzzzz	Parentheses, Space	+1 (650) 555 1212 or +1 (650) 5551212

• If a user enters a telephone number containing a fixed number of digits for a given country, and the country has multiple valid telephone formats for a fixed number of digits, the number should automatically be converted to the format selected by the user in preferences, or the default format if user preferences don't exist. Product teams should set the default based on locale. The conversion should occur when the user submits the form.
• When a telephone number is accompanied by a country code, it may be preceded by a plus sign ("+") based on localization requirements.
• When used in a multiple field layout (see next section), the Country Code should be an LOV choice list and should be shown as the first prompt/data pair.
• When a country code is selected, the source page or section should partially refresh to show the appropriate telephone number and related fields based on the selection.
• The options list panel in the LOV choice list should display two columns: each row should display a country code in the first column, and the corresponding country name in the second column. The entire list should be ordered alphabetically based on country name.
• The country name does not display when the LOV choice list is read-only.

Telephone Field Layouts

• Telephone field layouts may be arranged as single line/single field, single line/multiple fields, or multiple line/multiple fields, depending on factors such as:
• Page layout
• Additional telephone attributes desired
• Efficiency of interaction
• Optional action buttons, for features such as click-to-dial or editing telephone fields in a secondary window, may be provided by product teams.
• An optional Full Details action may be exposed to allow the user to launch a UI (such as a dialog) to show all telephone fields, in multiple lines, that the user can view or edit.
• In edit mode, the Extension field should be a separately labeled field from the telephone number. The label for the field is "Extension" or abbreviated as "Ext." In read-only mode, the Extension number should be appended after the telephone number, separated by a comma.

Single Line/Single Telephone Field

The single line/single telephone field layout is preferred in most cases, since it is more efficient for the user to enter telephone information into a single field than as segments in separate fields.

• The single line/single telephone field layout is recommended when:
• The consuming team has a parsing engine for telephone number formats, or
• The telephone number is intended to be stored in its entirety as a single string and not as individual parts, or
• The page or section uses a layout where a stacked multiple-line arrangement may not be feasible. For instance, there may be several instances of telephone fields on a page, so showing each in a stacked multiple-line layout may lengthen the page considerably and cause excessive vertical scrolling.
• Product teams can customize the label so that it is specific to the context or intent of the number, for example, "Work Number" or "Home Number".

 

Example of Single Line/Single Telephone Field Layout in US (Editable and Read-Only States)

Single Line/Multiple Telephone Fields

• The single line/multiple telephone field layout is recommended when the user may not be familiar with the telephone number format for a certain country. In this case, the user can select from the Country Code LOV choice list, then enter the destination code and telephone number into separate fields.
• Product teams can customize the label so that it is specific to the context or intent of the number, for example, "Work Number" or "Home Number".

 

Example of Single Line/Multiple Telephone Field Layout in US (Editable and Read-Only States)

Multiple Line/Multiple Telephone Fields

• The multiple line, multiple telephone field layout is recommended when:
• Additional attribute information relating to a telephone number is needed (for example, Fax, Best Time to Call, Telephone Number, etc). Product teams may encapsulate the telephone fields within a page or section.
• The telephone number cannot be parsed as a single text string to match a recognized format, and the user needs to re-enter it as individual segments. For instance, if the user entered a telephone number as a single text string in a single field layout, but the field does not recognize it, a secondary window may appear, prompting the user to enter the telephone number in multiple fields.
• The label for the subscriber number should be labeled generically as "Telephone Number" in the header to provide more context. For instance, if work number fields are shown, the header may be "Work Number". If a full set of telephone and additional detail fields is shown, the header may be "Full Telephone Details".

Example of Multiple Line/Multiple Telephone Field Layout in US (Editable and Read-Only States)

Date Formats

Standard date formats include:

• Full date
• Year
• Month
• Week
• Day
• Date ranges
• Fiscal Quarter
• Periods in educational institutions
• Periodicity (period length, such as weekly, monthly, or quarterly, and so on)

General Date Principles

• Date and time elements consist of either editable or read-only fields, and conform to the guidelines for those types of fields. See the Input/Choose Date guideline for details.
• Date and time elements may also be displayed as Page Stamps. Time zone can be included in a page stamp if it is not system generated.
• Date formats vary depending on user preferences and locale settings.
• Parentheses should not be used in date units; for example, use "days" instead of "day(s)" and "months" instead of "month(s)".
• Some countries, such as Japan, may use a national calendar in addition to the international calendar. In the case of Japan, this requires an additional "Era" field.

Full Date

Purpose:

Specifies a complete date within a single field.

Usage:

• A full date field should always be associated with a Input/Choose Date Selector. See the Input/Choose Date guideline for details.
• The Input/Choose Date Selector is associated only with full date fields, and cannot be used with separate month, year, or period fields.
• The format of the specific date defaults to the application locale setting. Users can then set preferences for date options available within that locale. Examples of date formats used in the United States are listed in the following table; date formats for other countries are also supported.
• The internationally-recognized date format dd-MMM-yyyy should be the default full date format.

Format	Example
mm-dd-yyyy	01-28-2011 ***
MMM-dd-yyyy	Jan-28-2011
MMM-dd-yy	Jan-28-11
dd-mm-yyyy	28-01-2011 ***
MMMM dd, yyyy	January 28, 2011
dd-MMM-yyyy	28-Jan-2011
yyyy-mm-dd	2011-01-28 ***
yyyy-MMM-dd	2011-Jan-28
EEEE, MMMM dd, yyyy	Sunday, January 28, 2011
EEE, MMM-dd-yyyy	Sun, Jan-28-2011

Editable Date Field in US English (EEEE-MMMM-dd-yyyy format)

Full Date and Time

A date can optionally display time information. The date should always appear as the first element, followed by a space and the time, as shown in the following example:

Full Date and Time Field in US English

Unless a time is specified, all calculations based on date elements are based on the time of midnight for the start of that day. For example, an application provides a running total of days elapsed since the start of a project. If no time is specified along with the start date, the application will add a day to the running total after midnight each day; if a time is specified with the start date, it will use that time each day as the reference to update the running total.

For more information on time and time zones, see Time Formats below.

Separate Date Fields

Applications may need to display the year, month, week, or day independently of a full date field. In this case, product teams can provide separate or standalone fields for this information.

Year

Purpose:

Specifies a year within a single field.

Usage:

Standalone year fields should be as follows:

• Years in standalone year fields should always be displayed with four digits.
• Read-only year fields should follow standard prompt/data format.
• Editable year fields should be spin boxes or Select Choice lists. Use a choice list when:
  • Ranges have fewer than 10 values, OR
  • Some years within the range displayed are invalid in the current context.

Read-Only and Editable Year Options

Month

Purpose:

Specifies a month within a single field.

Usage:

Standalone month fields should be as follows:

• Read-only month fields should follow standard prompt/data format.
• Editable month fields should be Select Choice lists. Lists should only display valid months for the current context.
• Standard abbreviations for months may be used in both read-only and editable fields.
• When the range of valid months bridges more than one calendar year, it is necessary to indicate the year. Put the year after the month, for example, "December 2010".

Read-Only and Editable Month Options

Week

Purpose:

Specifies a week within a single field.

Usage:

Standalone week fields should be as follows:

• Read-only week fields should follow standard prompt/data format.
• Editable week fields should be spin boxes or Select Choice lists. Use a Select Choice list if some weeks within the range displayed are invalid for the current context.
• Users may need help to determine when a week starts and ends. Standard English language calendar format shows weeks starting on Sunday, whereas other countries show weeks starting on Monday. In addition, a project planner may track from the start of the work week, and a contractor log may track from the end of the work week. The recommended method of providing help is different for read-only and editable fields:
  • Read-only fields: The label should specify "Week Starting" or "Week Ending" and the full date in the format specified by locale and preferences.
  • Editable fields: Use instruction text, or hint text to specify the starting or ending day of the week. For example "Week = Work week starting on Mondays"

Read-Only and Editable Week Options

Day of the Week

Purpose:

Specifies a day of the week within a single field.

Example:

A meeting scheduling application may allow users to specify a day of the week on which to hold a weekly, bi-weekly, or monthly meeting.

Usage:

Standalone day-of-the-week fields should be as follows:

• Read-only day fields should follow standard prompt/data format.
• Editable day fields should always consist of a Select Choice list, listing up to seven days of the week. Lists should only display valid days for the current context. For example, departmental meetings may only occur on business days.
• If certain days of the week are excluded from a list, product teams should indicate the reason in instruction text, or hint text.

Number of Days

Purpose:

Specifies a number of elapsed or projected days within a single field.

Examples:

• A scheduling application may indicate the number of calendar days elapsed since commencement of a project or an individual task.
• A project management application may provide an updatable field for users to enter the projected number of work days to accomplish a task.

Usage:

Standalone number-of-days fields should be as follows:

• Read-only day fields should follow standard prompt/data format.
• Editable day fields may be spin boxes or Select Choice lists:
• Spin box: For most cases.
• Select Choice list: If valid values are irregular, such as the number of days associated with different shipping methods (3, 7, 15, 30).
• The field should have a distinctive label, such as "Days Elapsed".
• If the count of days is based on a measure other than calendar days, such as work days, both read-only and editable forms should indicate the measure in instruction text, or hint text.

Read-Only and Editable Day Options

Fiscal Quarter

Purpose:

Divides an organization's fiscal year into periods of three months to track financial status.

Usage:

• Fiscal quarters are used by organizations in the United States and some other countries. Fiscal quarters are unknown in many countries, such as Japan.
• Fiscal quarters may match calendar quarters or be offset by several months, in which case they span two calendar years. In this case, the start or end of the fiscal year should be specified on the page.
• Read-only fiscal quarter fields follow standard prompt/data format, but should specify the year as well as the quarter. For example: "Quarter 3 2010" and "Quarter 4 2010".
• Editable fiscal quarter fields typically consist of a Select Choice list, but may also consist of a Select Radio group or check box group to select more than one quarter.
• Do not abbreviate "quarter" to "Q" or "Qtr", as these abbreviations have no equivalents in many languages.
• If business rules cause some quarters to be invalid in the current context, hide those options in most cases. If the options are available in other contexts, product teams may disable the options instead of hiding them, to indicate this availability to the user.
• In editable fields, the format for calendar quarters is different from fiscal quarters that span two calendar years:
• Calendar quarters may specify the year in a separate year field.
• Offset fiscal quarters must specify the year within the quarter field.

Read-Only and Editable Fiscal Quarter Options

Periods in Educational Institutions (Semester/Trimester/Quarter/Session)

Purpose:

To specify an academic period.

Usage:

Educational institutions typically divide years into semesters, trimesters, or quarters. Other educational organizations may also break the year into sessions. In the United States, academic years usually bridge two calendar years and are identified by concatenating the years, such as "2010-2011 Academic Year". Valid formats vary greatly between institutions; however, the following guidelines are generally applicable:

• The terms Semester, Trimester, and Session may not be abbreviated in either read-only or editable fields, but should be written in full, such as "Semester 1" or "Fall Semester".
• A page containing educational periods must always identify the starting month of the period. This can be accomplished in either of two ways:
  • By including starting months in Select Choice lists or Select Radio button labels. For example, a form may list choices such as "Semester 1 September 2007" or "Winter Quarter January 2008".
  • By providing this information in instruction text or hint text, such as "First Semester = September 2007 - January 2008".

Academic Period Options with Months Specified

Date Ranges

Purpose:

To specify a duration between a start and end date, or a start and end period.

Usage:

• Date ranges consist of two date or period fields, with one or two labels.
• The date range display order is "[minimum date] - [maximum date]". The order does not change when the range is translated.
• Read-only date range fields should always be placed side-by-side and separated by a hyphen.
• Read-only labels should indicate duration, such as "Project Duration" or "Review Period".
• Editable date range fields may be placed side-by-side or stacked vertically. The first field is typically labeled "From", and the second field is typically labeled "To".
• When using the labels "From" and "To", it is necessary to provide context in a subheader component or read-only field that specifies the current date range. For example, the date range for a fiscal quarter might have the section header, "Specify Fiscal Quarter". Alternately, the date range might appear below a read-only field, labeled Fiscal Quarter, that specifies the start and end dates of the quarter.
• If the date range fields are not close to the section header, it is necessary to provide more context in the field labels. For example, instead of "From", use "Project Start", and instead of "To", use "Project Completion".
• Labels for both read-only and side-by-side editable date ranges may consist of application-specific terms indicating the beginning and end of a period.
• If business rules cause some dates and periods to be invalid in the current context, hide those options in most cases. If the options are available in other contexts, product teams may disable the options instead of hiding them, to indicate this availability to the user.
• Editable fields for ranges of full dates should include an Input/Choose Date selector next to each field.
• Side-by-side editable fields for ranges of full dates should include hint text under the first field in each section of the page, but omit it from the second field, and from subsequent fields in the section.
• Common date ranges include:
• Start date - End date, such as Oct 12, 2007 - Dec 12, 2007
• Start week - End week, such as Week 24 - Week 27
• Start month - End month, such as December 2007 - January 2008
• Start year - End year, such as 2007 - 2008
• A date range can have optional explanatory text, such as Week Number or Period. The text is appended after the date or date range and is enclosed in parentheses. For example:
• 28-Jan-2008 (Week 1)
• January 01, 2008 - May 30, 2008 (Spring Semester)
• 21-Jan-2008 - 28-Jan-2008 (Weekly)
• Date ranges may also be combined with Editable Time Formats to specify both start and end dates and times.

Side-by-Side Date Range Options

Stacked Date Range Fields

Periodicity

Purpose:

To allow users to choose a type of period, such as Quarterly or Annually.

Usage:

Periodicity fields consist of Select Choice lists or Select Radio buttons. If users are expected to be familiar with the term, such as in Business Intelligence applications, the label can be "Periodicity". Otherwise the label should be "Period Length". Period types include:

• Daily
• Weekly
• Monthly
• Quarterly
• Annually
• Semester/Trimester (in academic environments)

Periodicity Field as a Select Choice List

Time Formats

Date and time formats vary depending on user preferences and on locale settings, and whether fields are editable or read-only. 12- and 24-hour time formats are distinguished by the presence or absence of AM/PM.

Time formats consist of up to five fields:

• Hours
• Minutes
• Seconds (optional)
• AM/PM (for 12-hour time only)
• Time Zone (optional)

Time fields may also be combined with a Number of Days field to form a duration format, showing time elapsed since a pre-defined start point.

Read-Only Time Formats

Purpose:

To allow users to view a time entry.

Usage:

Read-only time formats follow standard prompt/data guidelines, except when displayed as time stamps. 12-hour formats are distinguished from 24-hour formats by appending a mandatory AM/PM field. 12-hour formats should be displayed with three numbers, such as 7:30 (plus the AM/PM field), until the hour reaches 10:00.

Time

12:59 AM 12:59:23 AM 00:59 00:59:23 PM 00:01:02

12- and 24-Hour Read-Only Formats

Editable Time Formats

Purpose:

To allow users to edit a time entry.

Usage:

• Editable time formats consist of separate Select Choice lists for hours, minutes, and seconds, separated by colons. Seconds are optional.
• 12-hour formats are distinguished from 24-hour formats by appending an AM/PM Select Radio group or by adding AM/PM to the hours listed in the Hours Select Choice list. AM/PM options must be present for 12-hour formats.
• The decision to use 12 or 24-hour time formats depends on both industry and domain, and on locale. US applications for non-technical users typically employ the 12-hour format because it is more familiar to those users; however, French applications for non-technical users commonly use 24-hour format. Some industries, such as the airline industry, use 24-hour formats in professional applications, but use 12-hour formats for US self-service ticket reservations.
• Both minutes and seconds may be listed in full from 00 to 59 or in increments of five, depending on application requirements. Minutes and seconds must show a leading zero for values less than 10 (for example, "09"). In 24-hour formats, the hour must also show a leading zero for values less than 10.
• Editable time fields may be displayed on the page or in either the Select Time or Select Date and Time dialogs. See the Input/Choose Date guideline for details.
• When time is displayed together with a date in a single field, the field should always be associated with a Input/Choose Date Selector.

12- and 24-Hour Editable Format Options

Duration

Purpose:

To show the time elapsed since a pre-defined starting point.

Description:

The duration is expressed in the following syntax:

ddd Days hh:mm:ss

Example:

A database management application could use the following read-only format to specify how long a server has been up:

Uptime

23 Days 13:45:23

In the example above, "Uptime" is an application-specific label, "Days" is a fixed label, "23" is a numeric field, and "13:45:23" is a time field. Note that "Day" (singular) should be used to denote a single day.

Usage:

If applications need to enable users to specify a duration, use one of the following approaches:

• To specify a fixed amount of time, use a Read-only Time Format in 24-hour format. If the time elapsed exceeds 24 hours, add the number of days before the field.
• To specify a start and end time, combine two sets of read-only time fields, using the same approach as Date Ranges. If the start and end times are scheduled for any time outside of the current 24-hour period, combine the read-only time fields with Date Range fields.

Time Zones

Time zones are arbitrary geographical regions formed by a combination of longitude and politically-designated boundaries, such as national and state or provincial borders. By international convention, time zones are represented by a number of hours ahead or behind Coordinated Universal Time (UTC). Time zone principles are as follows:

• UTC vs. GMT: UTC was formerly known as Greenwich Mean Time (GMT), but the latter term is being phased out internationally. (Microsoft Windows continues to use GMT, but both Java and Oracle documentation use UTC.)
• Regional Terms for Time Zones: Countries which spread across many degrees of longitude determine where time zone boundaries occur within their territory, and typically use local terms for those zones. For example, the contiguous United States is generally divided into four standard time zones, Eastern, Central, Mountain, and Pacific. When displayed, regional terms must always be spelled out in full and never abbreviated, as regional abbreviations may be identical to abbreviations used in other countries. For example, "EST" denotes five hours behind UTC in English-speaking North America, but it denotes 10 or 11 hours ahead of UTC in Australia.
• Daylight Savings Time: Many countries and regions in higher latitudes choose to switch to Daylight Savings Time during summer months, thus advancing by one hour. States or provinces that choose not to switch, such as Arizona or Hawaii in the United States, may have their own time zone.
• Servers should keep track of whether Daylight Savings Time is in effect or not, and adjust times and dates accordingly.
• Daylight Savings Time is not indicated in the UI of Oracle products. The UTC offset of a time zone never changes (for example, "Pacific Time" is always UTC-8:00); however, the actual time displayed on the page reflects Daylight Savings Time when it is in effect.
• No Concatenation of Regions: Oracle's time zone entry for each city, country, or region is based on the US Navy Observatory listings. Even though some cities, countries, or regions may share a common time differential from UTC, they should not be concatenated into a single time zone arbitrarily. Some countries may choose to implement Daylight Savings Time; others may not, or may implement it on different dates. For example, in 2007, the United States and Canada moved the start of Daylight Savings Time to an earlier date, but Mexico did not. If Saskatchewan Time, US Central Time, and Mexico City Time had been concatenated as a single region, then it would have been very difficult to identify the customers affected by the daylight saving change. If the correct time zone is assigned at the beginning, then such time zone migration will not be necessary.

Time Zone Display Formats

Editable Time Zones

Purpose:

Allow users to modify a time zone.

Usage:

Users select a time zone from a Select Choice list. Entries are ordered by offset from UTC. For example:

• (UTC-12:00) Eniwetok, Kwajalein
• (UTC-11:00) Midway Island, Samoa
• (UTC-10:00) Hawaii
• (UTC-09:00) Alaska
• (UTC-08:00) Pacific Time
• (UTC-07:00) Arizona
• (UTC-07:00) Mountain Time

Read-Only Time Zones

Purpose:

Allow users to see a time zone.

Usage:

In read-only regions—such as page stamps, prompt/data layout, or table cells—time zones are displayed in one of the following formats. Depending on available space and user familiarity with time zones, developers may choose between Full, Medium, and Short length formats:

• If all date-time fields on the page represent the same time zone, and the user needs to know the time zone, use a page stamp with the label "Time Zone":
  • Full format: "(UTC-8:00) Pacific Time"
  • Medium format: "Pacific Time"
  • Short format: "UTC-8:00"
• If date-time fields on the page are not part of the user's time zone, or represent different time zones, then the time zone must be displayed after each date-time field:
  • Full format: "2:00 PM (UTC-8:00) Pacific Time"
  • Medium format: "2:00 PM Pacific Time"
  • Short format: "2:00 PM (UTC-8:00)"

Time Zone in Page Stamp

Read-Only Time Zone in Label/Data Format

Read-Only Time Zone in a Table

Recommendations for use of each time zone format are as follows:

• Use Full format to distinguish time zones from the same region as well as from different parts of the world. This minimizes the risk of users misinterpreting the time zone, and is generally the preferred format.
• Use Medium format to distinguish time zones that all come from the same region, if space is limited on the page, and users readily recognize those regional time zone names. For example, Medium format can be used if an application displays time data only from English-speaking North America, or an application displays time data only from the European Community.
• Use Short format if an application will display time data from time zones in different parts of the world, if space is limited on the page, and the application's users will recognize the UTC offset without reference to regional time zone names.

Numeric Formats

• Numeric elements may appear in editable or read-only fields or table cells, and should conform to the guidelines for those types of fields.
• Numeric formats vary depending on application locale settings, as defined in user preferences. For example, in the United States, decimal fractions are preceded by a period; in many European countries they are preceded by a comma. Conventions for thousands separators also vary with locale (the United States uses a comma; other countries use a period).

• Numbers may appear in three types of fields or table cells:
  • Text: No calculations are permitted
  • Alphanumeric: No calculations are permitted
  • Numeric: Calculations are permitted

• Users should be allowed to change some numeric formats in their preferences. For example, negative numbers can be displayed with a minus sign (-20) or in angle brackets <20>. Users should also be allowed to set preferences to display thousands separators—either as a comma or a period.
• In certain cases, numeric and alphanumeric data cannot be displayed in read-only fields or cells. Depending on the case, the field may be left blank, or filled with a substitute element:
• If no data has been entered in the field, the read-only field should be blank, except when providing confirmation at the end of a process. In this latter case, the field or cell should contain the text "(no value)" to draw the user's attention to a possible omission. The text "(no value)" is especially important when a process replaces a prior or default value with a blank entry.
• When the data entered in a field is outside the range of adjacent data, the field should contain a hyphen "-". For example, in a page where values are scaled in thousands, an entry of 40 in one field is below the minimum range, and the field should contain a hyphen.
• Editable numeric fields and cells should have hint text to constrain users to enter data that is valid in the current context. If the value entered exceeds maximum or minimum values, the application should generate an error message. See the Message Framework guideline for details.
• It is not recommended to use abbreviations such as "K" (for thousands) and "M" (for millions) as these are not translatable into all languages.

Use of "Percent" and "%" Symbol

• When values are expressed as percentages, the percent sign (%) must always be associated with the values. Rules for display of percent signs (and other units of measure) differ between form and table layouts.
• In form layouts:
• Teams using a number converter to represent a percentage should append the percent sign to the end of fields (without parentheses), instead of appending them to field labels or data.
• Teams using a percent converter should not put a "%" symbol after the field, or the result will be a duplication of the symbol.
• Whether using the percent converter or a number converter in fields, teams should use their choice consistently throughout the application.
• In table layouts:
• Teams using a number converter to represent a percentage should append the percent sign to the column header (within parentheses). Teams using a percent converter should not put a percent sign in the column header.
• Teams should consider how choosing to use a percent converter within table headers and cells can widen columns or contribute to clutter and overall page density.

For Field Labels	For Column Headers	Incorrect Use
Discount [ ] % (with [ ] representing the field itself)	Discount (%), or Total Returns (%)	Discount % taken

• In labels, spell out "percent" when it appears with a number, and use "percentage" when associated with unspecified quantities.

 

Context	Correct Examples	Incorrect Examples
When used without a number (percent)	Percent Complete	% Complete
When used without a number (percentage)	Discount Percentage Taken	Discount % Taken
When used with a number	50 Percent	50%
When used with an unspecified quantity	Percentage of Eligible Salaries	Percent of Eligible Salaries

Non-Numeric Range Formats

When defining ranges for non-numeric attribute entities, it is recommended that labels for the starting and ending range fields be specified as "From {attributeName}" and "To {attributeName}", respectively.

• For instance, if the attribute is given as "Employee Name", then the starting range field label should be labeled as "From Employee Name", and the ending range field label as "To Employee Name".

Currency Formats

• Depending on context, currency information may appear standalone on a page, in a section of a page, in a subsection, or within a table cell.
• Currency formats follow the numeric formats specified in user preference and locale settings. For example, in the United States, 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 (the United States uses a comma; other countries use a period).
• Do not use currency symbols such as "$". Instead, use full currency designators, such as "United States dollars", or currency abbreviations, such as "USD", together with a currency key to explain the abbreviations. See the Key Notation section of the Headers guideline for information.
• A currency symbol may not be exclusive 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.
• Currency symbols may pose translatability problems, as not every currency symbol character is available in each language's character set.
• Multipliers and scaling should be defined with scaling keys and can be placed within hint text or instruction text messaging. See the Key Notation section of the Headers guideline for information regarding placement and usage. Due to Internationalization requirements, each key may contain only one definition. For example, the phrase "Amounts in {thousands} of {United States dollars}" contains two definitions, which makes it difficult to translate. If this information is needed, provide two separate keys—one for currency and one for scale. Scaling exceptions must also be noted, such as "Amounts in thousands, except per share data".
• When currency values are displayed vertically, such as in a table column for comparisons or totaling, the decimal position should be in the same location for each value so that they align. To achieve this, specify the number of positions to display after the decimal point for the entire column, as shown in the following example.

Use of Decimals in a Table with Mixed Currencies

Identifying Currency Abbreviations

• Currency designators can be identified using currency keys, which can be placed within task stamps, as instruction text beneath a header component, in pop-up dialogs or Help messages accessed through a Help icon. See the Key Notation section of the Headers guideline for information regarding placement and usage.
• When only one currency is used in the page, identify the currency. For example, "Currency in United States dollars", or "Currency in Japanese yen".
• When multiple systems are used, use abbreviations and define each abbreviation. For example, "USD = United States Dollar", and "EUR = Euro".
• When defining multiple abbreviations, it may be necessary to place the definitions in a Panel Box or in a dialog launched from either a Help icon or instruction text link, depending on the number of definitions required:
• The instruction text and the link that launches the currency key dialog can be provided in the referring page as: "For an explanation of the currency codes used in this page, see the currency key."
• When only one currency system is used in the page, an alternative to using a currency key is to append the unit of measure to a header, such as "Gross Receipts 2010 (United States Dollars)".
• Currencies follow the same display rules as Weights and Measures.

Currency Key in Message Dialog

Currencies in Form Layouts

• In form layouts, currency abbreviations may be provided as a trailing label (without parentheses), or appended directly to data. For example: a field could have the value "1000 USD" or the value "1000" followed by the label "USD" or "United States Dollars".
• Where conversions are needed for individual fields, the converted amount can be appended within parentheses after the original amount. In this case, the currency abbreviation must be appended directly to the data so it precedes the conversion in parentheses. For example: "1000 USD (910 EUR Approximately)".
• When showing currency abbreviations in a Select Choice list in a Form Layout, the recommended width for the box is seven characters (ems) or 40 pixels.

Currency in Editable Form Layout

Currency in Editable Form Layout with Key Notation

Single Currency with Conversion in Read-Only Form Layout with Key Notation in Help Message

Multiple Currencies in Read-Only Form Layout with Instruction Text and Scaling

Multiple Currencies in Editable Form Layout with Instruction Text

Currencies in Table Layouts

In tables, the placement of currency abbreviations depends on whether the column data is homogeneous or heterogeneous:

• Homogeneous Data: Append the currency designator to the table column heading, within parentheses, such as "Accounts Receivable (EUR)" or "Sales (JPY)". Long currency designator terms may be abbreviated as long as the abbreviation is defined using an appropriate key as described in the Key Notation section of the Headers guideline.
• Heterogeneous Data:
• If multiple currencies are used, consider normalizing the data with a single currency. In this case, it may be necessary to provide Select Radio buttons or a Select Choice list where users can specify the currency to display, and refresh the table with the converted currencies. This approach is useful when users need to view all data using a single currency, such as in analytical applications.
• When users need to see multiple records in two currencies at the same time, rather than performing conversions for each currency, consider using a separate column for each currency, and providing conversions in the columns that would otherwise be blank. For example, data that was entered in Euros would appear in a column labeled "Sales (EUR)", and the converted data would appear in a column labeled "Sales (USD)". This approach is only feasible in tables with few currencies and few columns of data; otherwise, the additional columns can cause horizontal scrolling.
• When it is necessary to display multiple currencies in a single column of a read-only table, append currency abbreviations to data in each cell in a column (without parentheses), such as "43,000 USD". Columns with appended currency designators should not wrap. Abbreviated currency designators may be defined using appropriate currency keys as described in the Key Notation section of the Headers usage guidelines.
• An editable table may provide a column of Select Choice lists for users to specify currencies: The Select Choice lists contain valid currency designators based on international standards. For example, values could be entered in a column labeled "Quantity", and the adjacent column labeled "Currency" would contain choice lists of currencies. When the same table is displayed in read-only mode, that column should be retained, with currencies displayed in read-only text to avoid reformatting the table when switching between editable and read-only modes.
• When a table contains multiple currencies, currency symbols should be repeated in each column header and total cell to avoid user error.

Currency in Read-Only Table Layout

Currency in Read-Only Table Layout with Key Notation

Currency in Read-Only Table Layout with Key Notation and Scaling

Currency in Editable Table Layout

Currency in Editable Table Layout with Currency Key Notation and Scaling

Multiple Currencies in Read-Only Table Layout with Instruction Text and Scaling

Multiple Currencies in Editable Table Layout with Instruction Text and Scaling

Credit and Debit Card Formats

Description:

Credit and debit card information consists of a combination of name, address, telephone, numeric, and date fields. Common field labels are as follows:

• Card Type - Select Choice list
• Card Number - text field for credit cards
• Account Number - text field for both credit and debit cards
• Expiration Date - separate month and year Select Choice lists
• Cardholder Name
• Card Verification Value/Code (CVV2/CVC2) - text field for both credit and debit cards. Required in Europe. The length should be three characters, or four if American Express is accepted.

Usage:

• The "Card Type" and "Card Number" fields may be abbreviated to "Type" and "Number" if they appear directly below a section header that includes the term "Credit Card".
• The Card Number field should accept spaces as delimiters, because this helps reduce both data entry error and time spent checking the entry, and replicates the format commonly used on cards.
• Provide an example in hint text to indicate whether the Card Number field accepts spaces or hyphens (-) as delimiters.
• If the Card Number field accepts delimiters, the field must have space for 19 characters (16-digit card number plus three delimiters)
• Choice lists are used for the Year field because there is generally a small range of valid years for expiration dates.
• Certain cards may require other fields. The page should partially refresh to show these fields when the user selects the Card Type.

Weights and Measures

The term "weights and measures" covers a broad spectrum of measurement types, such as mass, distance, and volume. In general, there are two systems of measurements in broad commercial use across most domains: Metric and US/Imperial. Weights and measures convert automatically to either system of measurement units based on the user's locale setting. Types of weight and measures that are likely to appear in FusionFX applications include:

• Mass (Weight): Weight measures, such as kilograms and pounds, and metric tons and US short tons.
• Distance: Measures of length, such as kilometers and miles, and centimeters and inches.
• Volume: Liquid and dry measures of volume, such as liters and pints.
• Area: Units such as hectares and acres.
• Speed: Distance traveled per unit of time, such as kilometers per second and miles per hour.
• Temperature: Heat measured in degrees of Celsius and Fahrenheit.
• Data Storage: Bits, bytes, megabytes, gigabytes, and so on.

Identifying Weights and Measures

Do not mix weights and measures without adequate definition and/or conversions. Here are several principles to ensure that values are not misinterpreted:

• The system of weights and measures (Metric, US, Imperial, Avoirdupois, Troy, and so on) must be identified on the page, unless the units of measure are both unique to one system and clearly distinct to application users.
• For example, measures based on the terms "meter" or "gram" are both unique to the metric system, and readily distinguished from US and British equivalents. The same is true of miles, yards, feet, and inches. However, the US short ton is easily confused with both the British long ton and the metric ton(ne), so these terms must be clearly identified.

• Units of measure and their abbreviations can be identified using abbreviation keys. See the Key Notation section of the Headers guideline for information about providing abbreviation definitions on a page.
• When only one system is used in the page, identify the system. For example, "Distances in Kilometers", and "Weights in Avoirdupois Pounds"
• When multiple systems are used, use abbreviations and define each abbreviation. For example, "km = Kilometers", and "kg = Kilograms"
• When defining multiple abbreviations, it may be necessary to place the definitions in a Panel Box or in a message dialog, depending on the number of definitions required.

• When only one system is used in the page, append the unit of measure to a header, such as "Shipping Weight by Customer (Short Tons)".
• In form layouts, units of measure should be appended to the end of fields (without parentheses), instead of appending them to field labels or data.
• In tables, the placement of units of measure depends on whether the column data is homogeneous or heterogeneous:
• Homogeneous Data: Append the unit of measure to the table column heading, within parentheses, such as "Weight (Kilograms)" or "Distance (Miles)", and do not repeat the unit of measure within individual cells. Long terms may be abbreviated as long as the abbreviation is defined using key notation.

Unit of Measure Placement in Column Header for Homogeneous Data

• Heterogeneous Data:
• If the measures all belong to a single system, such as the metric system, consider displaying all measures as meters, rather than a mix of kilometers, meters, and centimeters. The measure can then be identified in the column header as described above.
• If measures belong to different systems, consider normalizing the data with a single measure. In this case, it may be necessary to provide Select Radio buttons or a Select Choice list where users can specify a measurement system, and refresh the table with the converted measures. For example, the table could be shown with either metric or US/Imperial measures. This approach is useful when users need to view all data using a single system.
• When users need to see multiple records in two systems of measurement at the same time, rather than performing conversions for each measure, consider using a separate column for each system of measure and providing conversions in the columns that would otherwise be blank. For example, data that was entered in kilometers would appear in a column labeled "Distance (Kilometers)", and the converted data would appear in a column labeled "Distance (Miles)". This approach is only feasible in tables with few columns of data; otherwise, the additional columns can cause horizontal scrolling.
• When it is necessary to display multiple systems in a single column of a read-only table, append abbreviated units of measure to data in each cell in a column (without parentheses), such as "43 kg". Columns with appended measures should not wrap. Abbreviated measures must be defined using key notation. See the Headers guideline for information on using key notation.
• An editable table may provide a column of Select Choice lists for users to specify measures. For example, when entering weights of shipments, values could be entered in a column labeled "Quantity", and the adjacent column labeled "Units" would contain a Select Choice list with the entries "Metric Tons", "Short Tons", and "Long Tons". When the same table is displayed in read-only mode, that column should be retained, with measures displayed in read-only text to avoid reformatting the table when switching between editable and read-only modes. This use of a Units column is common practice within the shipping industry.
• When a table contains multiple units of measure, the measures should be repeated in each column header and total cell to avoid user error.

• Weights and measures follow the same display rules as Currency formats.

Math Operators, Functions, and Symbols

Some applications, especially Business Intelligence and Financial, need to use math operators and functions. There are three basic approaches:

• Use standard spreadsheet keyboard operators, such as such as asterisk (*) for multiplication, to enter formulas within fields.
• Use standard spreadsheet function abbreviations, such as AVG for average, to perform calculations.
• Use images for mathematical symbols, such as square roots.
  

Spreadsheet Operators

Users can enter formulas within a field by using standard spreadsheet keyboard operators, such as asterisk (*) for multiplication and slash (/) for division. Operators are typically grouped in two classes, arithmetic and comparison, as listed below:

• Arithmetic Operators
• + (plus sign) Addition
• - (minus sign) Subtraction
• / (forward slash) Division
• * (asterisk) Multiplication
• % (percent sign) Percent, when placed after a value, for example, 20%
• ^ (caret) Exponentiation
• Comparison Operators
• = Equal to
• > Greater than
• < Less than
• >= Greater than or equal to
• <= Less than or equal to
• <> Not equal to

When spreadsheet operators are used to construct formulas in fields or table cells, it is essential to specify the operators in instruction text or hint text. See the Help Framework guideline for details. If a page contains multiple fields that accept the same operators, it is sufficient to place a Hint on the first occurrence in each section of the page.

Spreadsheet operators may also be used in labels. In this case, they should be defined in instruction text.

Spreadsheet Functions

Some applications may need to use spreadsheet functions, especially statistical and financial functions, to perform calculations. Scientific applications may require a broader range of functions. Spreadsheet functions consist of standard terms, often abbreviated, in ALL CAPS, such as MEDIAN, STDEV, and PMT, and are usually not modified in translation.

It is not recommended to use spreadsheet functions to construct formulas within fields or cells. Instead, display functions as label text and associate them with fields or table cells.

Spreadsheet functions should be defined in instruction text.

Mathematical Symbols

Some applications, especially scientific applications, may need to display mathematical symbols other than the standard spreadsheet operators. In this case, it is acceptable to use images to display the symbols. Do not use symbol fonts, as equivalents do not exist in many international character sets.

There are two constraints on use of images to display mathematical symbols:

• Page Load Time: Pages may load slowly if they contain multiple images, especially large images. As a general rule, do not use more than five different button-size symbol images per page. Avoid using multiple large symbol images on a page, such as a bracket that encompasses multiple lines.
• Right-to-Left Languages: Some symbol images must be reversed to read correctly.

Mathematical symbols should be defined in tooltip text. See the Help Framework guideline for details.