Common Formats

Last Updated 19-Mar-2004

General Description

BLAF applications feature many common label/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, as well as meeting internationalization requirements. Applications may deviate from standard formats where they have documented business or functional needs to do so, but such variations should not extend beyond that required by customers, and should adhere to internationalization requirements.

For instance, in an HR application users may need to enter their personal addresses; in a CRM application users may need to enter customers' addresses. The formatting of this information should both be similar between these applications, and be ready for translation without modifying the page.

This guideline provides common formats and describes usage for: Note: Common formats as default are not defined by the UIX framework. The formats in this guideline are generic layouts for specific types of common information. Applications may require additional information per format, depending on context, or have unique requirements beyond what is recommended in this guideline.

This guideline focuses primarily on U.S. English layouts, but also provides general internationalization requirements, where they differ from those in the U.S.

Guideline Attributes

Spec Version # - 3.1
Spec Contributors - Betsy Beier, Mervyn Dennehy, Raymond Wong, Lisa Serface, Ivy Leung
UI Models - all
Example Products - ERP Applications, CRM applications, BI applications, Tools Application, Server Technologies
Related Guidelines - Standard Web Widgets, Information Regarding NLS, Content Layout Templates, Date Picker

Interaction and Usage Specifications

General Principles

Common formats consist of label/data pairs or tabular elements, and are bound by standard BLAF format and alignment guidelines for those components. For example, labels for both updateable and view-only fields are in regular black and right-aligned; however, data in updateable fields is regular black, but data in view-only fields is bold. See the Content Layout Templates guideline for details.

Many common formats, such as date, time, and currency formats, are controlled by user preference and locale settings. Locale settings modify the display of data to match language, and national and regional requirements. For example, many European locale settings substitute commas and periods in numeric formats. User preferences include choices between a minus sign and angle brackets to display negative numbers, choices between 24-hour and 12-hour time formats, and comma or period for numeric formats. See Global Button Flow: Preferences for more details.

Common formats for contact information in Oracle applications must comply with Oracle's Trading Community Architecture (TCA) requirements, which enable sharing of data between applications, enable sharing of data with outside parties, and facilitate internationalization. Oracle internal developers can see more details on TCA at the Trading Community Architecture address.

Name Formats

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

Name Format

General Name Format Principles

Sequence of Name Fields

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

Sequence of View-Only Name Fields

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

View-Only Name Fields in a U.S. English Table

Sequence of Updateable Name Fields

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

Updateable Name Fields in a Short U.S. English Form

Updateable Name Fields in a Long English-Language Form

Updateable Name Fields in a U.S. English Table

Note: When the User Name and E-mail Address fields are included on the same page as name fields, they are positioned as follows: User Name precedes the other name fields, and E-mail Address follows the name fields, and also follows any street address fields.

Locale-Specific Name Format Issues

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

Updateable Name Fields in a Japanese-style Form

Technical Note: The method used to construct names from name attributes may vary between applications within a single locale. For example, in Japan, HR and Sales Online use different tables to store and construct names, so would require different algorithms to do so.

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 U.S. commercial correspondence is to omit titles, and sometimes suffixes, from addresses on business letters. A general rule of thumb 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 (except for DBI) Allow space for display of a minimum of 12 characters to reduce errors entering longer names, such as "Abdurachman". First names may contain spaces or hyphens, such as Jean-Paul.
Known As 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 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.
First Initial Replaces first name in DBI, where space is limited. Required text field for DBI Not used in other applications
Middle Initial Distinguish individuals with common first and last names Optional text field (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, such as INS Allow space for display of a minimum of 12 characters to reduce errors entering longer names, such as "Abdurachman"
Suffix Used to distinguish individual 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 choice list (may be required in some applications to meet statutory requirements) 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 (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 Optional text field ; required by some government agencies, such as INS 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:

Note: Other name components, such as the Degree field, may also be concatenated to meet business requirements -- usually in academic contexts.

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

Note: Concatenated names also appear when users are prompted to enter credit/debit card data. In this context the concatenated name should match exactly what appears on the credit/debit card rather than one of the two formats specified below. See Credit/debit card information for details.

Greeting Format in English

Greeting format is used to welcome the user. The standard syntax for all English-speaking locales is:

{Known As|FirstName} [Prefix] {LastName}, such as "Bob Jones" or "Martin de la Cruz"

Note: In US English, the Greeting format syntax is identical to the Display format syntax. Nevertheless it is necessary to define these as separate formats, because Greeting and Display formats differ in other locales, such as Japan, where an honorific such as "san" is appended to the family name.

Login Stamp with English Greeting Format

Display Format in English

Display format shows names in the order in which they are normally read.

Header with Standard English Display Format

List Format in English

List format is used to provide sorting by family name rather than by first or preferred name.

View-Only Table with Concatenated Names in U.S. English
(Example names are from multiple locales, but the syntax is U.S. English)
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.

Concatenated Formats in Different Locales

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

When concatenating names in greeting format, such as "Welcome Mary Stuart," a sequence that is welcoming in one country may be strange or impolite in another. For the USA, the standard sequence is "Welcome {Known As|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 U.S.A. a name may be concatenated in List format with a comma as "LastName, FirstName", whereas in Japan the sequence is "LastName FirstName" without a comma.

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

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

Address Format

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

Address Format

General Address Format Principles

Generic Updateable U.S. Address Form

Locale-Specific Address Format Issues

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

Generic Updateable Japanese Address Form

View-Only Table with Addresses From Multiple Locales

Use of Country Choice List To Add Addresses From Multiple Locales

Updateable 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. Unless the context clearly requires that users identify their gender, or provides 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.

Note: An alternative method for collecting gender information without being intrusive is to include a Title field, and only populate it with gender-specific titles such as Mr. and Ms.

Phone Number Format

Phone Format

Contact Formats

Contact information typically consists of a combination of name, address, and telephone fields, along with other application-specific elements, such as:

Note: More information to be added here.

Date Formats

Standard date formats include:

General Date Principles

Note: Unless another time zone is specified by the user, dates and times are based on the user's local time zone, not on server time, which may be different.

Full Date

The format of the specific date defaults to the application locale setting. Users can then set preferences for date options available within that locale. Formats for dates in view-only fields include:

Note: It is recommended to avoid full date formats that consist entirely of numerics and separators, such as 01-06-02, because international users may read this as 6-Jan-2002 or as 1-Jun-2002.

Users enter or update specific dates in the standard concatenated date field.

Updateable Date Field in U.S. English

Separate Date Fields

Date fields can also consist of separate or standalone fields for year, month, week, and day.


Standalone year fields are as follows:

View-Only and Updateable Year Options


Standalone month fields are as follows:

View-Only and Updateable Month Options


Standalone week fields are as follows:

View-Only and Updateable Week Options


Standalone day fields are as follows:

View-Only and Updateable Day Options

Fiscal Quarter

Fiscal quarters are used by organizations in the USA and some other countries to track the organization's financial status. Fiscal quarters are unknown in many countries, such as Japan.

View-Only and Updateable Quarter Options

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

Educational institutions typically divide years into semesters, trimesters, or quarters. Other educational organizations may also break the year into sessions. In the USA, academic years usually bridge two calendar years and are identified by concatenating the years, such as "2001-2002 Academic Year".

Valid formats vary greatly between institutions. However, the following guidelines are generally applicable:

Academic Period Options with Months Specified

Academic Periods with Key Notation

Date Ranges

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

Side-by-Side Date Range Options

Stacked Date Range Fields


Periodicity fields consist of choice lists or radio buttons that allow users to choose a type of period, such as Quarterly or Annually. If users are expected to be familiar with the term, the label can be "Periodicity". Otherwise the label should be "Period Length".

Period types include:

Periodicity Field as a Choice List

Time Formats

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

Time formats consist of up to five fields: Note: Unless another time zone is specified by the user, dates and times are based on the user's local time zone preference setting, not on server time, which may be different.

View-Only Time Formats

View-only time formats follow standard label/data guidelines, except when displayed as time stamps. 12-hour formats are distinguished from 24-hour formats by appending an AM/PM field. 12-hour formats may be displayed with three places, such as 7:30, until the hour reaches 10:00.

12- and 24-Hour View-Only Formats

12:59 AM
12:59:23 AM

Updateable Time Formats

12- and 24-Hour Updateable Format Options

Time Zones

Time zones are arbitrary geographical regions formed by a combination of longitude and politically-designated boundaries, such as national and state/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:

Time Zone Display Formats

Numeric Formats

Currency Formats

Currency as read-only content in a page and table layout
Currency in read-only page and table layout shown with key notation
Currency in read-only page and table layout shown with key notation and scaling
Currency as updateable content in a page and table layout
Currency in updateable page and table layout shown with key notation

Single currency with conversion as read-only content in page layout shown with Key Notation

Multiple currency as read-only content in a page layout shown with tip and scaling

Multiple currency as updateable content in a page layout shown with tip

Multiple currency as read-only content in table layout shown with tip and scaling

Multiple currency in an updateable table layout shown with tip and scaling

Credit/Debit Card Formats

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

Usage Principles

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 U.S./Imperial.

The U.S. system is based on the legacy system of English Customary Units, which consists of complex sets of measures developed independently from each other. For example, small weights may be measured with Avoirdupois ounces or Troy ounces, depending on industry/domain. All U.S. weights and measures are fixed in relation to the metric system -- conversion scales between these systems are readily available, both in hard copy and on the Web.

Detailed usage of each type of measure is beyond the scope of this guideline, which focuses on making sure that measures are clearly distinguished from each other. Types of weight and measures that are likely to appear in BLAF applications include:

Identifying Weights and Measures

The key principle in using weights and measures is to avoid mixing them without adequate definition and/or conversions. Here are several principles to ensure that values are not misinterpreted:

Math Operators, Functions, and Symbols

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

Note: When math operators are displayed in a choice list, both the symbol and its meaning can be displayed within the list, rather than using Key Notation, Tips, or instruction text to define the symbol. For example: ">, greater than".

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:

When spreadsheet operators are used to construct formulas in fields or table cells, it is essential to specify the operators in Instruction Text, and/or Tip or Hint text. See Help Methods for an overview. If a page contains multiple fields that accept the same operators, it is generally sufficient to place a Hint under 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 Key Notation, Instruction Text, or Tip text. See the Key Notation guideline for details on usage.

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.

At this point 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 Key Notation, Instruction Text, or Tip text. See the Key Notation guideline for details on usage.

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 GIF images to display the symbols, but it is not permitted to used Symbol fonts, as equivalents do not exist in many international character sets.

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

Mathematical symbols should be defined in Rollover text. See the Inline Message and Tips guideline for details.

Open/Closed Issues

Open Issues

Closed Issues