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
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 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.
The following core name fields must be provided for data entry across all Oracle Applications in all locales, so that names can be shared across countries in international organizations:
First Name (a.k.a. Given Name)
Last Name, (a.k.a. Family Name) such as Jones, or Izumi
Known As: Name by which a person is known; used instead of first name (a.k.a. Preferred Name).
The following name fields may be required in certain locales to construct or distinguish the name:
Prefix: Particles that precede the family name, such as "de", "D'", "de la", "della", "von", "van", "Abu", "ben" (a.k.a. "pre name adjunct")
Middle Name or Middle Initial
Phonetic fields in 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. 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 on stage)
Depending on context, name information may be applicable to the entire page, or a section or subsection of a page, with different headings depending on context. For instance a subheader may read "Employee Information", or "Subscriber Details".
Name attributes may be displayed as label/data pairs, or as column headers and cells in a table. Both types may be updateable or view-only.
Depending on the application and the type of name field data being entered, users may enter names manually, choose a name from a 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 view-only or updateable, whether they 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, such as the Degree field for academic degrees, "Examples: B.A., M.S., Ph.D.), and the Prefix field, "(Examples: d', de, della, van)" which is used for particles that precede the family name. Do not use Hint text for choice lists, such as the Title field.
Names from different national origins may be entered and displayed in an application. They may also be entered in one country/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 Known As) 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 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 (Known As).
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 Known As field in Chinese applications in which to enter "Bob", as well as the First 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". Including the title also provides gender information for business intelligence analysis without requesting users to specify gender in the form. See Personal Attributes below for a discussion of this sensitive issue.
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.
View-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.
View-Only Tables: When name components are displayed in separate columns in a table, they start with the person's Last Name to allow useful sorting; if the Known As 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, Suffix, Preferred.
Updateable name fields follow different sequences in form and tabular layouts.
Form Layouts: Updateable name fields generally follow the sequence in which the name is read in the locale, with the Known As 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, Known As; in a long English form the sequence could be Title, First Name, Middle Initial, Last Name, Suffix, Known As, 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.
Updateable Tables: Updateable name fields always follow the same sequence as view-only tables, starting with the Last Name column, and finishing with the Known As name column. For example, in a US English table, the name column sequence could be: Last Name, First Name, Middle Initial, Known As. This consistent sequence is necessary to avoid disturbing column reorder when switching between viewing and updating a table. See the example table image below.
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.
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, and 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 view-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 U.S.A. a middle initial is often a required field to distinguish people with the same first and last names; this is inappropriate 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, the name fields in Japanese applications should be consistent in both HR applications and in Sales Online.
Use of Core Fields: Certain locales may use the First, Last, and Known As fields to enter data in their own character sets, and 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. Oracle developers use a class of flexfield to extend storage of such name attributes.
Phonetic Field: Some ideographic character-based languages, such as Japanese, 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 US and UK, 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 be grouped with names starting with upper and lower case "D" and "d" in the USA. Ordering should be irrespective of case.
Separate Data Entry: Name data from multiple locales must be entered separately to ensure that the form or table contains the appropriate fields/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 updateable table for each locale. This approach is recommended for bulk data entry of records with five or less updateable attributes.
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.
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:
Title: Mr.
First Name: Charles
Middle Initial: L
Prefix: de
Last Name: Grasse
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.
Name components that commonly require concatenation are as follows:
First Name (a.k.a. Given Name)
Preferred Name (nickname) such as Bob or Betsy
Last Name, (a.k.a. Family Name) such as Jones, or Izumi
Prefix (such as "von" in Werner von Braun, or "de" in Alexis de Tocqueville)
Middle Name
Middle Initial
Suffix, such as Jr.
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:
Greeting Format
Display Format
List Format
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 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"
Greeting format is used only when concatenated names are displayed in the following view-only components:
Welcome string, such as "Welcome John Doe", when it does not appear in a header. See the Home Page Template for examples.
Login stamps, that specify the current user's name rather than a login ID such as "bjones/sys"
Use of Known As requires that this name element be identified correctly in the database. This is only possible if a separate field is provided for input of the preferred name.
Some people from countries such as India and Indonesia have only one name. Unless they have specified a Preferred Name, then only the single name can be displayed.
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.
Display format shows names in the order in which they are normally read.
The standard English language Display format is as follows:
Purpose: Identify people using the name by which they are known in an organization
Usage: Most cases
English Syntax: {Known As|FirstName} [Prefix] {LastName}
Examples: "Bob Jones" or "Martin de la Cruz"
Display format is used when concatenated names are displayed in the following view-only components:
Headers (page titles and other levels of header)
Page stamps
Contextual Information
View-only label/data fields in form layouts
Lists such as Notifications and Approvers list where rows are not sorted by person name
Hints and messages associated with these components
If a documented business need exists to identify people by their full or legal name, the Display format syntax may be modified to meet this need. The requirements for displaying the full name vary from one country to another. For example, in the USA, an application 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.
Use of Known As requires that this name element be identified correctly in the database. This is only possible if a separate field is provided for input of the preferred name.
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.
Some people from countries such as India and Indonesia have only one name. Unless they have specified a Preferred Name, then only the single name can be displayed.
Due to unusual space limitations for DBI name fields, DBI uses the Display format syntax: {FirstInitial.} {LastName}, such as "B. Jones". This is a unique exception approved by upper management.
List format is used to provide sorting by family name rather than by first or preferred name.
The standard English language List format is as follows:
Purpose: Identify people in a list using the name by which they are known in an organization
Usage: Most cases
English Syntax: [Prefix] {LastName}, {Known As|FirstName}
Examples: "Jones, Bob" or "de la Cruz, Martin"
List format is used when concatenated names are displayed in name order in all types of lists, including:
Choice lists
Shuttles
LOV choice lists
LOV pages
Tables
HGrids
Hints and messages associated with these components
Due to unusual space limitations for DBI name fields, DBI uses the List format syntax of {LastName,} {FirstInitial.}, such as "Jones, B.". This is a unique exception approved by upper management.
Some people from countries such as India and Indonesia have only one name. Unless they have specified a Preferred Name, then only the single name can be displayed.
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.
When a view-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 drill-down method to display the complete set on an object page, as shown in the following example.
Updateable fields should NOT be used in either form and 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 is the family name.
Users cannot be addressed in the more welcoming Greeting format.
View-Only Table with Concatenated Names in U.S. English
(Example names are from multiple locales, but the syntax is U.S. English)
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 setting is expected to be used mainly by users who deal mainly with staff in their own country, and are in countries where the local names are different from the global names. For example, if a user in the USA 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 US appears on the same page, it would be displayed with the international character set, using an English language syntax.
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):
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.
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 be treated as one name rather than First Name and Middle Name.
Depending on context, address information may be applicable to the entire
page, or a section or subsection of a page.
Address attributes may be displayed as label/data pairs, or as column headers
and cells in a table. Both types may be updateable or view-only.
Fields may be concatenated as needed in U.S. English applications and in localized
releases. For example, street, city, state and postal code may be included in
a single view-only field, or table cell.
There may be multiple "Address Lines" exposed, but it is recommended not to
expose more than two for US addresses; addresses in other countries may require
an additional line. (Too many address lines may confuse a user regarding the intention
of the field, adding unneccessary or invalid data to the database.)
For U.S. address format, "County" may be optional. "State" should be a choice
list of valid 2 letter state postal abbreviations.
In addition to locale settings, all address fields are dependent on the "Country"
choice list. The "Country" choice list is the first label/choice pair. A "Go"
button follows the choice of countries unless Partial Page Rendering (PPR) is
used. When selected, the other label/widget pairs redraw based on the selected
country's address format standards (Internationalization standard).
When an application uses PPR, the Go button may be omitted. However, if browsers
do not support PPR, or the application is running in Accessibility mode, PPR is
disabled, and the Go button is rendered.
The Country choice list and updateable address formats should default to locale
settings until another country is selected. View-only address formats should retain
country address order.
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 zip codes are used in the U.S. whereas four-digit
postal codes are used in Australia; some countries are divided into states, whereas
others, such as Japan, are divided into prefectures. Some countries, such as France,
omit the region name (department) because 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 U.S.A. if an address is required, then a zip code
is a required field, whereas it may be optional in other countries.
Choice List of Cities: Some countries, such as Japan, may provide a
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, whereas in the
USA the state and postal code are separated by a space.
Addresses in View-Only Tables: When a view-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/cells, and that the fields are in the correct order for
the locale. There are two recommended approaches:
Provide a country choice list above an address
form. The choice list displays a separate form for each locale. For example, enter
USA addresses in one form, and French addresses in another. This approach is recommended
for most cases.
Provide a country choice list with a context-specific
label above a view-only table of addresses. The choice list then navigates to
a separate updateable table for each locale. This approach is only recommended
for bulk data entry of records with five or less updateable attributes. Additional
attributes will likely cause horizontal scrolling, and increase the risk of data
entry error.
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
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 information may be alone on a page, a section of a page, or a subsection
depending on context.
Each country may have multiple valid phone formats, with varying numbers of
digits, and different delimiters. Consequently, the phone format field is dependent
on the selection made in the "Country Code" choice list. For example, many European
countries use periods to delimit sections of phone numbers, whereas dashes are
more common in the USA.
If a user enters a phone number containing a fixed number of digits for a
given country, and the country has multiple valid phone formats for the number
of digits entered,
the number will be automatically formatted to the country's default when the
user exits the phone field.
If the default format does not match the user's format, the user can select
the "Phone Format" LOV which will show a list of available phone formats
based on the fixed number of digits entered. The default phone format is listed
as the first object. The user can then select the desired option to format the
entered number in the phone field.
If the user selects the "Phone Formats" LOV and only a default format
is available, then it will be the only format displayed in the list.
NOTE:Currently, only automatic formatting is available on field
exit. In the future, features such as number validation (e.g. validating on the
area code of the number entered may be added.)
The "Country Code" choice list is the first
label/choice pair. A "Go" button follows the choice of country codes, unless PPR
is used. When selected, the items in the phone format label/choice pair redraws
based on the selected country code standard (NLS standard).
The "Extension" field is optional.
Common telephone fields include:
Country Code
Area Code
Phone Number (often multiple fields)
Extension (for each phone number)
"Phone Type" label, with a choice list containing items such as "Home," "Work,"
"Cell," etc.
Contact information typically consists of a
combination of name, address, and telephone fields, along with other application-specific
elements, such as:
Company
Organization
Division
Department
Position (avoid "Title" as it is also used for
honorific titles)
Date and time elements consist of either updateable or view-only fields,
and conform to the guidelines for those types of fields. See the Date
Picker guideline for details.
Date and time elements may also be use as page
stamps. Time zone can also included in page stamp if it is not system
generated.
Date formats vary depending on user preferences and locale settings.
Unless a time is specified, date elements are associated with the time of
midnight for the start of the current day.
Updateable date and time elements should constrain users to enter data that
is valid in the current context. For example, a meeting scheduler would not allow
a user to schedule a room at a time that was already booked by another user.
Parentheses should not be used in date units as they are not always translatable
(e.g. "day(s)" should be "days", "month(s)" should
be "months", etc.).
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.
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.
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:
Date
01-28-2001
JAN-28-2001
Jan-28-01
28-01-2001
January 1, 2001
28-Jan-2002
Formats for dates in choice lists include:
Date
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.
The Date field is always associated with a Date
Picker, and includes hint text for the first occurrence on a page or within a
discrete section of a page.
Users have the option to use the Date Picker,
or to enter the date manually, following the example in the hint.
Months may be entered in upper or lower case
(case insensitive).
The Date Picker is only associated with full
date fields, and cannot be used with standalone month, year, or period fields.
Both date syntax and hint need to match user
preference and locale settings.
View-only month fields follow standard label/data
format.
Updateable month fields always consist of a
choice list.
Lists should only display valid months for the
current context.
Standard abbreviations for months may be used
in both view-only and updateable fields.
When the range of valid months bridges more
than one calendar year, it is necessary to indicate the year. The method is different
for view-only and updateable fields:
View-only fields: append the year to the month.
For example: "December 2001".
Updateable fields: place the Year field to the
right of the Month field.
View-only week fields follow standard label/data
format.
Updateable week fields always consist of a choice
list.
Lists should only display valid weeks for the
current context.
Users need help to determine when a week starts
and ends. Standard English language calendar format shows weeks starting on Sunday,
but a project planner may track from the start of the work week, and a contractor
logs may track from the end of the work week. The method is different for view-only
and updateable fields:
View-only fields: The label should specify "Week
Starting" or "Week Ending" and the full date in the format specified by locale
and preferences.
Updateable fields: Use key notation, instruction
text, or a hint to specify the starting or ending day of the week. For example
"Week = Work week starting on Mondays"
View-only day fields follow standard label/data
format.
Updateable day fields always consist of a choice
list.
Lists should only display valid days for the
current context.
Day fields can contain two types of data.
Days of the week, such as Monday, Tuesday, and
so on, or
A number indicating days elapsed from a predefined
start time, such as a project commencement date.
The view-only form of the numeric type 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 view-only and updateable forms should
indicate the measure in key notation, instruction text, or a hint.
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.
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.
View-only quarter fields follow standard label/data
format, but should specify the year as well as the quarter. For example: "Quarter
3 - 2001" and "Quarter 4 - 2002"
Updateable quarter fields typically consist
of a choice list, but may also consist of a 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.
Users should be constrained from selecting quarters
that are invalid in the current context.
In updateable fields, the format for calendar
quarters is different from quarters that span two calendar years:
Calendar quarters may specify the year in a
separate year field
Offset quarters must specify the year within
the quarter field
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:
The terms Semester, Trimester, and Session may
not be abbreviated in either view-only or updateable fields, but should be written
in full 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 choice lists
or radio button labels. For example, a form may list choices such as "Semester
1 - September 2002" or "Winter Quarter - January 2003", or
By providing this information in instruction
text or key notation, such as "First Semester = September 2001 to May 2002"
Date ranges specify a duration between a start and end date, or a start and end
period.
Date ranges consist of two date or period fields,
with one or two labels.
View-only date range fields are always placed
side-by-side and separated by a dash.
View-only labels should indicate duration, such
as "Project Duration" or "Review Period".
Updateable 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 view-only field that
specifies the current date range. For example, the date range for a fiscal quarter
might have the section header, "Specify a Fiscal Quarter". Alternately the date
range might appear below a view-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 view-only and side-by-side updateable
date ranges may consist of application-specific terms indicating the beginning
and end of a period, but this should be avoided if horizontal space is lacking.
Updateable fields should only allow selection
of dates and periods that are valid in the current context.
Updateable fields for ranges of full dates should
include a date picker next to each field.
Side-by-side updateable fields for ranges of
full dates should include a hint 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 12-OCT-2001 -
12-DEC-2001
Start week - End week, such as Week 24 - Week
27
Start month - End month, such as December, 2001
- January 2002
Start year - End year, such as 2001 - 2002
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".
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:
Hours
Minutes
Seconds (optional)
AM/PM (for 12-hour time only)
Time Zone (optional)
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 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.
Updateable time formats consist of separate
choice lists for hours, minutes, and seconds, separated by colons.
12-hour formats are distinguished from 24-hour
formats by appending an AM/PM radio group or by adding AM/PM to the hours listed
in the Hours choice list.
The decision to use 12 or 24-hour time formats
depends on both industry/domain and locale. U.S. mass market applications typically
use the 12-hour format, because it is more familiar to U.S. users. However, French
mass-market applications 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 U.S. self-service ticket reservations.
Both minutes and seconds may be listed in full
from 0 to 59 or in increments of 5, depending on application requirements.
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:
UTC vs. GMT: UTC was formerly known as Greenwich Mean Time (GMT), but the latter term is being phased out internationally. (Microsoft continues to use GMT in Windows, 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 are generally divided into four standard time zones, Eastern, Central, Mountain, and Pacific. When displayed, regional terms must always be spelled in full, and never abbreviated, as regional abbreviations may be identical to abbreviations used in other countries. For example, "EST" denotes 5 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 all clocks by one hour. States/provinces which choose not to switch, such as Arizona or Indiana in the USA, 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 Oracle UI. The UTC offset of a time zone never changes: "Pacific Time" is
always -8:00. However, the actual time displayed on the page will factor in whether Daylight Savings Time is in effect or not.
No Concatenation of Regions: Oracle's time zone entry for each city/country is based on the US Navy Observatory listings. Even though some cities or countries 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, and others not, or to implement it on different dates. For example, if Austria (Vienna) suddenly decides to change its daylight saving time next year, and if we have only one time zone for Germany/Holland/Italy/Sweden/Switzerland/Austria, then it would be very difficult to identify the customers that would be 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.
Updateable Time Zones: Users select a time
zone from an LOV choice list (the number of entries
[approximately 75] is too large for a standard choice
list). Entries are ordered by offset from UTC, but
commence with the more recognizable regional name.
For example:
Eniwetok, Kwajalein (UTC-12:00)
Midway Island, Samoa (UTC-11:00)
Hawaii(UTC-10:00)
Alaska (UTC-09:00)
Pacific Time (UTC-08:00)
Arizona (UTC-07:00)
Mountain Time (UTC-07:00)
Updateable Time Zone Formats
View-Only Time Zones: In view-only regions,
such as page stamps, label/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: "Pacific Time (UTC -8:00)"
Medium format: "Pacific Time"
Short format: "UTC -8:00"
Time Zone in Page Stamp
If date/time fields on the page are not part
of the client time zone, OR represent different
time zones, then the time zone must be displayed
after each date/time field:
Full format: "2:00 PM Pacific Time (UTC
-8:00)"
Medium format: "2:00 PM Pacific Time"
Short format: "2:00 PM (UTC -8:00)"
View-Only Time Zone in
Label/Data
View-Only Time Zone in a Table
Guidelines 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 only displays time
data from English-speaking North America,
or an application only displays time data
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
can be expected to recognize the new UTC
standard without reference to regional time
zone names.
Numeric elements may appear in updateable or
view-only fields or table cells, and 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 USA, 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 (USA uses
a comma).
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
Rules for display of percentage data differ
between form and table layouts:
In form fields, the percent sign (%) may be
placed to the right of fields, or appended to data in the field.
In table cells, percent signs are always appended
to the data in each table cell. In addition, percent signs may also be appended
to table column headings -- in this case the percent sign should be enclosed in
parentheses, such as "Total Returns (%)".
Users can 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 can also set preferences to display
thousands separators -- either a comma or a period.
In certain cases both numeric and alphanumeric
data may not be displayed in view-only fields/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
view-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. Note: 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 dash "-". 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 dash.
Updateable numeric fields and cells should
constrain users to enter data that is valid in the current context. For example,
if the value entered exceeds maximum or minimum values, the application will
generate an error message. See the Messaging
Templates guideline for details.
Depending on context, monetary information may
appear standalone on a page, in a section of a page, in a subsection, or within
a table cell.
Monetary formats follow the numeric formats
specified in user preference and locale settings. For example, in the USA, 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 (USA uses
a comma).
Do not use the US abbreviations "K" and "M" as these are not translatable.
Do not use currency symbols such as "$" in displaying currencies for the following reasons:
There is not always a 1-to-1 parity of a currency
symbol to the currency of a particular country. For instance, the dollar symbol
"$" is not unique to the United States, but is also used by other countries
such as Canada and Brazil.
Performance issues using GIFs to display the
currency symbols.
Translatability problems, as not every currency
symbol character is available in certain language's font set.
Code overhead to keep choice list of currency
code in synch via PPR with the symbol.
Currency abbreviations such as USD and DM should be defined using Key Notation. For example
"USD = United States Dollars" and "DM = German Marks"
Multipliers and scaling should be defined with
key notation. Due to Internationalization requirements, each Key Notation entry
may only contain one definition. For example, the phrase "Amounts in {thousands}
of {US Dollars}" contains two definitions, which makes it impossible to translate.
If this information is needed, provide two separate Key Notation entries -- one
for currency and one for scale. Scaling exceptions must also be noted, such as
"Amounts in thousands, except per share data"
Multiple currencies may be displayed in updateable
tables to facilitate data entry.
Avoid displaying multiple currencies in analytical
applications, which need to "compare apples with apples" and typically require
multiple currencies to be converted to a single currency before performing analysis.
When a table contains multiple currencies, currency
symbols should be repeated in each column header and total cell to avoid user
error.
If appropriate for a user to switch the currency,
a choice list is provided after the monetary field. The choice list contains all
valid currency codes based on internationalization standards.
If currency conversion is needed, the converted amount can be appended within parentheses after the original amount.
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 and debit card information consists of
a combination of name, address, telephone, numeric, and date fields. Specific
field labels are as follows:
Card Type - 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 choice
lists
Cardholder Name
Usage Principles
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 a hint to indicate whether
the Card Number field accepts spaces or dashes (-) 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 can be used for the Year field
because the range of valid years does not exceed choice list limits (60 or less
for time elements).
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:
Mass (Weight): Weight measures, such
as kilograms and pounds; metric tonnes and US short tons.
Distance: Measures of length, such as
kilometers and miles; centimeters and inches.
Volume: Liquid and dry measures of volume,
such as litres and pints;
Area: Units such as hectares and acres.
Speed: Distance travelled 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
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:
The system of weights and measures (Metric,
U.S., 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/metre"
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), and so these terms must be clearly identified.
Units of measure can be identified in several
ways:
Use Key Notation,
when only one system is used in the page. For example, "Distances
in Kilometers", and "Weights in Avoirdupois Pounds"
Append the measure to field labels, if there
is only one occurrence, or if the page contains multiple measurement systems.
For example, "Weight (in Kilograms)"
Append the measure to column headers, such as
"Distance (in Miles)"
Append the measure to a header, such as "Shipping
Weight by Customer (in Short Tons)
Append the measure to data within a field or
cell, such as "43 liters". If the measure is not unique to one system (such as
"tons"), use this option in conjunction with one of the others, such as Key Notation,
to avoid making table cells too wide.
When displaying weights and measures from multiple
systems within a view-only table, use one of the following approaches:
Display a Units column that specifies the measure
used in each row. This is the standard approach within the shipping industry.
Provide radio buttons or a 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 metric or US/Imperial measures.
This approach is useful when users need to view all measures in a single system.
Append the measure to data within each table
cell. For example, 23 kilograms, and 43 pounds. This approach is useful to reduce
space in complex tables with a large number of columns.
Use a separate column for each system of measure,
and provide 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 useful when users need to see multiple records in two
systems of measurement at the same time, rather than performing conversions for
each measure.
When entering weights and measures from multiple
systems within an updateable table:
Provide a choice list next to each measure data
cell, where users can specify the measure. 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 choice list with the entries "Metric
Tonnes", "Short Tons", and "Long Tons".
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 GIF images for mathematical symbols, such as square roots.
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:
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, 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:
Page load time: Pages may load slowly if they
contain multiple GIF images, especially large images. As a rule of thumb, 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.
Bidi languages: The symbol images must be reversed
to read correctly.
Mathematical symbols should be defined in Rollover
text. See the Inline Message and Tips guideline
for details.
Open/Closed Issues
Open
Issues
5-Dec-2003: Need to specify core name fields that must be exposed across locales to enable sharing of enterprise-wide name information. How shall we handle the need to enter names that originate in a different locale? A draft of this guideline with an updated Name Format section is currently being reviewed.
17-May-2002: Version 3.0 needs to address the
following issues -
Examples of numeric formats, credit cards, and weights and measures
Web site address formats
Language Selection formats
06-Mar-2002: Do standards exist for the size
of name fields? Waiting on answer from TCA.
29-Mar-2003: Check with Internationalization
Team if math symbols (+, -, =, etc.) translate.
Closed Issues
28-Jan-2004:
Defined core set of name fields required for data entry across most Oracle Applications and locales.
Combined standard social titles such as Mr., Ms, Mme., with less common titles such as Rev., Prof., in a single Title choice list that can be populated by customer admins.
Defined Greeting and List formats for view-only name display in English, and provided examples of these formats used in other languages.
Defined name format exceptions for DBI, which has greater space constraints than other applications.
Defined field sequence for updateable tables and forms, and for view-only tables that do not concatenate name fields.
5-Dec-2003: Removed reference to GMT from Time Zone entries. Now use only UTC.
12.13.01 - Responses from IPG:
We cannot append a label to a field to specify
the type of data or scale (such as "Processing Time [field] days", or "Amount
[field] US dollars"
We can use "to" as a separator in date ranges
We cannot use the common abbreviations Q1, Q2,
etc. for fiscal quarters
The percent sign (%) can be included in both
fields and table cells.
It is OK to specify hours with A.M. and P.M.
in pulldown lists (4 am, 5 am, 6 am, etc.). Even though Japan places AM/PM before
the hour, this is handled by locale settings.
It is OK to use colons as separators between
hours, minutes, and seconds in time fields
07-Mar-2002: Added section on weights and measures
13-Mar-2002: Responses from IPG:
Percent sign labels be placed to the right of
numeric fields containing percentages.
Measures may be appended to data in fields and
table cells
It is acceptable to use standard abbreviations
for metric measures (km = kilometer; kg = kilogram, and so on)
15-Apr-2002: Responses from IPG:
OK to use standard spreadsheet operators to
enter formulas in fields.
OK to use standard spreadsheet function abbreviations
to perform calculations.
OK to use GIF images for math symbols, but not
OK to use symbol fonts.
29-Mar.2003: Currency examples added to documentation
29-Mar.2003: Documented the use of friendly
time zone formats in the Time Zones section.
