A dashboard is a collection of information summaries (high-level data views) that enable users to monitor different objects and data within a subdomain or functional area of interest. Typically dashboards are designed with a particular user role or function in mind, but may also be designed to fit the needs of a couple of related roles.

• Fusion Home
• Dashboard Types
• Dashboards vs. Work Areas
• Portlets vs. Taskflows
• Navigation
• Contextual Transactions
• End User Personalization
• Admin Customizations
• Frequently Asked Questions
• Dashboard Technology Resources

The Fusion suite has a home page which we will refer to as the Fusion Home. The Fusion Home Page is a collection of tabs based on the roles assigned to a user. Tabs can hold either home based dashboards, BI dashboards (built with OBIEE) or groupspaces.

The first tab in the Fusion Home is always the Welcome dashboard. It has content applicable to all users regardless of role(s). Other dashboards are always designed for a specific role or roles. They provide launching pads into relevant workareas and a way to monitor the status of the underlying transactions - per business domain (Sales, Finance, CRM,  Projects, Supply Chain, Manufacturing, etc) - or corporate function (Employee, Manager, etc).

Figure 1. Fusion Home - Welcome Dashboard

For example, a General Accounting Manager will see the following tabs: Welcome, General Accounting and Manager Resources. Not all roles have a dashboard assigned to them; therefore, some users will only see the Welcome tab. If a user happens to have been assigned a large number of tabs, all of them will be available and the standard ADF tab overflow mechanism will be used.

A single Spaces tab will be provided that gives access to the Webcenter Spaces available to the user. By default, this tab will contain the list of available Spaces. Opening a Space, will redraw the contents of this tab. Each Space is opened as a level 2 dynamic tab under the Space tab.

BI Dashboards can be embedded under a Fusion Home tab. This type of tab is created using the OBIEE tool and embedded in Home tab by development. This type of dashboards are also role based.

Note: V2 features will include the ability to open/close tabs/dashboards, ability to reorder tabs, and the ability for end users to create new tabs.

To an end user, a dashboard is made up of little boxes that do useful things which we will refer to as dashboards regions. They provide an overview over a particular domain and act as launch points to the applications that make up the suite.

There are different ways to categorize dashboards:

• From a navigation perspective, they can be primary or secondary.
  • Primary dashboards appear as tabs in the Fusion Home
  • Secondary dashboards appear in the Navigator menu (and not in the Fusion Home as tabs)
• From a technical perspective, they can be:
  • Transaction dashboards: core to the application. Built using Fusion UI Shell and ADF Portlet components.
  • BI (Business Intelligence) dashboards: OBIEE dashboards built using the OBIEE Answers tool.
• From a content perspective, they can be operational or strategic.
  • The difference between these is in the content and not in the user interface.

End users do not classify their dashboards. However, we need to classify them internally so we can talk about them. This will be based on a combination of technical and navigational perspectives as follows:

• Home Dashboards
  • Primary dashboards that appear as a tab in home page. These dashboards can also be linked to from the Navigator.
• Transaction Dashboards - accessible only from the Navigator menu, do not appear as a tab in the Fusion Home
• BI Dashboards
  • Primary BI Dashboards - appear as a tab in home page
  • Secondary BI Dashboards - accessible from reports panel. Launched in new window in OBIEE.

Yes, it can be confusing. But it's vital for each concept to be considered separately, even if some overlap in purpose exists. For roles with multiple domain responsibilities with many tasks to monitor and to complete, an extensible model is necessary for intuitive navigation and quick access to tasks. That said, sometimes the lines get blurry. The below description is the result of four product teams wrestling with the blurry lines, and finding some clarity.

Dashboards are where a user monitors information in order to prioritize which transactions to complete first.

Work Areas are where a user completes transactions.

Dashboards are for user roles with special needs. Either these roles need different views into a work area than other user roles (in particular additional analytic information) or they require a consolidated view and access across multiple work areas. Both criteria frequently apply to managers.

What confuses some teams is the fact that some dashboards offer a few in-place lightweight transactions, and some work areas offer a small degree of monitoring in their Overview pages. The main difference is that dashboards provide alternate views and allow users to monitor summary information coming from these work areas. If only one work area needs to be accessed and secondary users do not need different information, the work area overview (entry) page with a focused worklist will be sufficient and a full dashboard will not be required.

So the difference between work areas and dashboards is not so much in their content - though dashboards tend to be more analytic and pull information from different workareas - but in their purpose. Dashboards only make sense if the work area entry page does not meet the needs of all the user roles that use the work area.

Dashboard regions can be implemenet as either portlets or taskflows. Portlets use an iFrame that introduces scrolling in the contents of any enclosed popup. This includes: choicelist LOVs, calendar picker, dialogs and any component that is implemented with a CSS layer. To avoid this limitation, follow these general recommendations:

• Taskflow: dashboard regions from the same pillar.
• Portlet: dashboard region from across pillars.
  • If a popup is needed it must fit within the real state of the dashboard region at the target resolution.

The UI is the same regardless of implementation. For more details, refer to the Dashboard Regions Design Pattern.

Note: the use of taskflow vs. portlet is a decision that should involve development. There are a couple more options that should only be used when strictly necessary.

Navigation to a dashboard

• Fusion Home
  Users get to the Fusion Home after they log in, through entries in the Navigator and when they select the Home link in the global region.
• Transaction Dashboards appear only in the Navigator menu as workareas do.

Navigation from a dashboard is always to a different dashboard or workarea, causing a full screen refresh. There are few approved exceptions when a new secondary browser window is used. Current allowed secondary browser window use cases are: OBIEE, the BPM Worklist application, and individual workflow tasks and notifications.

<image here with home + others + navigator menu>

A contextual transaction is a lightweight action that can be performed in a dialog without leaving the dashboard. The action performed in the dialog may require a refresh of the calling region on submit.

The trigger for the action may be a button, a menu, or an icon. If the action requires a full page interface, the user will be taken to the relevant workarea page to complete the transaction navigating away from the current dashboard.

The following personalization features are supported:

• Collapse/Expand dashboard regions.
• Rearrange content through drag and drop.
• Remove content through the remove (x) icon in dashboard regions, if enabled.
• Add content from the content catalog in Composer.
• Change the layout of the page in Composer.
• Change the default settings of a dashboard region through custom personalization UI built into the region.

All of these personalizations must persist across sessions.

Collapse/Expand dashboard regions

Dashboard regions are collapsible through the Disclose icon in the header.

Re-order dashboard regions through drag and drop

Users can reorganize the content in the page by grabbing the header section of a dashboard region. Valid drop targets are highlighted as the user drags the region around the page.

Remove content

A dashboard region can be removed from the page through the Remove icon in the header toolbar.

Add content

Content can be added to the page via the Catalog in Composer. Users can open this tool through the "Edit Page" icon at the top of the dashboard or through the Edit Current Page option under the Personalization menu in the Global Region.

Every dashboard will have a corresponding catalog populated with both taskflows (for content from the same pillar) and portlets (for content from across pillars).

Change Layout

Page Composer supports 12 layout templates. When a template type is changed, content will be remapped according to a simple heuristic, then the user will manually drag + drop to complete the process. The diagram below shows the available templates. The numbers show the content mapping through template change.  If a change is made to a template containing fewer numbers, the "orphaned" content will be placed in area 1.

Users with Admin priviledges can make UI changes that will affect a targeted group of users. Tthe MDS Customization Framework will be leveraged for this purpose.

This funtionality is available through the global Administrator menu under "Customize <page name> Screens" option. This will open up the page in Page Composer where they will be able to perform all of the actions described under personalization above.

1. How does the Fusion Home Page get built?

This page is dynamically assembled based on user role. Each dashboard tab is implemented by the relevant development team and assigned to one or more roles. At run time, the appropriate collection is assembled for each user based on his or her roles.

2. Do all product teams need to deliver dashboards as part of Fusion v1?

As a result of the Navigation Model process, teams will identify and agree with the UX team which dashboards are needed. Not every single role and flow may require a dashboard in a one to one relation, but dashboards are highly recommended because they are easy for users and provide consistent entry points for key flows.

3. How do we handle cross pillar dashboards? (Line Manager, Employee)

All dashboards are identified as a result of the BPM Decomposition exercise. Even cases of dashboards that may imply cross pillar content should come as a result of this process and must be registered as deliverables for the Decomposition exercise.

If a product family decides that they need to build a dashboard with cross pillar content, the PM designated by the Dev. VP needs to take care of the design requirements to deploy this kind of dashboard and work out the cross dependencies. It is the PM and product family decision and responsibility to write FDDs for this type of case.

4. Are dashboards mandatory? Can we have a landing page without any dashboard information?

All users will have a landing Home Page with at least the Welcome tab. The decision of having additional role-based dashboards and the scope of them depends on the analysis each team does as a result of the Navigation Model Process.

5. Related to dashboards, how are object groups defined?

Product teams will work with the UX POC and refer to the Functional Analysis Process located at: http://fusiongps.us.oracle.com/process/content/analysis/index.htm

6. Related to dashboards, is there a review cycle and when should that review cycle take place?

Dashboards are first reviewed when the related flow designs are reviewed. You can follow-up with your UX POC for specific details for your particular flows.

7. Are all level 4 tasks represented on dashboards also represented in work areas?

Usually, but not always. Some examples of tasks which might only be included on a dashboard are: (1) viewing summaries to prioritize your workday based on what is most pressing, (2) exploring the possible causes of an alert that has been triggered, (3) seeing information side by side in order to determine patterns, etc.

8. What is OBIEE?

Oracle Business Intelligence Enterprise Edition (OBIEE) is the business intelligence solution that evolved from the former Siebel Business Answers. The official name going forward for Apps releases from OBIEE is "Dashboards for Fusion Intelligence". These are a set of dashboards that are complimentary to the business process, that answer fundamental questions about the health of the business - financial, operational, or comparative in nature. Characteristics of Dashboards for Fusion Intelligence:

• Dimensional analysis on a conformed dimension, ERP-wide data model
  
• Focused on executive or managerial role
  
• Content is mainly BI, including KPIs, metrics, Alerts, guided drill-down and cause/effect analysis
  
• To be built by the central BI team
  

9. What is the difference between BI Dashboards and Embedded Analytics?

In many cases, transaction dashboards and task flows within eBusiness Suite will require analytic content, but not necessarily the full package of a BI Dashboard content as offered in the Oracle Business Intelligence Enterprise Edition (being built by the central BI team).

Business Intelligence content (full reports, graphs, gauges, tables, watchlists, etc) that originates from an OBIEE product can technically be displayed in an EBS dashboard (using ADF data controls to point at a BST/MV schema). But in the majority of cases, the use case requirement for this type of content can be fulfilled by an ADF component (sourced directly from OLTP, with no dependency on OBIEE content). This is consistent with the Embedded Analytic approach, and offers developers a common JDev-based approach regardless of data source or target visualization (through data controls and UI controls). User Experience guidelines for analytic ADF components are located above, on this page.

11. How are BI Dashboards (Dashboards for Fusion Intelligence) going to be designed?

OBIEE is going to be exclusively used for BI Dashboards and BI Reports, and are designed and scoped by the central BI Core team. The product families or UX designers do not need / are not meant to use the OBIEE tool for typical pages. Only the BI Core PMs and developers will use the tool for prototyping and then delivering the pre-defined BI Dashboards to customers.

To an end user, a dashboard is made up of little boxes that do useful things. To Oracle product teams, these little boxes are defined as either a region or a portlet.

A taskflow (sometimes called a bounded task flow) is a re-usable UI that may be tied to some models. Pages are generally composed of regions. Regions are ADF components that have some UI, model, and business logic. Regions can also be shared ADF components that are developed to be re-usable on multiple pages.

A portlet refers to a third-party component or a shared region embedded within the page. The only reason an app developer would use a portlet is if they know they're developing reusable content that needs to be capable of being displayed remotely (in another pillar, in Webcenter Spaces, or a third party portal environment).

For more technology resources, check here:

• Dashboard Region Design Pattern
• Information Display Pattern Set
• RCUX/ADF Data Visualization (Graph)
• RCUX/ADF Data Visualization (Gauge)
• Embedded Analytics Concepts in Fusion