Dashboards are made up of small boxes that provide relevant information called dashboards regions. Dashboard regions consist of a collapsible header with a common set of actions, an optional content toolbar, and a main content area. Content is read-only and light-weight transactions implemented as dialog boxes are supported.

Dashboard regions are implemented as either Oracle Application Development Framework (ADF) taskflows or portlets (JSR-286 compliant). Portlets are required for content that must be shared across Oracle application pillars.

The following example denotes the structure of a dashboard region.

Figure 1. Structure of a dashboard region

Header

The header describes the content of the region. Dashboard regions can be expanded and collapsed by using a disclose icon next to the header. The collapsed or expanded state is kept across sessions.

Header Toolbar

The header toolbar provides the following options:

• Actions (menu)
  • Move Up
  • Move Down
• Remove (x icon)

The move options appear automatically if the enclosing page allows content reordering. Users can also rearrange content on the page through drag-and-drop functionality.

The Remove option removes the region from the page. This option can be added back using the Page Composer Catalog accesible through the Customize Current Page option under the global Preferences menu.

It is expected that the users will be allowed to move and remove dashboard regions, but teams do have the option to lock these regions.

Figure 2. Actions menu

Content Area

The content of the dashboard regions must be read-only and leverage appropriate ADF components (tables, graphs, subtabs, text, icons, and so on). Follow general guidelines and patterns when designing the content.

Lightweight transactions can be performed without navigating away from the dashboard, but these transactions are limited to actions that can be supported through simple popup dialog boxes. Heavier transactions that require a full-page navigation to a work area can be initiated from a dashboard region (through buttons, icons, links, or toolbar actions, as appropriate) based on the general patterns and guidelines of the component being used.

Scrolling and Resizing

Dashboard regions should be designed to avoid scrolling at the target resolution. However, it is fine for scrollbars to appear when needed. Users can increase or decrease the height of dashboard regions by dragging the vertical resize handle. Users can change the width of a region by moving it to a wider column through drag-and-drop functionality.

Content Toolbar

The content may include a toolbar with standard menus or tools, as needed. Components with built-in toolbars (like tables) should leverage standard menus or tools instead of providing a separate stand-alone toolbar.

Figure 3. Example with content toolbar that provides Edit settings, Refresh, and Help

The following content toolbar includes other actions in addition to Edit Settings, Refresh, and Help.

Figure 4. Sample with content toolbar with multiple actions

Navigation

Dashboard regions are launchpads to work areas; therefore, all navigation will cause a full-page refresh and in limited cases will require a new browser window.

Lightweight Transactions

Lightweight transactions can be performed without leaving the dashboard. These transactions must take place in a dialog box and follow standard dialog box guidelines.

Figure 5. A sample lightweight transaction in a popup dialog box

Dashboard regions can be implemented as either portlets or taskflows. They are both encapsulated in a ShowDetailFrame component. ShowDetailFrame provides the header, the header toolbar, and the surrounding box. The portlet or taskflow provides the main content including the content toolbar.

ShowDetailFrame is a component used to render the container of dashboard regions. This component includes a collapsible header, a header toolbar, and a boxed area. This omponent also supports drag-and-drop functionality, enabling dashboard regions to be moved around the page. The use of this component is required.

ADF taskflows provide a modular approach for defining control flow in an application. Instead of representing an application as a single large Java Server Faces (JSF) page flow, you can break the application into a collection of reusable taskflows. Each taskflow contains a portion of the application's code and logic. In the context of dashboard regions, a taskflow is used to render the main content and the content toolbar.

Portlets are web components that follow an industry standard. The portlet specification defines a portlet as a "Java-technology-based web component, managed by a portlet container that processes requests and generates dynamic content." Each portlet produces a fragment of markup to appear on a page. Similar to a taskflow, a portlet is used to render the main content and the content toolbar. Application developers use a portlet when developing content that can appear remotely (in another pillar, in WebCenter, or in a third-party portal environment).

Portlets use an iFrame that introduces scrolling in the contents of any enclosed popup. Components affected by the iFrame scrolling include choicelist LOVs, calendar pickers, dialog boxes, and any component that is implemented with a CSS layer. To avoid this limitation, follow these general recommendations:

• Use a task flow if the content appeasrs within the same pillar.
• Use a portlet only when developing content that must appear across pillars.
• When using portlets, make sure popups fit within the real state of the dashboard region at the target resolution.