Dynamic Tabs Work Area Guidelines Print this Page
Version 2.0.0.6  
 
Contents
Return to Top
  1  Description
       1.1  Data Integrity
  2  Common Tab Behavior
       2.1  Opening a Dynamic Tab
       2.2  Closing a Dynamic Tab
  3  Tab Types Employed in the Dynamic Tabs Model
       3.1  Work Area Entry Tab
       3.2  Manage Tab
            3.2.1  Subflows That Originate on a Manage Tab
            3.2.2  Opening Manage Tabs
       3.3  Detail Tab
            3.3.1  Detail Tab Naming Guide
            3.3.2  Opening Detail Tabs
            3.3.3  Record Navigation Inside a Detail Tab
            3.3.4  Drill-Down Navigation Inside a Detail Tab
            3.3.5  Record Navigation Inside a Detail Tab
       3.4  Compare Tab
  4  Related Documentation


Note: All images in this document are illustrative and do not represent actual Oracle Fusion Applications user interface (UI) screens.
 
1  Description
Return to Top

Each Oracle Fusion tab model is designed to organize information in a manner that best supports the unique requirements of a work area. The choice of tab model depends on the complexity of a work area's objects, tasks, business goals, and processes. The Dynamic Tabs model is optimized for business processes that require users to work on multiple objects or tasks in parallel.

The Dynamic Tabs model combines a persistent Work Area Entry tab with dynamic tabs that users open for each task or object instance. With the exception of the static Work Area Entry tab, this model's tabs are dynamic because they open and close as a result of direct user interaction. The dynamic tabs model enables users to open task flows in dynamic tabs in a number of different ways (for example, from within another tab or from the Tasks or regional area Search panes).

Once users open dynamic tabs, they can easily switch between them. Users can close dynamic tabs directly or click final page actions, such as Save and Close, Submit, and Cancel.

The Dynamic Tabs model employs four tab types that vary in the ways that they can be opened, navigated within, and closed. The four tab types are:

  • Work Area Entry tab
  • Manage tab
  • Detail tab
  • Compare tab

A fundamental principle of the Dynamic Tabs model is that the Work Area Entry tab, Manage tab, and Compare tab remain available as sources (they do not close) from which users can open multiple Detail tabs. For this reason, navigation inside a tab is permitted only within a Detail tab.
 

Figure 1.1. Partial screen shot of a dynamic tabs work area

The Dynamic Tabs model comprises multiple elements, as indicated in the following example.

Figure 1.2. The anatomy of dynamic tabs

Follow these guidelines:
  • Dynamic tabs use the Level 2 tab bar located in the application's primary layer. Tab text is not truncated. Tab component overflow is handled by overflow icons.
  • In the dynamic tabs model, all pages must appear inside a tab.
 
1.1  Data Integrity
Return to Top

Consider the following:

  • Deselecting a tab by selecting or opening another tab does not trigger validation on the unselected tab.
    For more information on validation, see the Save Model Guidelines.
  • Direct user interaction on a selected tab is the only way to update tab content.
    • Data changes made by other users or background processes do not automatically update tab content.
    • Changes made in one tab do not automatically update content in other tabs. Users must manually update affected tabs to see changes in data.
  • Users do not have to save changes in a current tab before selecting or opening another tab.
    • On each dynamic tab, data changes are cached until users initiate an explicit save or submit action.
  • When users try to navigate away from a work area in which there are unsaved changes, the system must launch the Unsaved Changes Warning dialog box.
  • Returning an unselected tab to a selected state does not trigger an automatic refresh of the tab's data.
 
2  Common Tab Behavior

Return to Top

The Dynamic Tabs model uses two distinct tab types: static and dynamic.
 
Static tabs:
  • Are always open and cannot be closed
  • Appear in a fixed position at the start of the tab bar
  • Are employed for the Work Area Entry tab

Dynamic tabs:

  • Are opened and closed by way of direct user interaction
  • Appear after the static tab on the tab bar
  • Are employed for the following tabs:
 
2.1  Opening a Dynamic Tab
Return to Top

New tabs always open to the right of existing tabs.

Figure 2.1. New dynamic tabs open after existing tabs

Consider these guidelines for dynamic tabs:

  • The dynamic tabs model has a limit of 10 open tabs.
    • When users attempt to open more than the allowed number, the system launches an Error message dialog box that states, “Currently, the maximum number of tabs (10) is open. Please close at least one tab and try again.”
  • If there are more tabs than fit on the tab bar, the overflow is handled by overflow icons.
  • If users open a new dynamic tab from a modal dialog box, the dialog box closes and a new tab opens and becomes selected.
  • For more information on the interaction models, see the Manage Tab, Detail Tab, and Compare Tab sections of this guideline.
  • A tab appears in one of two states: selected or unselected.
    Users can select only one tab at any time. All other tabs appear in an unselected state (see figure 1.1).
    • When a new tab opens, it becomes the selected tab.
    • When a Manage or Detail tab is open and users again select its corresponding link, a duplicate tab does not open. Instead, that tab appears in a selected state.
 
2.2  Closing a Dynamic Tab
Return to Top
When users close a dynamic tab, the previously selected tab becomes selected. Consider the following restrictions on dynamic tabs:

  • Users can close a dynamic tab only when it is in a selected state. Users cannot close a dynamic tab when it is not selected.
  • A tab closes after users select a final page-level action.
    • If users select a final page-level action on a page to which they have navigated inside a Detail tab, selecting that final action ultimately navigates them back to the root page in that tab. For more information, see the Drill-Down Navigation section of this guideline and the Page Actions Guideline.
  • Users can close dynamic tabs by clicking the Close icon button on a selected tab.
    • Users cannot close the Work Area Entry tab or other static tab types.
    • Only dynamic tab types should have a Close icon button.
  • To be consistent with the Save Model Guidelines, the Unsaved Changes warning dialog box appears when applicable.
  • Where appropriate, users can close a dynamic tab from a dialog box.
 
3  Tab Types Employed in the Dynamic Tabs Model
Return to Top

The Dynamic Tabs model employs four tab types to effectively manage the number of open tabs and minimize tab proliferation. The four dynamic tab types are:

  1. Work Area Entry tab
  2. Manage tab
  3. Detail tab
  4. Compare tab

This table compares the tab types employed in the Dynamic Tabs model.

  Work Area Entry Tab Manage Tab Detail Tab Compare Tab
Purpose

Every work area in this model must have a persistent Work Area Entry tab. Typically, this is the Overview tab.

By default, the Work Area Entry tab is always the selected tab when users first navigate to a work area.

This tab type contains transactional search functionality or pooled search results.

Work areas contain a Manage tab for each object type.

 

The tab displays the details of a specific object or task instance within the context of a specific state.

Detail tabs are typically employed for the following actions:
- Create
- Edit
- View (read-only)
- Others

This tab refreshes with new content each time that users select different objects or processes for comparison.

 

How many tabs of this type can be in one work area? One One for each object type One for each object instance One
Is navigation permitted inside this tab type? No No

Yes

Note: With drill-down navigation, the tab text remains unchanged. The page header and content update.

No
Position on the Tab Bar 

Always the first tab on the tab bar

These tabs always appear to the right of the Work Area Entry tab.

Tab Type Static: Always open, cannot be closed, and appears in a fixed position Dynamic: These tabs open and close as a result of direct user interaction.
Opening Behavior

Always open

Open as a result of direct user interaction.
A new tab always opens to the right of existing tabs.

Closing Behavior

Cannot be closed

Close as a result of direct user interaction.
When selected, the tab can be closed by way of page actions or its Close icon button.
When not selected, the tab can be closed by clicking the Close icon button.

Table 3.1. Comparison of tab types employed in the Dynamic Tabs model
3.1  Work Area Entry Tab
Return to Top

Each dynamic tab work area has a persistent tab that supports the work area entry experience by orienting users to the state of the work. The Work Area Entry tab has the following characteristics:

  • The Work Area Entry tab appears in a static tab type that is open and is selected by default when users first navigate to the work area.
  • The Work Area Entry tab appears in a fixed position at the beginning of the tab bar.
  • The Work Area Entry tab cannot be closed.

An Overview tab is recommended for the Work Area Entry tab because it provides status and summary information across all objects in the work area. The tab text and page header for this tab read "Overview."

  • If the work area does not contain business intelligence, a Worklist, or analytics, such as a static Manage tab, can be employed instead of the Overview tab. 
    • Using a static Manage tab is considered a less desirable entry experience because, unlike the Overview tab that delivers tasks and information to the user, a Manage tab requires users to search.
    • The tab name should be "Manage <Object Type> or <Business Process>" (for example, "Manage Intrastat Transactions").
    • If "Manage <Object Type>" is employed as the Work Area Entry tab, the corresponding task name should not appear in the Tasks pane.

In rare cases, you can also possibly employ more than one static tab in a dynamic tabs work area. Work with your pillar user experience team to determine whether multiple static tabs are appropriate for your flow. If you use multiple static tabs, ensure that these conditions are met:

  • No more than three static tabs can appear in a dynamic tabs work area.
  • The Work Area Entry tab always appears first in the tab bar, and the Work Area Entry tab is selected by default when users first accesses a work area.
  • If you use other static tabs, these tabs should appear after the Work Area Entry tab.
  • The dynamic tabs should always appear after the static tabs.

For more information, see:

 
3.2  Manage Tab
Return to Top
The Manage tab type includes pages that contain transactional search functionality. The following attributes apply to the Manage tab:
  • If a work area has multiple objects, each object has its own Manage tab.
  • A work area has no more than one Manage tab for each object type.
  • The Manage tab is typically a dynamic tab unless it is employed as the Work Area Entry tab (instead of an Overview tab).
  • Users cannot navigate inside of this tab type.
 Figure 3.1. In a work area, each object type will have its own Manage tab

Some task flows begin with transactional search. In flows such as this, a subflow may open a dialog box or open in a new tab. You cannot drill down within a Manage tab.

 
3.2.1  Subflows That Originate on a Manage Tab
Return to Top
Users cannot navigate inside a Manage tab. Therefore, when users click an action or detail, the following may result:
  • A dialog box opens.
  • A new tab opens or an open tab is selected.
 
3.2.2  Opening Manage Tabs
Return to Top

When opening a new tab, Tasks pane links and regional area searches interact with Manage tabs in similar ways, but they vary in their interactions with Manage tabs that are already open. Table 3.2 highlights these interactions.

User Action Manage Tab
Not Yet Open Open
  • Select a task in the Tasks pane.
  • Select a Manage task from the global Recent Items or Favorites menus.
  • Conduct a regional compact search.
  • Select a saved search from the Regional Area Search pane.
  • Select a summary number commonly found on a Work Area Entry tab.
  • Select a summary number from the Watchlist.

A new Manage <Object Type> tab opens and is selected by default.

For example, Manage Shipments

The corresponding Manage <Object Type> tab is selected.

For more information on this interaction, see the Transactional Search design pattern set.

If users have edited attributes of one or more records in the existing search results, a warning dialog box indicating unsaved changes must appear.

For more information see the Save Model Guideline and the Warning Message design pattern.

Table 3.2. Opening a Manage tab

Users can open Manage tabs from the Tasks and Search panes in the regional area:

Figure 3.2. Each object type in a work area has its own Manage tab

When a Manage tab is already open, clicking its corresponding link in the Tasks pane selects that tab. Here is a diagram that illustrates this Tasks pane interaction.

Figure 3.3. No more than one Manage tab opens for an object type in a Dynamic Tabs work area
 
3.3  Detail Tab
Return to Top
The dynamic Detail tab displays details of a specific object or task within a specific state. For the purposes of this guideline, the following definitions apply:
  • Object type: A type of entity (for example, an item is a common object type in Oracle Supply Chain Management).
  • Object: An object is a specific instance of that object type (for example, Item WM100).
  • State: A state is one of the possible conditions in which an object may exist.
    • Common examples in Oracle Fusion include read-only and editable states such as Item: WM100 (read-only) and Edit Item: WM100.

Detail tabs are used for the following actions:

  • Create
  • Edit
  • View
  • Others

Detail tabs include the following characteristics:

  • The Detail tab type is the only tab type inside of which users can navigate.

  • Different states of the same object may appear simultaneously in separate tabs.
    • Conversely, a specific state of an object may appear in no more than one tab at a time.
      • For example, only one tab can display Edit Shipment: 595. If, on the Manage Shipments tab, users highlight Shipment 595 and click Edit, the corresponding unselected tab is selected. A duplicate of this object state does not open in a new tab.
      • This behavior may not be consistent when record navigation is employed inside a Detail tab.

    • Tab text displays the object type and object name but, unlike the page header, does not include the action name (see Table 3, the Naming Guide in this document). The page header is governed by the Header Syntax section of the Headers Usage Guideline. Here are examples of two tabs, each of which contains a different state of the same object:
      • Tab text: Shipment: 123; page header: Edit Shipment: 123
      • Tab text: Shipment: 123; page header: Shipment: 123 (read only) 

  • If users have open tabs that represent different states of the same object, changes made in one tab do not automatically update data in other related tabs. Users must manually refresh a related tab to update its data.
    • For example, changes made on the Edit Item: WM100 tab will not cause content to automatically refresh on the read-only Item: WM100 tab.
       
  • For information about tab closure, see the Closing a Dynamic Tab section of this document.

Figure 3.4 shows an example of two tabs that represent edit and view states of the same object. Note that page headers should follow the Header Syntax section of the Headers Usage Guideline.

Figure 3.4. Examples of two tabs that represent edit and view states of the same object

Here is a naming guide table for tab text and page headers inside Detail tabs.

Action Tab Text and Page Header
Edit Tab text: <Object Type>: <Object Name>
Example: Shipment: 123

Page header: Edit <Object Type>: <Object Name>
Example: Edit Shipment: 123

View Tab text and page header: <Object Type>: <Object Name>
Example: Shipment: 123

Create <Object Type>
(Employed in a case where the object name is unknown)

Tab text and page header: Create <Object Type>
Example: Create Shipment

Create <Object Type>: <Object Name>
(Employed in a case where the object name is known or system-generated)

Tab text: <Object Type>: <Object Name>
Example: Shipment: 456

Page Header: Create <Object Type>: <Object Name>
Example: Create Shipment: 456
 
For more information, see the Create design pattern set.

Other Actions Performed on an Object Instance

Note: The object name does not display in the page header if the action applies to multiple objects on that tab

Tab text: <Object Type>: <Object Name>
Example: Shipment Line: WM100

Page Header: <Action><Object Type>: <Object Name>
Example: Split Shipment Line: WM100

Other Actions Performed on Multiple Objects
Tab text and page header: <Task name>
Example: Record Shipping Costs
Subflow Within a Detail Tab Type

Tab text: <Object Type>: <Object Name>
Example: Shipment: 123

Page Header: <Action><Object Type>: <Object Name>
Example: Record Lot and Serial Numbers: Shipment 123

Table 3.3. Dynamic tab text does not always match the page header
3.3.1  Opening Detail Tabs
Return to Top

Tasks pane links and regional area searches open new Detail tabs in similar ways. However, with the exception of the Create action, interactions differ when a Detail tab is already open. Table 4 shows a comparison of these interactions.

User Action Detail Tab 
Not Yet Open Open
Select a Create task in the Task Pane. A new tab opens and becomes selected. A new tab opens and is selected. Multiple Create tabs can be open simultaneously.
Conduct a Regional Compact Search.

When a team employs the Shortcutting design pattern to link directly to a Detail tab (instead of displaying the single result inside a Manage tab), a new Detail tab opens and is selected by default.

Note: Applying the Shortcutting design pattern to a search conducted in the local area of a Manage tab is an open issue.

 

When a single search result is found and the team uses the Shortcutting Design Pattern to link directly to a Detail tab (instead of displaying the single result inside a Manage tab), the corresponding Detail tab becomes selected. This does not cause tab content to automatically refresh.

Note: Applying the Shortcutting design pattern to a search conducted in the local area of a Manage tab is an open issue.

Initiate a flow from the local area of another tab.
(For example, select search results on a Manage tab.)
A new dialog box opens or a new tab opens and becomes selected. A new dialog box opens or the corresponding unselected tab becomes selected. Tab data does not automatically refresh.
Table 3.4. Opening a Detail tab

The following characteristics apply to Detail tabs:

  • Multiple tabs that represent the same object can open only for unique states of that object.
  • A Detail tab (other than for Create) should not be duplicated. For example, two unique Create Shipment tabs can be open at the same time, but two tabs for Edit Shipment: 123 cannot.
  • If an object state that already appears in an open Detail tab is called again, the open Detail tab is selected without its content automatically updating.

Note: Follow these implementation guidelines to prevent the duplication of a Detail tab:

  • When opening an object state in a dynamic tabs work area, set the property called reuseInstance to True. When a flow is already open in an existing tab, clicking a link to open the same object state selects that tab but does not refresh its data.
  • If the reuseInstance value is incorrectly set to False, a duplicate dynamic tab containing that object state (for example, Edit Shipment: 123) opens.
 
3.3.2  Record Navigation Inside a Detail Tab
Return to Top

When users navigate from within a Detail tab, the subflow may open in a dialog box or, in the case of an open Detail tab, the contents can update by way of navigation within that tab. Two types of tab navigation are available within a Detail tab:

 
3.3.3  Drill-Down Navigation Inside a Detail Tab
Return to Top

Based on the Record Navigation Drill Down Details Design Pattern, drill-down navigation drills down into and up out of a Detail tab. Drilling down inside a Detail tab results in the following:

    1. Tab text: Remains unchanged.
    2. Page header: Updates to reflect changes in navigation and resulting tab content.
    3. Navigation path: For every level of drill down, the navigation path is retraced in reverse when users select each level's final page-level action. The final step is tab closure by way of a page-level action.
      • If the user drills down from a read-only state to an editable state, clicking a final action on the editable state closes the tab. Users do not return to the read-only state before the tab closes. For more information, see the Page Edit design pattern.
    4. For more information about final page actions, see the Page Actions Guidelines.

In drill-down navigation, the tab text remains the same while the page header updates to reflect the task or subobject to which users have navigated. Here is an example of this flow type.

Figure 3.5. Initiating a drill-down action from within a Detail tab
3.3.4  Record Navigation Inside a Detail Tab
Return to Top

The record navigation model applies to navigation among peer objects inside a Detail tab. This model occurs most often as a result of the following:

Here are common types of record navigation that can be employed inside Detail tabs.

Figure 3.6. Examples of linear and nonlinear record navigation used only within Detail tabs

Record navigation within a Detail tab yields the following changes:

  1. Tab text: If not embedded inside a drill-down flow (see figure 3.5), tab text updates to reflect changes in tab content.
  2. Page header: The page header updates based on navigation and reflects changes in tab content.
  3. Navigation path: The path differs from the drill-down model in that tab content does not retrace its navigation path to the point of origin.

In the record navigation model, Detail tab text and page headers update as users navigate across peer objects.

Figure 3.7. Representation of the Record Navigation model
3.4  Compare Tab
Return to Top
The dynamic Compare tab is recycled each time that users select different objects or processes for comparison. Each dynamic tabs work area contains no more than one reusable Compare tab. Users cannot navigate inside this tab type:

Here is an example of tab text and page header naming on a Compare tab.

Figure 3.8. Tab text and page header naming on Compare tabs
4  Related Documentation
Return to Top
 
About Oracle | Legal Notices | Terms of Use | Your Privacy Rights