Language in UI

General Description

• General Rules
  • Capitalization
  • Use of Pronouns
  • References to Labels and Object Types
  • Hyphenation
  • Use of Plurals
  • Use of Delimiters
  • Use of Symbols
  • Use of Numbers in Sentences
  • Use of Trademarks
• Browser Window Title
• Tab/Navigation Text
• Breadcrumbs
• Page Header, Subheader, Subsubheader Text
• Instruction Text
• Tip Text
• Bubble (Rollover) Text
• Messages
• Button Labels (Action/Nav; Global; Links)
  • Common Button Terms
  • Step by Step Terms
  • Comparison of Related Terms
  • Actions that Affect Data

Guideline Attributes

Usage Specifications

General Rules

Capitalization

In HTML Apps, use headline capitalization for titles, headers, control labels, and rollover text. Headline capitalization places initial caps on each word except for the following:

• Articles (a, an, the)
• Prepositions with less than four letters
• Conjunctions (and, but, or, nor, so, yet)

Note: If any of these exceptions appear at the beginning of a phrase or sentence, they always have an an initial cap.

Use sentence capitalization for instruction text, inline messages, key notation, and tips. Sentence capitalization places an initial cap on the first word in each sentence.

References to Labels and Object Types

When writing Instruction and Tip text, avoid references to UI labels, such as "Search", and to object types, such as "Accounts". Applications are often translated by multiple translators, with one or more people assigned to translate UI labels and others assigned to instruction text. As a result, translated references to UI elements may not match the translations employed for those elements. For example, if instruction text refers to a Search button, the translation of "Search" in the instruction text may not match the translated text on the Search button.

Use of Pronouns

In general, Oracle Applications should omit pronouns (such as I, my, his, our, they) from user interface labels. Oracle Applications should not contain the common Web construction, "My (xxx)", such as "My Portal". Exceptions to this guideline include the global button,"Contact Us", and the portal address "my.oracle.com". Use of the pronouns "you" and "your(s)" is acceptable in instruction text and messages.

Hyphenation

Oracle Applications should not include hyphenated terms. If a term is typically hyphenated in English, omit the hyphen, or substitute another term. For example, the term "High-end Notebooks" should be changed to "High End Notebooks", or replaced with another term, such as "Notebooks Over $5,000".

Use of Plurals

When referring to one or more items, use the plural form of the word, rather than using parenthetical plurals. For example, instead of "Select item(s)....", use "Select items...."

Use of Delimiters

Applications frequently concatenate data to populate fields. Concatenated strings require delimiters to avoid forming nonsense phrases, or making numeric data unreadable. However some delimiters, such as commas, may occur within strings, and thus create further problems.

BLAF Applications have standardized on the following delimiters. All other delimiters, such as slashes (/) are deprecated:

• Semi-colon (;) to delimit for concatenated data
• Colon (:) for concatenation of page and section titles
• Greater Than symbol (>) to delimit levels in a hierarchical path, such as breadcrumbs

For details on page title syntaxes, see the Language: Page Titles and Breadcrumbs guideline.

Use of Symbols

Avoid using symbols such as the percent sign (%) in labels and all forms of inline Help, such as Instruction Text, Tips, and Hints. Instead, spell out the symbol name, such as "percent sign". The only exceptions are for column header text, where space is limited, or when the symbol is used to indicate units. For example, in form layouts the percent sign may be placed to the right of a field containing a percentage. For more details on the use of percentages, see Numeric Formats in the Common Formats guideline.

Use of Numbers in Sentences

Standard US English writing practice is to spell out all numbers when they appear at the beginning of sentences, and to spell out numbers from zero to ten when they are embedded in sentences, unless they are units of measurement. For example: "One hundred ten employees received bonuses this quarter, 33 employees received raises, and five employees were terminated."

These rules may lessen the usefulness of message, Tip, or Instruction text when the text includes variable numbers that indicate quantities, and be inappropriate where a number is the identifier for an object. In addition, applying these rules to variables would require additional code to render the page. Consequently, BLAF applications will use the following rules for display of variable numbers:

• Display variable numbers that indicate quantities in bold numeric text.
• Display variable numbers that identify an object in regular numeric text, unless they are embedded in a bold text phrase or sentence.
• Where possible, avoid starting sentences with numbers.

The following example message shows how this can be implemented:

"You saved 2 assets in Asset List 45798." (Instead of "2 assets were saved in Asset List 45798.")

If Instruction or Tip text includes non-variable numbers (unusual), follow the general documentation rules above, with one exception: If the text includes more than one occurrence of numbers, avoid mixing spelled numbers and numerals in a single instruction or Tip -- instead use numerals for all occurrences, but construct the sentence so that numerals do not appear at the beginning. Here is a rewrite of the example above that incorporates this exception:

"Human Resource actions in the past quarter included: bonuses for 110 employees, raises for 33 employees, and termination of 5 employees."

Use of Trademarks

When including the names of trademarked products within the UI, Oracle documentation practice is to include trademark statements in the 'About (Application)' page and/or the application's Help system. Oracle internal developers can see full details on use of Oracle trademarks at the Oracle Legal Web site.

Third party trade marks only need to be referenced if Oracle has a contractual obligation to do so. In this case refer to the contract with the third party for details.

For more information on trademarks, contact Oracle Legal.

Browser Window Title

The title bar in a primary browser window displays the page title, which can be constructed with the following syntax. All window titles have headline capitalization.

{Oracle} {Application Name} [: Module Name | : Task Name] [: SubTask Name]- {Browser Name}

Variables in square brackets are optional, because some names may result overly long titles, especially in translation. Here are examples of several basic forms:

• With Module Name:
  Oracle Human Resources: Promotions - Netscape
• Without Module Name, with Task name:
  Oracle Order Management: Create Order - Netscape
• With both Task Name and SubTask Name:
  Oracle Order Management: Create Order: Select Vendor - Netscape
• Without Module or Task Name but with SubTask Name:
  Oracle Order Management: Select Vendor - Netscape
• Without Module Name or Task/SubTask name:
  Oracle Order Management - Netscape
  

When secondary windows are used (uncommon) the title bar only displays the component name, such as "Date Picker," or level one heading, to distinguish it from the primary window.

For details on page and section title syntaxes, see the Language: Page Titles and Breadcrumbs guideline.

Tab/Navigation Text

Tab and navigation link text should be concise to avoid horizontal scrolling. Where necessary Tab and navigation link text may contain multiple words.

Tab labels should consist of nouns, such as "Customers," or brief nouns and adjectives, such as "New Contacts." Tab labels should not contain verbs, such as "Create."

When tabs and navigation labels are the names of containers, use plural form. For example, a tab that contains orders should be called "Orders", not "Order", and a tab containing information about shipments should be called "Shipments", not "Shipment". However, a tab containing information about a company's structure would be called "Organization", because the plural form implies there is more than one organization.

Use parallel word forms or constructions within a single set of peer navigation links. For example, avoid mixing names such as "Inventory" with action terms like "Create Part."

Common navigation terms and their usage are as follows:

• Overview: For high-level information that introduces an object or task.
• General: For primary attributes of an object or task, as well as attributes that cannot easily be categorized with other attributes.
• Summary: For conclusion of a process or project.
• Basic: Avoid using this term except when it directly relates to page content, such as a basic plan for insurance coverage.
• Main: Avoid using this term except when it directly relates to page content, or is used as an adjective to qualify a noun, such as "Main Street".

Oracle Applications currently have one standard Level 1 Tab Name, which is "Home." Currently many applications feature a Home tab. In future, another term instead of "Home" may be used for the primary tab in individual applications.

Breadcrumbs

Breadcrumbs appear below the tab bar on applicable pages. Their syntaxes vary depending on the page template and the page's location in the application hierarchy. See the Language: Page Titles and Breadcrumbs guideline for details on page title syntaxes.

In addition to page-level breadcrumbs, HGrids also feature breadcrumbs to indicate the path to the overall root of the hierarchy. See HGrid Breadcrumbs in the HGrid Templates guideline for details.

Page Title (type of Header), Header, Subheader, Subsubheader Text

Page titles appear as first level headers below the tab bar in all BLAF pages, and should not be confused with the browser window title, which has its own conventions. Page titles are are assembled using a variety of syntaxes, frequently with concatenated formats, such as "Schema Objects: Scott" or "Purchase Orders: 34523462". See the Language: Page Titles and Breadcrumbs guideline for details on page title syntaxes.

Consistency in Phrasing

All titles and headings should omit pronouns as much as possible. Wherever possible, use parallel word forms or constructions for headings within a single application. For example, this set of headings has a parallel structure:

• Notebooks Under $1,000
• Notebooks Between $1,000 and $2,000
• Notebooks Between $2,000 and $3,000
• High End Notebooks

• Desktops Under $1,000
• Desktops Between $1,000 and $2,000
• Desktops Between $2,000 and $3,000
• Buy a High End Desktop?

Abbreviated Titles and Headers

Several navigation components display the title of a target page, or a heading within a page. Due to space constraints, these components may often require abbreviation of long titles or headings. These components include:

• Breadcrumbs: show hierarchy of pages
• Train: displays the name of each step in a process, as a link or a lable
• Choice list: when used with Next/Back Button in Step by Step processes
• Quicklinks: point to abbreviated section headers within the current page

General Principles for Abbreviating Headers

• Abbreviated titles and headers must make sense to the user
• Abbreviated titles and headers must be readily distinguishable from other title/header choices in a page or process.
• Where possible, abbreviated page titles should be readily distinguishable from other page titles within a specific application module.
• Where possible, abbreviated titles should be readily distinguishable from other page titles in the current application module.
• Where possible, abbreviated titles/headers within a page, a process, or an application module should retain parallel construction.
• Page titles are syntax-based and can usually be abbreviated automatically, but may sometimes require additional manual edits to make the title short enough, or to keep it distinct from other titles in the page or set.
  • Except for the case noted below, abbreviate syntax-based titles by removing the leftmost syntax elements.
    For example, elements to the left of the colon in the title, "Create Invoice: Shipping Information", can be removed to result in the shorter title, "Shipping Information".
  • Abbreviation of titles with the syntax {Action} {ObjectType:} {ObjectName} (from "Object Template: 1 Page and 1 Long Page") depends on context. Retain one or two syntax elements, along with a colon delimiter, that distinguish each page from others in the page or module.
    For example, if other page titles have different actions, but the same object type, such as "Create User: Mary Scott" and "Remove User: Fred Black", then retain {Action}, the colon delimiter, and {ObjectName} elements, but remove {ObjectType:}. The result is then "Create: Mary Scott", and "Delete: Fred Black".
• Section headers within a page are often not based on syntax rules, and so must be manually abbreviated to specify distinctive Quick Links. As a rule of thumb, if headings have common elements, consider omitting those elements.
  For example, a page titled "Membership Profiles" with section headings of "Lifetime Membership Criteria", "Supporting Membership Criteria", and "Regular Membership Criteria", could have the Quick Links: "Lifetime", "Supporting", and "Regular".

Instruction Text

Instruction text is the primary method for directing users to perform a task on a page. Instruction text may be applicable to:

• The entire page
• A section of content
• A group of components within a section (uncommon)
• A table

Instruction text should only explain the primary way to complete a task. Use Tip Text to explain ways to increase productivity, shortcuts, and alternate methods, or to provide domain-specific information, such as organization policies.

Users are more likely to read and understand text if it is concise, well-phrased, and used sparingly. Consequently, restrict instruction text to a maximum of 3 paragraphs per page, with a combined total of no more than 7 lines. If a page does not need text, do NOT add text to make it consistent with other pages.

Use imperative voice to give directions, such as, "Select a task, and then enter a start date." If you need to describe something, use active voice, such as, "You can change these parameters later." In general, avoid passive voice, such as, "The parameters can be changed by you later."

Oracle writers can find detailed style guidelines at Oracle's internal DocTools Web site: http://doctools.us.oracle.com/standards/standards.html

The Instruction Text guideline provides guidelines on placement of instructions within a page. Examples of standard instruction text are provided in individual page templates.

See the Help Methods guideline for a comparison of Instruction text with Tips and other Help methods.

Tip Text

Tip text is used to call attention to useful domain or UI information that might not otherwise be obvious. This information may include reminders about organization policies, UI shortcuts or alternate ways to perform tasks, pointers to Preferences, or information on how the UI behaves, such as "Changes will be saved when you move to the next set of <objects>".

• Regular Tips: for a page, section of page, table, group or components, button, or link, in one or two lines with a Tip icon.
• Hints for standard Web widgets, in one short line of text without a Tip icon.
• Content Container tips for a page or section of page, with an optional Tip or Quick tip icon.

For visual guidelines on these three forms of Tips, see the Inline Messaging and Tips guideline.

Regular Tips

Regular Tips consist of a tip icon and associated dark blue text, and may be associated with a page, section of page, table, group or components, button, or link. Regular Tips should not exceed one or two lines of text.

Regular tips depend on context, and vary from page to page. The following illustration shows an example of a section-level tip:

Hints for Standard Web Widgets

Hints for standard Web widgets (for fields, choice lists, radio buttons, etc.) appear beneath the related element, and do not include a Tip icon. In general, Hints should not exceed a single line in U.S. English, to allow a maximum of one and a half lines in translation to other languages. To keep Hint text succinct:

• When giving directions, use imperative voice, such as "Enter your first name" instead of "You need to enter your first name"
• When explanation requires too many words, use an example or a syntax instead, as in the Hint text for a Date field.
• As long as it communicates well, Hint text does not need to form complete sentences.

The following elements have standard Hint text.

Date

Date field Hint text varies depending on locale and user settings, so must include a variable for the date format. The Hint text syntax is:

(example: <date format example>)

Here are some examples of date field Hint text in different formats:

Time

Time field Hint text also varies between 12 and 24-hour formats, so require a variable. The Hint text syntax is:

(example: <time format example>)

Here are some examples of time field Hint text in different formats :

Telephone Number

Phone number field Hint text also varies between locales, so require a variable. The Hint text syntax is:

(example: <phone format example>)

Here are some examples of phone field Hint text in different formats :

Identification Numbers

ID numbers vary from one locale to another, and a single user may have mulHintle IDs, such as Passport number, driver's license number, or national identity number, such as the U.S. Social Security number. The standard syntax for all ID numbers is:

(example: <ID example>

Here are some examples of different ID formats:

Name

Applications may require that full names be entered into a single field, or separate names into different fields. When names are separated into labeled fields, there is no need for Hint text. When full names are entered in a single field, the sequence of the name varies from one locale/language to another, and takes the following syntax:

(example: <name format example>)

Here are some examples of different name formats:

If the middle initial is optional, append the following text to the name example:
"(example: Michael J. Smith) - middle initial is optional"

New User Name

When new users are prompted to specify a user name, use the following Hint text:

"Enter the name you will use to login."

Password (on change password)

When users are prompted to change their password, display the following Hint text, replacing 'n' with the minimum number of characters:

Passwords must contain at least 'n' characters including spaces (example: log mein4)

Street Address Line

Address lines have the following Hint text:

(example 111 Main Street)

Content Container Tips

Content Container tips depend on context, and vary from page to page. The following illustration shows an example:

See the Help Methods guideline for a comparison of Tips and other Help methods.

Bubble (Rollover) Text

Bubble text, otherwise known as ALT text or rollover text, is used on buttons, links, and icons. Bubble text can provide a slightly longer description of a UI element than is possible in the element's label. For instance, an action/navigation button may be labeled "Save Form," and the bubble text can read "Save 1999 Federal Tax Form."

See Icon List for standard rollover text on common icons. For detailed information on use of Bubble Help, see the Inline Messages and Tips guideline.

On Action-Only or Action/Navigation Components

When implementing Bubble text on action-only or action/navigation components use the following syntax in most cases:

{ActionVerb in imperative voice} [preposition] [adjective] {Object} [additional info]

For example, "Delete Row", "Create Approved Vendor", or "Delete Vendor from Approved Vendor List".

On Navigation-Only Components

When implementing Bubble text on navigation-only components, use this syntax for most cases:

{Go to} {PageTitle|StepNumber}

For example, "Go to Approved Vendor List", or "Go to Step 5"

Use this alternate syntax for Bubble text on navigation-only components, if the page title is unclear in the current context, or if the concatenation of "Go to" and "PageTitle" results in a confusing phrase:

{Display} {Subject|PageTitle}

For example, "Display List of Prospective Clients"

For Components with Keyboard Shortcuts

If keyboard shortcuts are implemented on a button, use the following Bubble text syntax:

{ButtonLabel:} {Alt +} {x}

For example, "Next: Alt + x"

The Keyboard Shortcuts guideline specifies standard accelerator keys.

Message Text

There are five types of message content:

• Information - Provides contextual information about business practices and methods.
• Warning - Alerts the user to a condition or a situation that requires a decision before continuing.
• Error - Alerts the user that one or more actions have failed due to data inaccuracies or system level problems. The application requires immediate attention and/or correction before continuing.
• Confirmation - Notifies the user that an action has been completed successfully.
• Processing - Notifies the user that an action is currently being processed.

Message text appears in three forms:

• Inline messages
• Message boxes with inline messages
• Stand-alone message pages

The following table details the attributes of each form of message, and examples of each form are provided in the following sections.

Message Boxes and Stand-alone Message Pages

The key difference between Message Boxes and Message Pages is that the latter features at least one Action/Navigation button that requires user response to the message.

Information Message Boxes/Pages

The general form of the message provides contextual information that may be useful to the user, even though it may not be critical to completing the current task.

Examples:

"Orders must be entered before <date> to be processed before the end of the quarter/end of the fiscal year."

"Subscribers to the xxx program get yyy benefits. Would you like more information? Yes/No."

Warning Message Boxes/Pages

Warning messages alert the user to potential problems that may or may not lead to loss of data or loss of function. Warning messages may be caused by system-level problems or be displayed as a result of user action.

Examples:

"You have been specified a start date after the end of the fiscal year. Continue with this transaction? Yes/No"

"You have been disconnected from the system. Please try again later."

"The system is going down in 'n' minutes. Please logout now."

"The system is going down in 'n' minutes. Please save your work and logout."

Error Message Boxes/Pages

Standard error messages consist of up to three parts that, depending on the message context:

1. Identify the action that failed, including the object name if appropriate.
2. Provide directions to resolve it, and optionally append a back-end error code.
3. (Optional) Provide additional information for use by a support representative.

When an error is associated with one or more page components, the error message provides a link to the page anchor for each component requiring attention.

Most errors can be described with the following English-language syntax:

"Cannot <button or link name> [object name or general term for object of action].
<Suggested resolution.> ([Message number])
[Additional Information: for Support representative.]"

Message numbers are necessary to help debug translated applications, but should not be used as a substitute for useful, explanatory messages. See Oracle Applications Message Standards for more information on message numbers.

Additional Information (for Support) provides back-end messages that are rarely intelligible to application users, so should only be provided when they are truly useful to help resolve the problem.

Caution: This English-language syntax is a guideline for writing messages, but cannot be used to assemble messages programmatically. Any message code written to this syntax would not be translatable.

Examples:

"Cannot add row.

"Cannot remove item.

"Incorrect date format.

"Some required fields have not been completed.

"System Error: Cannot display page

"Program Error: Invalid arguments specified on exiting the field.

Confirmation Message Boxes/Pages

Confirmation messages inform the user that an action has been completed successfully.

Examples:

"Your work has been saved."

"Your <object name or changes> has/have been submitted for approval."

"Your <object name or changes> has/have been distributed for review."

"Your changes have been applied."

"Your order has been submitted. Your confirmation number is: 02345790"

"Your <object name> has been created."

Processing Message Boxes/Pages

Processing messages inform the user that an action is currently being processed, and, where possible, provide an indication of the range of time required to complete the task. For more details, see the Processing Templates guideline.

Examples:

"Your <action name> process has been started. Typical <action name> times vary between nn and nn minutes/hours. See the xxx page for <action name> status."

Inline Messages

Inline messages provide users with Error, Warning, and Information text for specific components or groups of components. Inline messages are displayed in conjunction with a related message box or message page. Unlike page-level messages, inline messages cannot be used to provide confirmation of user actions.

Inline Error Examples:

"First select a value for the <field name> field."

"First enter a value in the <field name> field."

Existing User Name

When existing users fail to enter their user name correctly, display one of the following messages, depending on whether the user chose the name, or whether it was assigned by a sysadmin:

"Enter the user name assigned by your administrator."
"Enter the user name you specified when you set up this account."

Inline Warning Examples:

"Specifying a value of xxx will result in potential problem yyy."

The date specified is after the end of the fiscal year."

Inline Information Examples:

"Dates must be within the current fiscal year."

"Valid entries include aaa, bbb, and ccc."

The Oracle Applications Message Standards contain detailed recommendations on writing messages for Forms-based applications. Some of these standards are clearly Forms-specific (such as message names and numbers), but the section titled, "A Few General Guidelines for Writing Good Messages" applies equally well to HTML applications.

For more information on placement of tip and message text within a page, see the Inline Messaging and Tips guideline.

Button Labels (Action/Nav; Global; Links)

The terms in the following tables specify standardized button usage in Oracle HTML Applications. Terms with related usage are grouped together. The tables include several key notations:

(xxx) indicates that the control commonly includes a pre-defined object name, such as "Create Invoice."
(nn) indicates that the control commonly includes a pre-defined number, such as "Add 10 Rows." Note: Designers may also use application-specific terms for other usages than those listed below. New terms will be added to the list when they are used in multiple applications.

Common Button Terms

Terms Specific to Step-by-Step and Linear Processes

Comparison of Related Terms

In the following comparisons, guideline-approved terms are in bold, even though they may not be correct for the usage under discussion.

Adding New Content

Create vs. New
Create is a verb like all other Action buttons, so is preferable to New.

Create (xxx) vs. Add (xxx)
Create displays a page where a user can create a new object (where none yet exist). Add (xx) appends a new instance of an object inline to an existing set of objects -- the new object then needs to be populated with data or properties.

Create and Add (xxx) vs. Apply
Create and Add (xx) display a page where a user can create an object. That page includes an Apply button to confirm the user's changes.

Modifying Existing Content

Update (xxx) vs. Edit
Both terms means to make changes. Update is more common in Web environments. Edit is reserved for displaying a page or window with editing controls.

Update (xxx) vs. Refresh
Update displays a page where users can make changes. Refresh redraws the current page without making user changes.

Update (xxx) vs. Apply
Update displays a page where a user can make changes. That page includes an Apply button to save the user's changes.

Update vs. Rework
Update is used to modify any type of object. Rework is used exclusively when modifying existing files.

Delete vs. Remove (xxx) vs. Cut
Delete removes an instance of an existing (saved) object from a database. Remove (xx) affects application objects that appear in the UI, but that have not yet been saved to the DB, such as Remove from Shopping Cart.

Note: Some applications may use the term Remove, if Delete is considered offensive, such as "Delete Person."

If Cut is implemented in the same way as Java applications, it removes an instance of an object from the UI and places it in a temporary storage buffer, but only deletes it from the database if it is pasted elsewhere. If the user takes another action to clear the buffer before pasting the object, the object will reappear in its former location when the page is next refreshed.

Confirming Changes

Apply vs. Set vs. OK vs. Commit
All three terms confirm changes. OK is associated with modal dialogs. Apply is more common than Set, and is a more obvious action term. Commit is a database term that is not commonly used in mass-market applications.

Apply vs. Save for Later vs. Save As
As detailed above, Apply confirms changes and commits data to the database. Save for Later saves changes to the database and returns the user to the originating page (usually an object list) with a confirmation that the object was saved and is in an incomplete status. A status column should be available on that object list page stating that the object is still in draft status. The user can then complete work on the object when needed.

Save As is used when an object or file is to be saved to the local disk under a new or modified name.

Apply vs. Enter
Apply confirms changes to a page. Enter can easily be confused with the Enter key, which may have different functions depending on the current focus.

Apply vs. Submit
Apply confirms changes made to the current page. Submit routs an object for approval in a workflow process.

Apply vs. Go
Go initiates an action or actions that draws a section of the page. Its most common Web usage is for Search operations, but it is also used to confirm changes in a page. If Go is used to confirm changes in a page, it would only make sense if it leads to a page that has not yet been visited, because Go implies moving away into a new space. Typically, lists of results with additional levels of data contain links, so do not require another Go button.

Apply means to confirm changes to a page, with display of a new page as the result. This term has extensive usage in GUI environments, and should not be used interchangeably with Go. We need to define specific cases, apart from Searching, where Go should be used rather than Apply. One criterion is that the term Apply may seem inappropriate in some contexts.

Canceling Changes and Clearing Settings

Cancel vs. Close vs. Back
Cancel aborts 1-, 2-, or 3-plus-step transactional pages. Processes may be either linear or non-linear (where steps may be completed in any order). Back returns to the previous step. Close is only used with secondary windows (deprecated).

Cancel vs. Return to (xxx)
Cancel aborts a 1-, 2-, or 3-plus-step transactional process, whereas Return to (xxx) navigates to a prior page or a page that is higher in the hierarchy. Do not use Return to (xxx) in place of Cancel, because users will be uncertain whether the process has been aborted or not. Transactional pages are distinct from the rest of the application - so using Cancel is parallel to canceling a dialog box or conventional wizard process.

Reset to Default vs. Reset
Reset is ambiguous, as users don't know which settings will be returned - original, or last settings. Display of the full term in a rollover may not be sufficient to avoid confusion.

Use Reset to Default primarily for Preferences, to return preference settings to those shipped by Oracle, or those defined by customer IT departments. Reset to Default is also commonly used in applications that specify network settings.

Revert vs. Restore vs. Reset to Last Settings vs. Undo
These terms all refer to canceling previous changes. Undo cancels the last change to a single element of a page, whereas Restore/Revert/Reset to Last Settings have the same function of returning a page to its last saved state, which may affect the settings of any number of page elements, and makes Undo redundant.

Both Restore and Revert have the advantage of being readily distinguished from Reset (to Default). When this specification is generalized to include Server Tools, the term Restore will be problematic, because it is reserved for DB Restore operations.

Clear/Clear All vs. Reset to Default vs. Revert
Clear and Clear All can be used in any case where the user needs to enter and/or select new settings. Their primary function is to save the user from having to select and delete/edit multiple fields. Do not use Clear/Clear All if you want to retain any values in input fields.

Use Reset to Default specifically to return all settings on a page, including input fields, to the out-of-box state -- depending on the application, this may mean that input fields are populated with default values. Reset to Default will most commonly be used for Preferences.

Use Revert to return settings to their previous state. The first time a user opens a page, Revert may have an identical result to Reset to Default, but this may not be the case during subsequent sessions, where Revert returns the last settings specified by the user.

The behavior of a choice list helps illustrate the differences between these three actions:

• Clear/Clear All moves the selection to the default entry in the choice list.
• Reset to Default moves the selection to the default entry specified by Oracle Applications or the customer IT group.
• Revert moves the selection to the entry that the user selected the last time the user opened the page, or caused it to be redrawn.

Making Copies of Data

Copy and Save As vs. Duplicate
Copy is a common GUI term for placing a duplicate of an object in a temporary storage buffer (Clipboard) prior to pasting it at another location under the same name. Copy operations in conventional applications do not require use of dialogs.

Save As is a common GUI term for saving a file to disk under another name, and requires input in a dialog.

Duplicate is an Oracle Applications term for placing a copy of an object immediately below it, providing local Copy and Paste functionality in a single step. Duplicate can also be used to navigate to a duplicated object page.

Reloading the Page

Refresh Data vs. Refresh (xxx)
Refresh Data reloads data from the database and refreshes the page. Ask whether the user wants to reload data from the database, then either refresh data or refresh both data and page.

Refresh (xxx) redraws the specified object without querying the database.

Navigation and Selection

Next vs. Forward
Moves to the next page in a process (commonly used in a step-by-step or linear process). Next is short and direct, and more common. One example of a non-linear process is a registration process where steps may be completed in any order.

Next vs. Next (nnn)
The Next (nnn) link displays the next nnn set of records, whereas the Next button is used to move through steps in processes.

Back vs. Previous (nnn)
The Previous (nnn) link displays the previous nnn set of records, whereas the Back button moves to the previous page in a process (commonly used in a step-by-step or linear process).

Searching

Search vs. Find
'Find' is the old Oracle Applications standard term, which is being replaced by Search in both Java and HTML applications.

Search vs. Go vs. Iconic search button
Search displays a page where a user can define search criteria. Go performs the defined search. The Search iconic button is displayed next to an input field or LOV, and performs a search for matching records.

Data Transfer

Import and Export vs. Upload and Download vs. Synchronize
Import and Export are used exclusively for transferring data in non-database formats, such as spreadsheet or delimited formats. Upload and Download are used for transfer of data in database format between server sites and local machines (including hand-help devices). Synchronize is used to match up data and/or metadata between two systems, such as between servers or between a server and a client system/device so the user can work offline, or between a Forms and BLAF application.

Modifying Display of Data (customization)

Personalization vs. Customization
Personalization refers to the process where a user modifies the display of his or her own content. Customization is a deprecated term that is associated with arduous setup of an application.

Personalization vs. Setup vs. Administration
Users initiate a Personalization process by selecting a "Personalize" button. Application administrators and project managers prepare an application for their users with "Setup" functionality -- typically a one-time process. Administrators perform ongoing maintenance, including reconfiguration of Setup parameters, with "Administration" functionality.

Exiting Applications

Logout vs. Exit vs. Quit
Logout typically means breaking a connection without leaving the environment, whereas Exit and Quit typically mean leaving an environment. Currently, only Logout is used in Oracle Applications, including the Portal, which allows users to break the connection but continue to operate in the Portal in "guest mode."

Actions That Affect Data

The following actions allow the user to specify changes, and may navigate to another page:

• Create (xxx)
• Update (xxx)
• Add (xxx)

The following actions validate the content/changes in the current page, and may navigate to another page:

• Apply
• Submit (xxx)
• Go
• Review
• Next (in step-by-step process)
• Finish (in step-by-step process)
• <Perform Context-Specific Action>

The following actions invalidate the content/changes in the current page, and may navigate to another page:

• Revert
• Reset to Default
• Clear/Clear All
• Cancel

Open/Closed Issues