Work Area Overview Page Content Display Guidelines Print this Page
Version 2.0.0.0  
 
Contents
Return to Top
  1  Introduction
  2  Filtering, Switching Data, and Changing Data Views
  3  Filtering
      3.1  Subtab Filters
      3.2  Filter Components on a Table Toolbar
      3.3  QBE in a Table
      3.4  Filter Components Inside Content Sections
      3.5  Filter Placement and Data Synchronization
  4  Switching Data
      4.1  Switching the Data Using a View Field
      4.2  Switching the Data Type by Using a Data Type Choice List
  5  Changing the Data View
      5.1  Changing the Data Representation
      5.2  Changing the Data View by Using Subtabs
      5.3  Changing the Data View by Using a View By Choice List
  6  Combining Filter, View By, and Data Type Components
  7  Data Synchronization: Filters and Data View Components
  8  Search Button Usage
  9  Glossary
10  Related Documentation
 

Notes:
• All images in this document are illustrative and do not represent actual Oracle Fusion application user interface (UI) screens.
• See the Glossary at the end of this guideline.

 
1  Introduction
Return to Top

A work area contains the complete set of tasks, reports, embedded analytics, searches, and other content that users need to accomplish a business goal. For more information, see Introduction to Work Areas.

The work area entry page is the first page in every Oracle Fusion work area that users see when they navigate to a work area from the Navigator. Work area Overview pages, the preferred type of entry page, provide actionable status and summary information across objects in the work area. They present data as information designed to help users identify and act upon open issues within the work area. For more information on work area Overview pages, see the Work Area Entry Page Guidelines.

A well-designed work area Overview page enables users to manipulate data views of status and summary information. Such interactions can help users quickly see and understand data in new ways that more quickly yield greater clarity and insights. This guideline offers direction about how to filter and change perspectives on work area Overview page content.

 
2  Filtering, Switching Data, and Changing Data Views
Return to Top

Overview pages can display rich, useful information if the pages are well organized and not overly dense. Common methods of shaping the context in which data is presented include filtering, switching data, and changing views of the same data by using subtabs and choice lists.

  • Selection of the most appropriate component type should be based on an understanding of the user role, an evaluation of the density of information on the page, and available page real estate.
  • Placement should ensure that related data remains synchronized across multiple content sections on the page.

Table 2.1 provides a comparison of common filter and view components.

Consideration Subtabs Choice List Component

Visibility

Users can immediately view available options in the subtab labels.
Users must open the choice list to see the full list of available options.
Page Real Estate
Subtabs occupy more page real estate than a choice list. Occupies less page real estate than subtabs.

Number of Filter Values

If a large number of subtabs would clutter the page or be visually overwhelming to users, consider using a choice list. A choice list consumes the same amount of page real estate regardless of the number of items that it contains.

Level of Complexity

Subtabs are suitable for all user types as long as the number of subtabs or length of labels do not require the use of the overflow icon. Because choice list content must first be opened to be seen, it is more suitable for medium to power users.
Table 2.1. Comparison of component options for filtering, switching data, and changing data views
 
3  Filtering
Return to Top

Consider filter placement to ensure that related data remains synchronized across multiple content sections on the page. Content filtering enables users to distill a data set according to one or more defined attributes or values. The result is a more tailored and relevant subset of data. For example, users can filter a set of search results by status or due date.

Filters can be:

  • Subtabs
  • One or more choice lists on a toolbar
    For example, a choice list on a table toolbar that enables users to filter according to status.
  • Query By Example (QBE) in a table
  • One or more choice lists inside a content section
    For example, a date field inside a subheader and above:
    • A component such as a graph or gauge
    • Subtabs that contain related data
    • Multiple subsections
 
3.1  Subtab Filters
Return to Top

Subtabs can act as filters that provide subsets of objects based on attributes. This approach can be particularly useful if users do not need to see the full set of data at any one time, if a table is required in one subtab and a tree table in another subtab, or if table columns are different in each subtab.

For example, in figure 3.1, each subtab displays information on a different status of the same object type. Notice that tab labels reflect the object’s status followed by a summary number that indicates the number of records in that subtab.

Figure 3.1. Subtabs filter orders by status. Summary information is included in the label
 
3.2  Filter Components on a Table Toolbar
Return to Top

One or more filter components can be employed on a table toolbar. For more information, see the Toolbar Filters Pattern.

Place a choice list filter on a table toolbar only when data in the table does not require synchronization with other data on the page.

Figure 3.2. Example of a filter on a table toolbar
 
3.3  QBE in a Table
Return to Top

The QBE table element can be employed on an Overview page and is best suited for expert users. For more information, see the Table Filters Pattern Set and the Query By Example Pattern.

 
3.4  Filter Components Inside Content Sections
Return to Top

One or more filter components can be employed inside a section to apply to all content within that section, including subtabs and subsections. For example, a date field can appear inside a section and above one or more of the following components:

  • Multiple subsections
  • Subtabs that contain related data
  • A graph or gauge

Note:
Filter or refresh related data inside different content sections at the same time to avoid asynchronous data (see figures 3.3 and 3.4).

 
3.5  Filter Placement and Data Synchronization
Return to Top

It is important to consider filter placement to ensure that related data in multiple sections on the page remains synchronized.

Place one or more filter components on a table toolbar when data in that table does not need to be synchronized with related other data on the page.

Place one or more filter components inside a content section when related data in multiple sub-sections or subtabs must remain synchronized. For example:

  • When all subtabs within a content section contain related data, place the filter component inside the content section and above the subtab bar (see figure 3.3).
  • When all subsections within a content section contain related data, place the filter component inside the section and above the subsections (see figure 3.4).
    In subsections or subtabs that contain unrelated data, synchronization is not an issue.
  • When a content section contains a graph or gauge, place the filter component inside the content section and above the graph or gauge (see figure 3.5).
Figure 3.3. Example of a filter placed above subtabs in which the same data is presented by carrier, customer, order, and shipment priority
>Figure 3.4. Example of a date filter that applies to all content within that section including nested subsections
Figure 3.5. Example of a filter component inside a content section and above a graph
For more information, see:
 
4  Switching Data
Return to Top

Switching data enables users to view:

  • Related data within the same page real estate
  • Different types of data associated with the same objects within the same table, tree table, or graph.

Oracle Fusion offers two ways to switch data:

  • Switching the data using a View field
  • Switching the data type using a Data Type choice list
 
4.1 Switching the Data Using a View Field
Return to Top

The View field enables users to access different types of related data within the same page real estate.

Figures 4.1 and 4.2 show examples of two subsections, each dedicated to a single object type or attribute: Item and Customer. Within each subsection, users select the data that they want to view from the View field. The prompt is View and the choice list value is the name of the corresponding graph.

In figure 4.1, a line graph in the Item subsection depicts order frequency by time. After users select a different analytic title in the Item section’s View field, a new graph appears in that content section (see figure 4.2).

In figure 4.2 the same Item subsection shows a bar graph depicting the count of holds for this item by hold name. In each case, the graph title appears in the View field.

Figure 4.1. Example of the Item subsection View field set to Order frequency by time
Figure 4.2. Example of the Item subsection’s same View field set to Count of holds for this item by hold name

For more information, see the Grouping Related Analytics with the View Choice List section of the Analytic Display Guidelines.

 
4.2  Switching the Data Type by Using a Data Type Choice List
Return to Top

The Data Type field enables users to view different types of data associated with an object. In figures 4.3 and 4.4, users can switch between viewing the count and the value of the same set of fulfillment lines.

Changing the data type results only in changes to table cell content while column headers remain consistent.

  • Figure 4.3 shows counts for each customer's fulfillment lines.
  • Figure 4.4 shows the value of the same customer fulfillment lines.
Figure 4.3. Example of the Data Type choice list set to Count
Figure 4.4. This is the same table shown in figure 4.3, except that the Data Type choice list is set to Value
 
5  Changing the Data View
Return to Top

Changing the data view enables users to examine the same data from different perspectives and in different formats. Oracle Fusion offers two ways to change the data view:

  • Changing the data representation enables users to view the same data in different formats such as tables, tree tables, or graphs.
  • Subtabs and the View By choice list offer multiple views of the same data in different contexts.
 
5.1  Changing the Data Representation
Return to Top

Users can view the same data set in different formats, for example, in a table, tree table, hierarchy viewer, or in different graph types. For more information on switching the data representation, see the Switching the Type of Information Visualization with Show Graph or Table section of the Analytics Display Guidelines.

Figure 5.1. Example of a data set represented in a table
Figure 5.2. This is the same data set shown in figure 5.1.1, but represented in a graph
 
5.2  Changing the Data View by Using Subtabs
Return to Top

Subtabs enable users to select the context in which to view the data. In each subtab, totals remain the same but contexts and structures vary.

Figures 5.3 and 5.4 illustrate two examples from the Shipments work area Overview page. Subtabs enable users to see the same data organized in four different ways: by carrier, customer, order, and shipment priority. Totals remain consistent across each subtab. Only the component and context in which data is grouped change.

In figure 5.3, the shipping agent selects the Carrier subtab to focus on preparing shipments for a carrier’s standard pickup time. In figure 5.4, the shipping agent can shift his focus to getting high priority shipments out the door.

Figure 5.3. The Carrier subtab displays data from a carrier-centric perspective
Figure 5.4. The Shipment Priority subtab displays the same data set but from a different perspective. Note that the totals match those shown in figure 5.3
 
5.3  Changing the Data View by Using a View By Choice List
Return to Top

Similar to subtabs, users can select the context in which to view the data in the View By choice list. For example, users can view fulfillment lines exceptions by item or customer. The prompt is View By. Changing the dimension in which the data appears enables users to view the same information and same data type within different contexts and organizing structures.

The View By choice list must be placed above, rather than on, a component such as a table or tree table, or inside individual subtabs. This placement is required because selecting a different value in the View By choice list often changes the type of component it governs (for example, a table in one view and a tree table in another view) or a part of the same component type (for example, different columns appear in each view of a table or tree table).

Figures 5.5 and 5.6 show two different views of the same fulfillment lines exceptions data. In figure 5.5, exceptions are organized by customer, as can be seen in the View By choice list and the table’s first column. In figure 5.6, exceptions are organized by item. Note that in each view, totals remain the same and all values are represented as currency.

Figure 5.5. Example of the View By choice list set to Customer
Figure 5.6. Example of the same View By choice list set to Item
For more information, see the Dividing Information with the View By Choice List section of the Analytic Display Guidelines.
 
6  Combining Filter, View By, and Data Type Components
Return to Top

The filter components, View By and Data Type choice lists described in preceding sections can be combined to further refine the data views. Per the Data Synchronization: Filters and Data View Components section of this guideline, carefully consider the placement of each component so that related data remains synchronized across multiple regions when users filter or change data views.

Figure 6.1 shows a table inside a content section. A View By choice list, a Data Type choice list, and multiple content filters are employed. In this example:

  • The View By and Data Type choice lists are placed above the table because each can change the type of component it governs (for example, a table in one view and a tree table in another view) or a part of the same component (for example, different columns appear in each view of a table or tree table).
  • The View By choice list enables users to view data by customer or item.
    • When the value in the View By choice list is Customer, the table itself changes: the first column header is Customer.
    • When the value in the View By choice list is Item, the first column header changes to Item.
    • When users change the View By or Data Type choice lists, content filters remain unchanged.
  • The Data Type choice list enables users to view numerical values as counts or values.
  • Filters are placed on the table toolbar.
    Users can filter by customer and item. Because two content filters are used, you must include a Search button.
    For more information, see the Toolbar Filters Pattern.

Rule of thumb: If, in most cases, users would change the value of each filter, View By and Data Type component independently, you do not need a Search button.

Figure 6.1. Example of a content section in which the View By and Data Type choice lists are placed above a table and filters are placed on the table toolbar
 
7  Data Synchronization: Filters and Data View Components
Return to Top

You can assemble filters, View By, and Data Type choice lists in different combinations and in different locations on a page. Locations of filter components, View By and Data Type choice lists can affect data synchronicity across the Overview page.

View By and Data Type choice lists
Place View By and Data Type choice lists inside a section and above a component such as a table, tree table, tree, graph, or gauge.

Filter Components
Place one or more filter on a table toolbar when data does not require synchronization with other data on the page (see figure 7.1).
 
Figure 7.1. Example of a component-level filter on a table toolbar
Place one or more filter components inside a content section and above subtabs when either of the following is true:
  • Subtabs contain related data that should remain synchronized
  • The same filters apply to content in all tabs

One or more filters can be placed inside a subtab and on a table toolbar when data does not require synchronization with data in other subtabs or elsewhere on the page (see figure 7.2).

Figure 7.2. Filters inside a content section apply to all content within that section, including content inside subtabs or subsections
Place one or more filter components inside a content section and above subsections when they contain related data that should remain synchronized (see figure 7.3).
Figure 7.3. Example of a filter that applies to all content within that section, including multiple subsections
Place one or more filters inside a subtab or section and above a graph or gauge (see figure 7.4).
Figure 7.4. Example of a filter inside a content section and above a graph component
 
8  Search Button Usage
Return to Top

When combining filters and data view components, the use case and the type and number of filters and data view components employed determine whether a Search button is required.

Note:
References to filters, View By choice lists and Data Type choice lists in table 8.1 apply only to form fields (specifically, choice lists and radio button groups).

Combination Is a Search Button Needed?

An input or choose date filter component

Yes. The input or choose date filter component always requires a Search button.
An input or choose date filter component with a View By choice list, a Data Type choice list or both data view component types Yes. Use a Search button after the input or choose date filter component.
A select-one choice list filter No
A select-one choice list filter and a View By choice list or Data Type choice list No. The filter and the data view field can work independently.
A View By choice list or Data Type choice list No
A View By choice list and a Data Type choice list If the 80 percent use case is that users would use one data view component at a time, a Search button is not required.
A select-one choice list filter and a Data Type choice list If the 80 percent use case is that users would use one data view component at a time, a Search button is not required.
Multiple filters

Yes


Multiple select-one choice list filters, one View By choice list and a Data Type choice list

Data view components can operate independently; however, input or choose date filters and multiple select-one choice list filters require a Search button (see figure 6.1).

Note:
Ensure that the layout of filters and data view components is clear, particularly when a Search button applies to filters and not data view components.

Table 8.1. Recommendations on Search button usage with filters, View By choice lists and Data Type choice lists
 
9  Glossary
Return to Top

For the purposes of this guideline, the following definitions apply:

Figure 9.1. Illustrated examples of terms used in this guideline
  • Data View Component
    • A View By choice list, a Data View choice list, or subtabs.
  • Filter Component
    • A UI element used to filter data.
    • Common filter components include the select-one choice list, input or choose date, and list of values (LOV). For more information, see the Toolbar Filters Pattern in the Table Filters Pattern Set.
    • A UI element used to change the data view or data type, such as a select-one choice list or radio group
  • Page
    • A content area identified by the mandatory page header on all pages in a work area. A page can appear in a No-tabs work area or inside a Level 2 tab in a Dynamic Tabs work area.
  • Section
    • A content area identified by a subheader that divides a page into one or more sections.
    • A content area defined by a subtab.
  • Subsection
    • A content area identified by a sub-subheader that divides a section into one or more subsections.
  • Subtab: A Level 3 or Level 4 tab.
    • Each subtab contains a content section.
    • Subtabs can be used to filter data.

 
10  Related Documentation
Return to Top
  • Introduction to Work Areas
  • Work Area Entry Page Guidelines
  • Dynamic Tabs Work Area Guidelines
  • Analytic Display Guidelines
  • Table Filters Pattern Set
  •  
    About Oracle | Legal Notices | Terms of Use | Your Privacy Rights