|Work Area Entry Page Guidelines|
| 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.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
188.8.131.52 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
10 Related Documentation
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|
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.
|3 Overview Pages and Dashboards|
Here are some common questions about Overview pages and dashboards:
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.
Note: Values in the Total row can be read-only if drilling down on a large number of records could result in performance issues.
|4 Designing an Overview Page|
|4.1 Identify Roles, Goals, Success Factors, and Priorities|
Before designing a work area entry page, you must first define the scope of the work area itself .
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:
Figure 4.1 shows an example of a tasks and roles analysis created for Supply Chain Management (SCM) Logistics.
|4.2 Identify Overview Page Content for Each Role|
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:
The most common goals across applications are productivity, accuracy, and on-time performance. Each goal has corresponding content and functionality options.
|5 Overview Page Content|
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:
|5.1 Common Overview Page Content|
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:
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|
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.
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:
|5.3.1 Summaries in Subtab Labels|
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.
|5.3.2 Summaries in Tables and Tree Tables|
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.
|5.3.3 Prompt and Link Summaries|
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.
|5.3.4 Graphs and Gauges|
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.
|5.4 Grouping, Organizing, and Presenting Information|
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|
Subtabs and other components enable users to filter data, switch data, and switch views of the same data.
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|
|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.
|5.4.3 Roles and Content Display|
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.
|184.108.40.206 Overview Page Structure Options for Multiple Roles|
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.
|5.5 Drilling Down from an Overview Page to a Manage Page|
Overview page summaries commonly link to a corresponding Manage page:
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.
|6 Refreshing Content on Overview Pages|
|Two types of refresh actions are available on Overview pages: automatic and manual.
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|
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:
Table 6.1 describes the use of the page-level manual refresh action.
|7 Overview Page Naming|
|8 Designing a Manage Page for the Work Area Entry Experience|
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.
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.
For the purposes of this guideline, the following definitions apply:
|10 Related Documentation|