Work Area Entry Page Guidelines Print this Page
Version 2.0.0.0  
 
Contents
Return to Top
  1  Introduction
  2  Types of Work Area Entry Pages
  3  Overview Pages and Dashboards
  4  Designing an Overview Page
       4.1  Identify Roles, Goals, Success Factors, and Priorities
       4.2  Identify Overview Page Content for Each Role
  5  Overview Page Content
       5.1  Common Overview Page Content
       5.2  A List of Individual Objects
       5.3  Summaries
            5.3.1  Summaries in Subtab Labels
            5.3.2  Summaries in Tables and Tree Tables
            5.3.3  Prompt and Link Summaries
            5.3.4  Graphs and Gauges
       5.4  Grouping, Organizing, and Presenting Information
            5.4.1  Filtering, Switching Data, and Changing Data Views
            5.4.2  Organizing Overview Page Content
            5.4.3  Roles and Content Display
                 5.4.3.1  Overview Page Structure Options for Multiple Roles
       5.5  Drilling Down from an Overview Page to a Manage Page
  6  Refreshing Content on Overview Pages
       6.1  Placing Manual Refresh Actions
  7  Overview Page Naming
  8  Designing a Manage Page for the Work Area Entry Experience
  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. For example, users navigate to the work area entry page when they select a work area title in the Navigator menu.

The objectives of the entry page are to inform users of the work that needs to be done in that work area and in what priority and to offer direct navigation to task flows and detailed information. In Oracle Fusion, the intent is to deliver actionable insights and information to users when they arrive in a work area, instead of requiring them to search for this information.

This guideline offers direction about how to design a useful and compelling work area entry page.

 
2  Types of Work Area Entry Pages
Return to Top

Oracle Fusion offers two types of work area entry pages: Overview and Manage. Overview is the preferred work area entry page type. Overview pages 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. Users can drill down from information on this page to initiate a task flow or view detailed information.

If actionable status and summary information are not available due to the nature of the work area, or if the only way that users can begin work is by performing a transactional search, designers can employ a Manage page as the work area entry page. A Manage page contains transactional search functionality and a section for search results. A Manage page offers a less desirable entry experience because, unlike an Overview page that delivers tasks and information to users, a Manage page requires users to search. See Designing a Manage Page for the Work Area Entry Experience.

Therefore, in most cases, the work area entry page should be an Overview page.

Figure 2.1. Example of an Overview page
 
3  Overview Pages and Dashboards
Return to Top

Here are some common questions about Overview pages and dashboards:

  • What is the difference between an Overview page and a dashboard?
  • When should I use one or the other?
  • How do Overview pages and dashboards differ? Both are summary pages from which a user can drill down; how do they differ?

Note:
Design each work area Overview page first. Then evaluate Overview page summaries to see if they can be further distilled into higher-level dashboard summaries.

Dashboard Work Area Overview Page

Dashboards display information summaries (high-level data views) that enable users to monitor different objects and data across one or more related work areas.

Dashboards are designed to fit the needs of one or more related user roles.

Overview pages provide actionable status and summary information across objects in a single work area. Users can drill down from information on this page to initiate a task flow or view detailed information.

 

Dashboards display high-level summary information pertaining to one or more related work areas for which a role is responsible. Overview pages display summary information for a single work area and can hide or show information based on the user role.
Not every role has or requires a dashboard. Every work area has an entry page, the focus of which is the work area’s specific business activity.
A dashboard is not inside any work area. An Overview page is always inside a work area and serves as its entry page.
A task flow initiated from a dashboard ultimately returns to the corresponding work area’s entry page upon conclusion of the flow. Users must manually navigate back to the dashboard as automatic return navigation is not supported. A task flow initiated from an Overview page ultimately returns to the Overview page upon conclusion of the flow.
Resources:
Dashboard Guidelines
Dashboard Region Pattern

Resources:
Introduction to Work Areas Guideline

Table 3.1. Comparison between dashboards and work area Overview pages

Figures 3.1 and 3.2 show examples of content on the warehouse manager’s dashboard and the Shipments work area Overview page. The warehouse manager primarily monitors the progress of work in the warehouse, but also utilizes related work areas to manage, schedule, and troubleshoot.

Summary information on the warehouse manager’s dashboard (see figure 3.1) is associated with multiple related work areas (Shipments, Picks, Receipts, and so on). Users can drill down on any link to view more detailed summary information on the associated Overview page (see figure 3.2). Each Overview page displays detailed summary information only for that work area.

Figure 3.1. The warehouse manager’s dashboard shows drillable and read-only high-level summary information from related work area Overview pages
In the dashboard table in figure 3.1, users click a summary number that represents 215 shipments that have not yet been completed. They navigate to the Shipments work area Overview page (see figure 3.2) and view a detailed breakdown of those 215 shipments. On this page, users can select any of the four subtabs to view the same 215 shipments by carrier, customer, order, or shipment priority.

Note: Values in the Total row can be read-only if drilling down on a large number of records could result in performance issues.

Figure 3.2. Detailed summary information on the Shipments work area Overview page
A dashboard is appropriate if any of the following statements are true or valid:
  • Users require summary information across multiple work areas.
    • In this case, the team should consider whether it makes more sense to merge the work areas rather than keeping them separate.
  • Users require summary information at a level higher than what is represented on the Overview page.
    • Would users benefit by seeing a summary of the Overview page summaries?
      For example, the dashboard in figure 3.1 displays summaries across multiple object types.
  • Users would benefit from strategic summary information that supports strategic, long-term decision-making.
    • For example, Business Intelligence content can appear in a KPI table, graphs, or a Business Intelligence summary table.
  • Users do not need to navigate seamlessly between initiating task flows and returning to summary information (drilling and automatic return navigation).
    • If this sort of navigation is required, the information should appear on an Overview page.
 
4  Designing an Overview Page
Return to Top
 
4.1  Identify Roles, Goals, Success Factors, and Priorities
Return to Top

Before designing a work area entry page, you must first define the scope of the work area itself .

  • The Navigation Model Schematic identifies primary and secondary user roles and lists the tasks that each role performs.
  • The Work Area Definition Process document offers guidance on how to define work area content for a business process. It also helps teams identify related dashboards and work areas.

In addition, review the user profiles associated with the work area and note the responsibilities, primary goals, and success factors associated with each role.

If different user roles perform substantially different tasks, you might organize this information in a matrix that associates tasks and user roles. Creating this type of reference document can help teams design an Overview page that addresses each role’s informational needs for that work area.

The next level of detail concerns primary and secondary tasks for each role (see figure 4.1). In the context of a user role:

  • Performance of a primary task is part of the user role’s core job responsibilities.
    For example,
    • The shipping agent creates outbound documentation in the Shipments work area in advance of carrier arrivals at the loading dock.
    • The warehouse manager is responsible for warehouse staffing, productivity, and troubleshooting.
  • Performance of a secondary task supports the user role’s primary responsibilities.
    For example,
    • In a smaller warehouse with fewer staff, the shipping agent may also pick items from inventory and pack them into shipments before preparing outbound documentation.
    • The warehouse manager monitors the work performed by the shipping agent and other roles associated with the work area. The warehouse manager can also perform specialized tasks and view detailed information in the work area to help with troubleshooting.

Figure 4.1 shows an example of a tasks and roles analysis created for Supply Chain Management (SCM) Logistics.

Figure 4.1. Example of the Shipments work area Key Tasks and User Roles Matrix
 
4.2  Identify Overview Page Content for Each Role
Return to Top

Understanding each role’s responsibilities, goals, success factors, and priorities within the work area helps teams identify content and functionality that can be combined into a useful Overview page.

Overview page content should inform users of work to be done and serve as entry points to task flows. Functionality should help users group and filter data to enable users to view the most relevant information in the most informative contexts.

Two levels of detail can help support users:

  • Communication of high-level business goals supports users in organizing their work at a higher level.
  • Communication of detailed information helps users prioritize their work, including addressing exceptions or troubleshooting.

The most common goals across applications are productivity, accuracy, and on-time performance. Each goal has corresponding content and functionality options.

Content:

  • A list of individual objects that require attention
    For example:
  • Summaries that help users identify and complete work to be done
    For example:
    • Pending and completed work
    • Items that require attention
    • Objects grouped by status or other attributes

Functionality:

  • Group or filter by status and other attributes
    For example:
    • Group data in subtabs to view data by status, date, attribute, and so on.
    • Use a choice list to view or filter data by status, date, attribute, and so on.

 
5  Overview Page Content
Return to Top

An Overview page holds the potential of being a powerful business tool. This page type is also a strategic differentiator for Oracle Fusion Applications. A well-designed 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.

Overview pages are read-only and not directly transactional. Users can navigate to a new task from the Overview page or initiate lightweight transactions that can be performed in a dialog box. Consequently, no final page-level actions appear on the Overview page. For more information, see the Page Actions Guidelines.

This section examines:

  • What content to include
  • How to group and organize content
  • How to filter content and change perspectives on the data


 
5.1  Common Overview Page Content
Return to Top

Local area Overview page content offers users two types of benefits: information appears directly on the page, and it enables users to drill down to view additional detail or initiate a task flow. Content display is flexible: information can appear or not, depending on the user role.

Common Overview page content types include:

  • A list of individual objects that require action or provide status information
  • A summary that shows pending and completed work, exceptions, or errors

Each type can be represented using a variety of components and can be organized, grouped, filtered, and presented in varied contexts. The following sections describe the building blocks and tools that can help deliver compelling information and functionality to users.

 
5.2  A List of Individual Objects
Return to Top

The most common content containers for lists of individual objects are Worklist tables and Applications Development Framework (ADF) tables and tree tables.

Worklist tables list human tasks that are routed to users. For more information, see the Worklist Tables Pattern Set in the Notifications and Approvals Pattern Group.

ADF tables and tree tables on Overview pages should not be directly transactional; rather, users can drill down to view additional detail, drill down to initiate a task flow, or launch a lightweight transaction in a dialog box. Figure 5.1 shows a subheader that contains lists of individual orders with recent activity.

Figure 5.1. Tables can list individual objects in separate rows. In this example, each subtab groups orders by activity type, and labels summarize the number of objects listed in each subtab
 
5.3  Summaries
Return to Top

Overview page summaries represent key searches that users would otherwise perform upon entering the work area. In Oracle Fusion, these summaries proactively deliver information to users.

Overview summaries can appear in a variety of components and represent a variety of object types, statuses, and issues. Common components that display summaries include:

  • Subtab labels
  • Tables and tree tables
  • Prompt and link pairs
  • Graphs and gauges
 
5.3.1  Summaries in Subtab Labels
Return to Top

Subtab label text may include a summary of the total number of records listed in that subtab. This label offers users a quick Overview of the work status before they select any individual subtab.

Figure 5.2. Subtab label text can include a summary of the number of records listed in each subtab
Figure 5.3. Example of a subtab containing a table with no data to display
 
5.3.2  Summaries in Tables and Tree Tables
Return to Top

Summary information can appear inside a table in the form of numbers, text, and icons. Each element links to the corresponding Manage page that lists the individual objects.

In figure 5.4, clicking a summary number — in this case, the number 3 — links users to the Manage Shipments page, where three shipments that are Medium priority and are Ready to Ship will appear in the search results table. For more information, see Drilling Down from an Overview Page to a Manage Page.

Figure 5.4. Example of an Overview page table that has numerical summary links
 
5.3.3  Prompt and Link Summaries
Return to Top

Prompt and link pairs can be employed to summarize information on an Overview page. Prompt and link pairs enable users to drill down to view detailed information or initiate a task flow.

Figure 5.5. Example of summary data in a form layout
 
5.3.4  Graphs and Gauges
Return to Top

Summary information in graphs and gauges can facilitate users’ rapid understanding of data and their relationships. Drillable graphs enable users to navigate to detailed information or initiate a task flow. For more information, see the Analytic Display Guidelines.

Figure 5.6. Example of a graph on an Overview page
Figure 5.7. Highlighting should always be enabled for drillable graphs. The pie graph shown here is not highlighted (at left) and highlighted when users hover over the graph (at right)
 
5.4  Grouping, Organizing, and Presenting Information
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, changing the data view, changing the data type, and organizing content.

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

Subtabs and other components enable users to filter data, switch data, and switch views of the same data.

  • 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.

For more information on issues pertaining to filtering, switching data, and changing data views on Overview pages, see the Work Area Overview Page Content Display Guidelines.

 
5.4.2  Organizing Overview Page Content
Return to Top
If a work area supports more than one primary business object or if a work area Overview page contains a great deal of content, you can effectively organize the information pertaining to each object type or business activity on a separate subtab.

Figure 5.8. Subtabs help organize content according to object type or business activity
 
5.4.3  Roles and Content Display
Return to Top

One or more user roles can use a single work area. Overview page content and components can appear or not, depending on the user roles.

Figures 5.9 and 5.10 illustrate examples of the Shipments Overview page. In the shipping agent’s view, graphs are hidden; in the warehouse manager’s view, graphs appear. The pages are otherwise identical for each user role.

Figure 5.9. Example of the shipping agent’s (a hands-on worker) Overview page
Figure 5.10. Example of the warehouse manager’s Overview page. Content can appear or not, depending on the user role
 
5.4.3.1  Overview Page Structure Options for Multiple Roles
Return to Top

Teams can leverage components such as subtabs or subheaders to support a flexible, modular design. An effective design option that supports multiple user roles is to group the content into subtabs based on either object type or business activity.

In figure 5.11, subtabs support multiple user roles on the Supplier Portal Overview page. In this work area, some users have single roles, and others have multiple roles. Subtabs and subheaders can appear or not, depending on the user role and its requirements and permissions.

Figure 5.11. Subtabs can appear or not, depending on the user role
 
5.5  Drilling Down from an Overview Page to a Manage Page
Return to Top

Overview page summaries commonly link to a corresponding Manage page:

  • The Search subheader is expanded by default; query fields display search criteria associated with the selected summary number on the Overview page (see figure 5.13).
  • The number of records in the Search Results table should match the selected summary number on the Overview page unless changes have since been made in the database.

See the Transactional Search and Results Pattern Group and figure 11.1 in Introduction to Work Areas for additional details.

Figures 5.12 and 5.13 illustrate an example of drilling down from a numerical summary link on the Shipments Overview page to the Manage Shipments page.

  • In figure 5.12, users can initiate a task flow by clicking a summary link on the Overview page and navigating to the associated Manage page (see figure 5.13).
  • In figure 5.13, the number of records in the Manage page’s Search Results table matches the selected summary number on the Overview page unless changes have since been made in the database.
Figure 5.12. Users can initiate a task flow by clicking a textual, numerical, or graphical summary link on the Overview page
Figure 5.13. When drilling from an Overview page summary to a Manage page, the Search or Advanced Search subheader is expanded by default; query fields display search criteria associated with the selected summary number on the Overview page
 
6   Refreshing Content on Overview Pages
Return to Top
Two types of refresh actions are available on Overview pages: automatic and manual.
  • Automatic refresh causes all content on the Overview page to update each time that users return to the Overview page after concluding a task.
  • Manual refresh requires a specific user interaction to refresh content.

Automatic refresh is optional and is supported only in No-tabs work areas. Manual refresh is supported in No-tabs and Dynamic Tabs work areas. All Overview pages should offer manual refresh to enable users to see updated content, regardless of whether automatic refresh is employed.

 
6.1  Placing Manual Refresh Actions
Return to Top

Teams may employ manual refresh actions at page, section, or component levels. Teams must balance the placement of one or more manual refresh actions with performance-related considerations. An additional placement consideration is the importance of maintaining consistency and accuracy across related data on different parts of the page. For example, if a table shows the number of shipments due today and a graph in a different section shows related data, both sections should refresh simultaneously to communicate the same, consistent information.

Two manual refresh strategies are available:

  • Page-level only
    • One manual refresh button appears in the header toolbar section of the page header region.
      No other level of manual refresh is available on the page.
    • If page-level refresh would result in performance concerns, consider component-level refresh.
  • Component-level only
    • Component-level refresh can occur on content sections, subtabs, tables, tree tables, and trees. Users can refresh each component independently of other components on the page.
    • If the same or related data appears in multiple components on the page and refreshing one component could result in conflicting data across multiple components, employ page-level manual refresh.

Table 6.1 describes the use of the page-level manual refresh action.

Scope Criteria Placement and Format

A page

  • Employed when data synchronization is required across multiple sections on a page

  • Recommended for pages on which the resulting performance remains acceptable
A Refresh text button in the header toolbar section of the page header region (see figure 6.1) or an action inside the page-level Actions menu

Table 6.1. Page-level manual refresh actions can be used at one or more levels on a page
 

Figure 6.1. Example of a page-level Refresh text button. The corresponding task stamp does not appear until users click the Refresh button
Table 6.2 describes components that support component-level manual refresh.
 
Scope Criteria Placement and Format

A content section

May be employed when data synchronization is not required across multiple sections on a page.

A Refresh text button or icon button:

  • In the header toolbar of a subheader or sub-subheader (see figure 6.2)
  • In the content section of a subheader or sub-subheader
A subtab May be employed when data synchronization is not required across multiple subtabs in a tab bar or sections on a page. A Refresh text button inside the content section of a subtab (see figure 6.3)
An individual component May be employed when data synchronization is not required across content in multiple:
  • Sections
  • Subtabs
  • Components
An icon button and action inside the View menu on the toolbar of an individual component such as a table, tree table or tree (see figure 6.4)

Table 6.2. Manual refresh actions can occur on content sections, subtabs, tables, tree tables, and trees

Figure 6.2. The Refresh icon button or text button can be used at the section-level
Figure 6.3. Example of the Refresh text button in a subtab. The corresponding task stamp appears after users click the Refresh button for the first time and updates each time users click Refresh in that session
Figure 6.4. Example of component-level refresh on a table toolbar
 
7  Overview Page Naming
Return to Top
  • The page header is Overview in each tab model.
  • In the Dynamic Tabs work area model, the tab label is Overview.
Figure 7.1. Detail of an Overview page in a No-tabs work area
Figure 7.2. Detail of an Overview tab with subtabs in a Dynamic Tabs work area
 
8  Designing a Manage Page for the Work Area Entry Experience
Return to Top

Using a Manage page is considered a less desirable entry experience because, unlike the Overview page that delivers tasks and information to users, a Manage page requires users to search. However, if the work area does not contain business intelligence, a Worklist, or analytics, or if users must always begin with a search, a Manage page can be employed in lieu of the Overview page.

For example, the SCM Logistics Inventory work area enables users to query the amounts, values, and locations of available items. Users navigate to this work area to use it as a tool in support of shipping, receiving, and other related tasks that are performed in related work areas. Therefore, an Overview page would not be useful here because every task flow performed within this work area must begin with a query and there is no meaningful or actionable data to list or summarize.

Figure 8.1. Example of a work area entry Manage page
The design of a Manage page is the same whether or not it is a work area entry page. However, if a Manage page is employed as the work area entry page, the corresponding task name should not appear in the Tasks pane.

The page header and tab label would be Manage <Object Type> or Manage <Business Process> (for example, Manage Intrastat Transactions or Manage Item Quantities).

A potentially valuable option is to autoexecute a saved search. Upon arrival, the Manage page can display the criteria and results of an autoexecuted saved search. This is most useful for cases in which a valuable saved search can be defined for the Manage page. For example, the Manage Shipments page could have an autoexecuted search to show shipments that are due today.

If a work area has more than one Manage page and does not have an Overview page, the product team should employ the most important or most often used Manage page as the work area entry page.

For more information on Manage pages, see the Transactional Search and Results Pattern Group.

 
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
 
About Oracle | Legal Notices | Terms of Use | Your Privacy Rights