Analytic Display Guidelines

Print this Page
Return to Top
Return to Top

In the Oracle Fusion E-Business Suite, analytics appear in dashboards, work areas (embedded analytics), and in advanced analytic flows. They usually appear in the form of a graph or gauge, but also can be presented as tables, lists, or fields. Designers and developers placing analytics on the page must make a number of decisions including graph size, titles, styles, and so on. This document provides tips and specific recommendations to help you make the best choices.

Before You Begin
Return to Top
Before you determine the precise characteristics of your analytic, you should make sure that you are presenting your data in the most appropriate form. For example, do you need to use a table or a graph? If a graph, what kind should you use?

The Oracle Fusion Guidelines, Patterns, and Standards (GPS) site offers several resources to help you with this and other questions:

Graph Sizes
Return to Top

The size of a graph that users should use is one of the most common usability issues. If the graph is too small, users cannot easily discern the information being presented or may misunderstand what they see. If the graph is too large (a common mistake), you waste valuable screen real estate, and users may have a harder time grasping the overall pattern because they have to move their eyes back and forth and integrate what they see instead of taking everything in at a glance. The graph will either push other content below the bottom of the screen so that users must scroll to see it or may not even notice it, or the graph itself extends below the fold.

Whether a graph is too large or too small depends to a great extent on its content. A bar chart with three bars is easy for users to understand even when the graph small; a chart with a hundred bars is not. If the amount of content is not known at design time, plan for the 80 percent worst case. Do not use small graphs in situations where the amount of content is unpredictable.

For reference purposes, you can think of the local area of an Oracle Fusion page as consisting of either two or three columns. The width of a graph depends on its placement on the page: the graph can span all columns of the local area, span one of two columns (using 50 percent of the area), span one of three columns (using 33 percent of the area), or squeeze into the regional or contextual areas on either side. Because the size of a graph component includes the title, legend, labels, and other elements, the height of the graph will vary depending on how many of these elements are present. The following table shows recommended width and typical height for all four possible placements.

Placement Recommended Settings** Typical Size**

Full Span

Width 100%
Height 250
700 x 250*
Half Span Width 100%
Height 250
350 x 250*
One Third Span Width 100%
Height 250
230 X 250*
Side Area Width 100%
Height 250
140 x 250*

*For the typical height, always inspect the runtime presentation and adjust the height as needed.
**All sizes are specified in pixels.

In general, you should set the width of a graph to 100 percent of its enclosing container. Then, if users with a large monitor widen their browser windows, the graph can automatically grow and shift legend placement to take advantage of the extra width. But you should also set a minimum and maximum width to make sure that the graph remains readable under all conditions using the typical size widths from the preceding table. (You should set the height of a graph in pixels. Never set the height to 100 percent.)

For example, if your graph is designed to fit into a compact single-column region, you should probably not let it shrink any further, so use 230 pixels as a minimum width. With more complex or data-rich graphs, you may need a larger minimum width, possibly 350 pixels (a typical half-page span). Be aware that all your graphs may widen if users collapse the contextual area. Simple graphs look odd when stretched too far, so consider 350 or 700 pixels as good maximum values. For data-rich graphs that might benefit from large monitors, you may want to omit the maximum value altogether.

JDeveloper Tip: To set relative widths, you must first change the dynamicResize value (located in the Behavior subcategory in the Jdev panel) from the default FIXED_SIZE to DYNAMIC_SIZE. In the Style subcategory, enter the following string into the inlineStyle field: “width:100%; min-width:230px; max-width:700px;” (replacing 230 and 700 with the desired minimum and maximum values). You should then test these settings by running the page and stretching the browser window back and forth to make sure the graph remains readable at all widths.

When setting the height of a graph, it is important that you inspect it at runtime using actual labels, titles, and data and adjust the height if the graph appears cramped or contains excess white space. Various factors can increase the space required to present the nongraphical elements of the graph, and because the height is fixed, the component compensates by shrinking the graphical portion, making bar charts unreadable or reducing a pie chart to a very small size.

The following example shows two vertical bar graphs with identical dimensions. Because the second example includes a title, subtitle, and legend title, the area devoted to the actual graph is smaller. Also notice that in the second example, the final series in the legend was truncated due to lack of space, rendering the graph unusable. You must increase the height of the second graph to correct this problem.

Graph Sizes
Figure 1. Two vertical bar graphs with identical dimensions

When inspecting graphs, use actual or realistically long labels and titles. If you set the height too small, the graph may clip words (for example, “North America” might become “Nort…”) or change the orientation of x-axis labels to vertical. Test the graph using labels 30 percent longer than the English label to ensure that the graph will withstand translation to another language.

The following example shows what happens when long x-axis labels force a vertical orientation. Vertical labels are harder to read and consume more vertical space, so avoid them whenever possible.

Figure 2. Resulting bar graph when the long x-axis forces vertical orientation

Note: Small graphs currently default to two-column legends, which cause most values to be severely truncated.

Dealing with Small Graphs
Figure 3. Two-column legends result in truncated values

Follow these tips for squeezing graphs into the narrow Oracle Fusion side areas:

  • Avoid pie graphs. Use bars to express percentages instead.
  • If you must use pie graphs, set the slice to no labels to suppress pie graph labels and rely on a legend instead. Test the graph using realistic label names, because the legend may severely truncate the labels.
  • Use vertical rather than horizontal bar charts.
  • Use a graph subtitle or read-only parameter instead of y-axis titles to display units of measure.
  • Use shorter text strings.
  • Move noncritical text outside of the graph area.
  • Avoid complex graph types.
  • Stack several simple, narrow graphs instead of one complex, wide one. This technique works best when all stacked graphs share the same x-axis.
  • Consider spark charts

Dealing with Wide or Tall Graphs

Graphs are sometimes asked to convey data across a long sweep of time (for example, weekly data over several years) or large category sets (for example, all 50 US states). In such situations, avoid create a graph that is either especially tall or wide, because these dimensions require users to scroll to see the entire graph.

The chief disadvantage of scrolling is that at any given moment, part of the data is out of view. This situation may be acceptable if the hidden data is not necessary to convey a larger understanding. For example, in a bar graph that shows population by state, each data point is independent, and users who scroll down to see data about Wyoming may not really need to see data about California on the screen at the same time. Sorting bars by value (height) addresses this issue somewhat. In general, sorting bars by value positions categories with similar values near each other makes it easier for users to identify groups of similar categories.

Note: This process is somewhat difficult using the Application Development Framework (ADF) graph component. You must first programmatically sort by category to achieve sort bars by value.

However, users must be able to grasp the bigger picture formed by an overall pattern. Having part of the pattern hidden can lead to frustration or miscommunication. For example, when studying the performance of a stock, users find it difficult to grasp long-term trends if thousands of daily numbers are plotted on a very wide graph, only part of which can be seen at any one time. In this situation, you should instead use a parameter setting to adjust the graph to different time scales (for example, daily, weekly, monthly, quarterly, yearly, 5-year, and 10-year). Then users can quickly select the time scale that they want, and the graph will successfully convey the trend at that time scale even though the graph itself can remain fairly small. You can apply this binning technique to any quantitative scale, not just time.

If you do need to create a graph with many datapoints, you can make graphs either tall or wide, but in general, vertical scrolling is less disruptive on a web page than horizontal scrolling, and horizontal labels are easier to read than rotated or vertical labels, so use tall graphs when listing category values (for example, the 50 states). Embedding meter gauges in tables (stamping) provides a similar effect and can be quite usable.

By convention, though, you should always represent time along the x-axis, so time-based graphs with many data points are often wide. Extremely wide graphs disrupt the layout of an Oracle Fusion Applications page, so you should not set the width of a graph to more than 700 pixels. Remember that you can use both horizontal and vertical scrolling within the graph component itself. This technique enables users to scroll across data even as the graph itself remains fixed at a size that fits within the Oracle Fusion Applications page. You can use horizontal scrolling for wide line or vertical bar graphs or use vertical scrolling for tall horizontal bar graphs, but you should not by default use both horizontal and vertical scrolling at the same time.

Figure 4. Horizontal scrolling within a graph

When sizing the graph itself, select a width that minimizes the amount of scrolling required while making the individual datapoints and labels easily discernible. You may need to experiment to find the right balance.

Elements and Styles
Return to Top


The title should clearly indicate the metric that appears, including the metric constraints (such as a specific region or time period). A vague or incomplete title makes the meaning of the analytic unclear or causes users to misinterpret the data being presented.

You can use a header or tab as a title if the analytic appears in close proximity to the header or tab and if there is only one analytic under that header or tab. If users may be unsure about whether or not the header or tab title also applies to the analytic, then you should provide the analytic with its own header to convey its name.

Note: To provide a consistent look and feel consistency across components, use the ADF region header instead of the Graph Title property to display the name of a graph.

Figure 5. Using a header or tab as a title when the analytic appears in close proximity to the header or tab

In the previous example (figure 5), you might be tempted to omit the title and rely on the Subledger Accounting tab to convey the essential meaning of the graph. However, because the various container titles are complex, with the header Pending Activity competing with three tab titles and the intervening toolbar adding more confusion between the graph and the tab title, it's helpful to provide the graph with its own title.

Another important use of titles is to aid in signaling a change to an embedded analytic. Often embedded analytics are tied to the selection of rows in a local area table so that whenever users select a particular row, a related graph is updated to display data relevant to the object described in that row (for example, selecting a subsidiary company displays subledger account value for that subsidiary in the contextual area). If the only thing that changes is the actual data (often a subtle change), users may not be sure whether or not the graph has been updated yet or may become confused about which object the data pertains to. For this reason you should change the title or read-only parameter whenever updating a graph in this manner (for example, you could change the title from "Vision Enterprises, Japan" to "Vision Laboratories"). In small graphs, you may need to provide an abbreviated text string for titles or read-only parameter rather than the full name that appears in the table row.


You should position a graph legend either below or to the right side of the graph, depending on the size of your graph and the layout of your page. In narrow spaces such as the contextual area, the legend should go below the graph. If you are placing a graph in the local area in a spot with unused horizontal space (for example, in a one- or two-column-wide graph in a three-column-wide tab), you should position the legend to the right side of the graph if this does not cause users to scroll horizontally.

You can orient legends either vertically in one or more columns or horizontally in a single row. The horizontal orientation works only for wide, two- or three-column graphs when there is enough room to fit the longest of labels. Remember that when legend text is translated, item names may become 30 percent longer.

Figure 6. Examples showing both possible legend placements

Because the graph contains only two items, the horizontal bottom placement is probably the better location for the legend, but you could place the legend in either location. Notice that placing the legend below makes the graph itself wider. Placing it to the right side makes the graph narrower and reduces the space available for x-axis labels. However, this placement increases the relative height of the graph and makes it easier for users to tell the y-axis values of data points apart.

Whenever possible, you should arrange the legend to mirror the elements that it refers to. For example, if you have a horizontal bar chart arranged in groups of red, blue, and green bars running from top to bottom, a vertical legend with red, blue, and green references arranged in the same way is easy for users to read. Similarly, a chart with vertical red, blue, and green bars should, if space permits, show a horizontal legend placed just below the chart.

More Info Links

You can often associate a graph with one or more links to more detailed or other related reports, which can open in separate windows. Research shows that users may not notice these links unless they are clearly called out. Therefore, you should place links start-aligned under a More Information heading. As with legends, you can place these links below the graph and start-aligned. Alternatively, if you have free horizontal space and doing so would not cause users to scroll horizontally, you can place the graph to the right side of and top-aligned with the graph. (See figure 5 in the Titles section.


Footnotes are usually used to provide information about the source of the data that appears in a graph. Footnotes are important for graphs that appear in official reports but are not generally needed or recommended for graphs that appear in online dashboards and embedded analytics. If you do use a footnote, position it in the default location: right-aligned below the graph. Be aware that a footnote is part of the graph and falls within its overall dimensions, so adding a footnote without increasing the height causes other elements in the graph to shrink.

Other Elements

The various components offer many additional options that can enhance an analytic. These options can be helpful when used correctly, but you should not overuse them. In small graphs, you should reduce visual clutter as much as possible. So in general, you should strive for simplicity.

A partial list of other available graph options worth considering in some situations includes:

  • Annotations
  • Alerts
  • Gridlines
  • Axis labels and check marks
  • Dynamic reference lines and areas
  • Interactive line graphs
  • Data labels

For more information about these options, see the Graph specifications.

Styles and Colors

In general, you should not set colors, fonts, or sizes for individual elements of a graph or a table. These elements are controlled by the defined Oracle Fusion style, which in turn is controlled by the Oracle Fusion skin mechanism. Leave the style tag in the JDeveloper blank so that the skinning engine can remain in control of graph and table styles. However, some cases call for special treatment:

  • Oracle Fusion in general allows several exceptions to customizing default Oracle Fusion style elements, some of which are applicable to analytics, such as color formatting of positive and negative numbers.
  • Sometimes you should manually set a color palette for a graph series to avoid the use of different colors for the same categories in multiple graphs. For more information, see the Multiple Graph Guidelines.
  • You should also manually set the color palette for a graph series when you need to highlight data based on predefined conditions (such as conditional formatting). For example, set the color palatte to show in red the months when actual expenses exceeded the budget.
Note: If you are applying conditional formats to tables, the information should also be repeated in a different form for accessibility. For example, use a status icon to indicate a highlighted cell, or use an adjacent table showing only highlighted records. You could follow a pivot table showing all expenses with a table titled Exceptions that shows only expenses that exceeded the budget.

Symbols and Abbreviations

All Oracle Fusion abbreviation guidelines are fully applicable to analytics. For abbreviations in graph axis labels and legends, follow the same guidelines as for table column headers:

  1. Use the full term when space allows (this includes the 30 percent expansion rule for other languages). Use only approved abbreviations when space is a concern.
  2. For column headers, graph axis labels, and graph legends, the percent sign or an abbreviation of units of measure (such as USD for US dollars) can be dynamically appended to column headers, within parentheses. For example: Cost (<currency>) or Variance (%).
  3. Access the definitions of approved abbreviations through help.

Note regarding scale abbreviations such as K, M, and B in graphs: The ADF graph component automatically selects the most appropriate scale for the graph based on the volume of underlying data and formats the associated tick labels using abbreviations, such as K or M or the localized equivalents (for example, 50M instead of 50,000,000).

Related Documentation

Here are the sage guidelines for the term percentage and the % symbol in analytics interfaces:

Usage Examples

Metric Names
Do not use abbreviations.
Use the word percentage rather than percent.
Example: Fulfillment Lines Exceptions as Percentage of All Fulfillment Lines

Nonbillable Cost as Percentage of Total Cost
Nonbillable Cost as % of Total Cost

Region Titles
Do not use abbreviations.
Example: Fulfillment Lines Exceptions as a Percentage of All Fulfillment Lines

Graph Titles
Do not use abbreviations.
Example: Fulfillment Lines Exceptions as a Percentage of All Fulfillment Lines

Y-Axis Labels
(Optional) Append the % symbol at the end in parentheses.
Example: Fulfillment Lines Exceptions (%)

X-Axis Labels
(Optional) Append the % symbol at the end in parentheses.
Example: Fulfillment Lines Exceptions (%)

See previous example.

Tick Mark Labels
Do not use the % symbol.


Pie Chart Callouts
Use the % symbol if the unit of measure of the callouts is not clear or if multiple units of measure are shown.

Do not use the % symbol.


Table Titles
Do not use abbreviations.
Example: Fulfillment Lines Exceptions as Percent of All Fulfillment Lines

Table Column and Row Headers
Append the % symbol at the end in parentheses.
Example: Fulfillment Lines Exceptions (%)





Table Cells
Do not use the % symbol.

See the previous example.

Field Labels
Do not use abbreviations.

No analytics use cases.

Field Values
Do not use abbreviations.

No analytics use cases.

Return to Top

Enabling users to interact with a graph or table control in a dashboard or embedded analytic is often useful. The various graph or table components offer a rich array of features to support user interaction. Interaction can also be accomplished by using other elements on the page such as tool bars and region-level action menus.

Note: These guidelines focus primarily on typical end-user interactions. Applications that enable users to redesign or create graphs from scratch require a much richer set of user controls than those described here. (If end-user require customization of the analytics, consider developing the analytics as embedded OOBIEE regions. For more information, see the Analytics and Reporting FAQ section).

End-user interactions can be divided into four broad categories:

  • Adjusting the content (parameters)
  • Clarifying the presentation (data tips, highlighting, and changing presentation type)
  • Accessing details (drilling, switching, and launching)
  • Taking actions (refreshing, printing, and exporting)
Adjusting the Content
Return to Top

Sometimes the content of graphs and tables is completely defined by the context of the page and no further refinement is necessary. But often users have flexibility to fine-tune the content by breaking information down in a different way, filtering the information to a specific item, or selecting to focus on a different item.

About Parameters

The most common way of enabling users to adjust the content is to provide parameters (or prompts), usually in the form of lists or other controls placed near the graph or table. Parameters may be the actual parameters defined as part of the underlying query, or they may be other constraints or variables that are not technically parameters but that are perceived as such by most users. In fact, adjusting some parameters may actually call up an entirely different analytic.

Some guidelines for using parameters with analytic displays include:

  • Group the parameters controls in one place.
  • Generally, place parameters directly above the analytic that they control. In some cases, you can place them in a column on the start side of the analytic. Always be clear and unambiguous about which parameters control which graphs or tables.
  • Use controls to enter parameters that are constrained (drop-down menus, option buttons, calendar controls) rather than using free-form fields so that users do not have to guess at acceptable values.
  • Provide default values for every parameter, even in cases where there is no clear default. When the page containing the analytic first loads, it should use these default values to automatically present a default graph or table. This saves users from some mouse clicks and also helps users to more quickly understand what the analytic is about.
  • If one parameter is dependent on another, place the controlling parameter immediately before the dependent parameter and adjust the list of choices for the dependent parameter as soon as users change a controlling value.
  • Do not provide users with every possible parameter. Instead, find the right balance between flexibility and simplicity. In most cases, one or two parameters are sufficient. Avoid displaying more than two rows of parameters if possible.
  • As a general rule, you do not need to include a Go button. Changing the value of a parameter should immediately result in an update of the graph. This saves users from clicking and helps prevent situations in which the parameter is out of synch with the data that actually appears.

Always try to keep the default parameter block small and the initial presentation of the graph focused on the message that you want to start with.

Grouping Related Analytics with the View Choice List

Sometimes multiple analytics related to a given theme need to be grouped together in one region. For example, the Turnover region can provide analysis of Turnover and Terminations information. Use a View <Analytics Title> choice list to enable users to switch between analytics grouped in a single region.

Figure 7. Correct example
Figure 8. Incorrect example

Note: OBIEE does not support using a switcher in the region.

To enable users to modify the list, add a Personalize value as the last option on the list.

Figure 9. Note the Personalize value

Examples of incorrect labels: Metric, Measure, Fact, Views.

Showing the Unit of Measure

Make the unit of measure part of the analytics title. For example:

Fulfillment Lines Exceptions
Fulfillment Lines Exceptions (Percentage of Total)
Fulfillment Lines Exceptions (Value)

Avoid Unit of Measure choice lists.

Note: Separating a metric and a unit of measure into choice lists is not supported by OBIEE.

Figure 10. Including the unit of measure as part of the analytics title

Dividing Information with the View By Choice List

The View By choice list enables users to see information divided in different ways. For example, if profit is broken down by item, users can select to see profit broken down by region or period instead. Use a View By <Dimension/Attribute Title> choice list to enable a users to switch a View By choice list value.

Figure 11. View By choice list example

The View By choice list can be used with graphs and tables showing multiple dimensions. Users will know which dimension will be changed based on the current View By selection. For example, in a table showing Profit by Item by Region by Period users can switch the current View By selection (Item) to Warehouse or to Supplier.

Incorrect label: Dimension.

Selecting Time Period and Other Ranges

In all other cases, use the native Zoom and Scroll features of the graph . If you have sufficient screen space, consider using the Filter by Time graph feature (which requires two adjacent graphs). To change the periodicity of the graph, use the native Drilling feature .

For tables, use these Date formats standards and guidelines:

For ranges other than dates follow the From <Attribute Value> To <Attribute Value> format, for example “From Invoice Number 1250 To Invoice Number 1750.”

Additional Sorting with the Sort By Choice List

Use a Sort By <Dimension/Measure/Attribute> choice list to prompt users for a sort order of a table or graph other than the one available through standard table sorting. For more information, see Table Standards.

Figure 12. Sort By choice list to sort the order of a table
Figure 13. Sort By choice list to sort the order of a graph

Showing Additional Analysis Options

You should usually keep the initial parameter block short and simple. If additional parameters are needed only by a subset of users or only in certain situations, you can provide an Analysis Options section collapsed by default. Expanding this section reveals additional parameters (as described in the Detail on Demand pattern set). The newly exposed parameters should all have default values whenever possible. Expanding or collapsing a parameter block should never in and of itself affect the graph or table in any way.

Figure 14. Analysis Options section
Figure 15. Expanded Analysis Options section

If layout constraints make it awkward for users to expand a parameter block in place, you can have it open as a separate dialog box as shown in this example:

Figure 16. Analysis Options dialog box

Note: This option is supported only by ADF Data Visualization Components. Notice that even after users close the Reporting Options dialog box, the three most important parameters (the lists showing which analytic is selected, how the information is divided, and the time period) always remain visible above the graph or table that they control.

Examples of incorrect labels: Filter, Filters, Filter By, Reporting Options, Analysis Criteria, Criteria

Read-Only Analysis Options

If you or an administrator set parameters values somewhere else, such as in a dialog box, and users absolutely need the settings for the proper understanding of the analytics, you can display those parameters as read-only on the page. Doing so is especially important for parameters that you set to other than the default value.

Figure 17 illustrates how when you set up manager and performance parameters in a dialog box, those values appear as read only on the page.

Figure 17. Options set on the Analysis Options dialog box appear as read only on the page
Clarifying the Presentation
Return to Top

Besides adjusting the content itself, users may need to fine-tune the way that the content is presented by highlighting, hiding or showing information, and changing the type of presentation.

Tooltips and Series Highlighting in Graphs

Unlike a graph printed in a report, an online graph can respond to user mouse movements in order to clarify what appears. You should take advantage of this ability in all Oracle Fusion graphs. The two most important techniques that you use to accomplish this advantage are data tooltips and highlighting.

Data tooltips are browser-based pop-up lists that identify a data item and specify its value. Data tooltips should always appear in Oracle Fusion graphs when users move the cursor over elements in either the graph or legend. Data tooltips are enabled by default.

Line and legend highlighting or fading highlights the series when users move the cursor over the text and makes other series transparent in both the graph and the legend. Highlighting is disabled by default, but you should enable it for graphs that allow drilling. In Oracle Fusion, page highlighting is the primary signal that informs users which graphs are clickable and which are not. Always enable highlighting for clickable graphs, and always disable it for static graphs.

Hiding and Showing Series in Graphs

Users can also adjust content by hiding and showing variables displayed in the graph using the Hide/Show Series feature built in to the graph control. Users do this by clicking the series marker in the graph legend. A tooltip appears when users move the cursor over items in the legend.

Generally, you should initially display all of the series and enable users to hide the ones they do not want to see. In some cases, though, you may want to initially display the subset of values that conveys the basic meaning and enable users to add additional elements as needed. Showing a subset of variables at the outset is also a good way to handle unpredictable amounts of data.

Applying Conditional Formatting with the Highlight Choice List

Prompt users to select a conditional format to apply to data with a Highlight <Conditional Format> choice list. The conditional format is a set of rules used for highlighting data based on selected criteria. For example, you can bold all invoices whose amount exceeds a certain threshold.

Figure 18. Highlight choice list

Switching the Type of Information Visualization with the Show Graph or Table Choice List

To enable users to switch between different types of data visualization, such as a table or graph, use the Show <Visualization Type> choice list.
If users have only two choices, as in case of table and graph, use the toggle control.

Figure 19. Show Graph choice list
Figure 20. Show Table choice list

If users can select between many options, such as different graph types, use a choice list. Note that if a table is one of the choices available, it will be in the choice list together with the graph types.

Figure 21. Choice list with graph types

Examples of incorrect labels: Chart, View, Display

Accessing Details
Return to Top

Graphs enable users to gain an initial understanding of an analytic, but users often need to see more details than can reasonably be shown in the graph itself. If a graph is the direct expression of a table, users may want to switch to or open that table to read the exact values more easily. Users may also want to drill down to more detailed information by clicking elements in a graph.

If you can display the table associated with a graph in the same container holding the graph, the simplest way to give users access to both the table and graph is to provide a switching mechanism. For more information, see the Switching the Type of Information Visualization section.

Figure 22. Switching from a graph to a table enables users to quickly access underlying data

In Figure 23, the graph appears with a Show Table link. When users click this link the table replaces its associated graph and the link to show graph. This approach enables users to easily switch back and forth between graph and table visualizations.

If the table or report summarized by a graph is too large or complex to fit in the same container, you should provide a link to open that table or graph in a separate window. As discussed previously, provide an explicit View Full Detail or similarly named link below the graph. Enabling users to use this link is particularly useful for small embedded analytics in the contextual area or other places where you have little space:

Figure 23. Viewing a graphi in a separate window

Drilling Down

Because drilling down is one of the most powerful ways for users to interact with a graph, use this technique whenever appropriate. Drilling in a graph is directly analogous to drilling in a table. Just as you can click a link in the cell of a table to see more information, you can click on a series bar or line to do the same thing. You should always enable users to drill down through any graph that is directly associated with a table containing cells and enable users to drill down through the elements that correspond to those cells.

Inform users about which graphs they can drill down in able which they cannot. One important way to signal this difference is to always enable highlighting for drillable graphs and disable it for nondrillable graphs. Then, as users roll over a graph, they receive a consistent indication that it does or does not support drilling.

Hierarchical Drilling

The most common form of drilling down is hierarchical drilling. Summary analytics use this method in which each number plotted is an aggregation of lower-level units, with all data obtained from the same query. For example, a summary bar graph might show Quarter 1 revenue across four major regions. For example, clicking the bar for North America might display a low-level graph showing Quarter 1 revenue across 10 company sites within North America. Users can repeat the process to drill down even deeper.

Users perform hierarchical drilling inline using the graph’s built-in drilling behavior. This ensures that only partial page refreshes are done and the surrounding context remains intact.

Drilling to Detail and Drilling to a Full Report or a Related Page

You can also enable drilling to detail, that is, clicking an element in a graph or table to display related information or a full report. You should not drill to detail inline. Instead, you should open a related table, graph, or report in a dialog box or separate window, leaving the parent page intact. If the link in the corresponding table is the kind that takes users users to a different page, clicking that element in the graph should do the same thing.

Master/Detail Relationships on the Same Page

You can also click items in tables to change other details on the page, either as part of a master/detail pairing or a way to update related embedded analytics. Clicking items in graphs can do the same thing, though this is less common. When using this technique you must use highlighting to identify which element is controlling the detail table or embedded analytic.

Taking Actions
Return to Top

In addition to changing the content or presentation of a graph, users may also need to act upon it in some way. The three most common actions that apply to a graph are refreshing, printing, and exporting.


Generally, refreshing a graph automatically whenever its page is loaded or when an associated control on the page is modified is sufficient to provide relevant up-to-date information in synch with surrounding content. In these cases a Refresh button is not needed, but you should still provide one in the container’s action menu.
Fusion GPS Graph Selection Tool
However, if the data represented is rapidly changing or if users are using the graph to actively monitor a changing situation, you may need to provide a Refresh button in the container’s header. In this case, use the read-only parameter or some other technique to display the last time that the graph was updated. For more information, see the Last Refreshed <Date> in the Task Stamps standards.

Figure 24. Correct example
Figure 25. Incorrect example

Use this option only when an automatic refresh is technically not feasible.


A printing option enables users to view the analytic as a separate PDF document that they can printed out, save, or email. Oracle Fusion recommends exposing this by including a Print option in the Actions menu. If this option is not available and users are likely to need a printing option, you can alternatively provide a Print Graph link just below the graph or table.


An export option enables users to save the graph as a spreadsheet that they can open and edit. As with printing, Oracle Fusion recommends including an Export item in the Action menu or an Export link just below the graph or table.

Mouse Button Actions

In certain applications users may need to select and act directly on elements within the graph or table. They can do so clicking the graph data points or table cells and displaying a contextual menu. If you feel that your application requires this kind of interaction, contact your user experience representative to see if this is the appropriate way of supporting the interaction.

Note: In OBIEE data visualization components the contextual menu is available only by clicking the left mouse button click and only if there no links are enabled on the selected data point or table cell.

Consider Gauges, Tables, and Spark Charts
Return to Top


Designers sometimes forget that graphs are not the only, or necessarily the best way, to present analytic information. For example, a dial gauge might be a more effective choice to convey a single metric (for example, the percentage of budget consumed) rather than a pie chart.

You can use three types of gauges, either individually or in sets: dials, light-emitting diode (LEDs), and graphical state meters. Each type has a standard recommended size for Oracle Fusion pages that fits easily within a single column or a three-column layout. In general, you gain little by stretching gauges to fill larger spans (although a meter can sometimes be made wider if you needed to convey a detailed range of values). Unlike graphs, you should set gauge widths to a fixed number of pixels, not to 100 percent of the container width.

Standard Size
Figure 26. Ring-filled dial gauge with a metric and value label
Width: 190 pixels, Height: 120 pixels
Figure 27. Dot LED with a metric and value label
Width: 140 pixels, Height: 50 pixels
Figure 28. Graphical status meter with a metric and value label
Width: 190 pixels, Height: 60 pixels

As with graphs, the width and height if dials, LEDs, and graphical status meters refer to the overall rectangle containing the gauge. So if you omit the metric and value label from the previous dot LED example, you would need to reduce the height so that the LED itself would not double in size. The gauge controls enable you to place values inside the gauge (for example, inside the LED), but this usually makes both the gauge and the label more difficult to read.


For precise values, using a simple list or table can be a better choice than using a bar graph. You can use tables inside the contextual area to create simple lists or two-column tables. Set the table width to 100 percent of the container and assume a width of 140 pixels. Use full-sized tables with graphs so that users can easily switch back and forth between the two. For more information, see the previous Accessing Details section.

Spark Charts

Stamping a table with word-sized graphs (spark charts) is a powerful data visualization technique that combines the benefits of a table and a graph. Use spark charts in a table permits to enable users to quickly compare and contrast records.

Figure 29. Spark chart, example 1
Figure 30. Spark chart, example 2

You can directly embed spark charts in the context of words, numbers, and images.

Figure 31. Spark chart, example 3

For more information about ADF tables, see the Table specifications. For more information about gauges, see the Gauges specifications.

Using Multiple Graphs or Embedded Analytics
Return to Top

When you need to display multiple graphs together it is important to make sure they are presented in a way that enables users to compare and consolidate information efficiently. The following sections discuss several possible ways of doing this.

Consider Building a Dashboard

If your end user needs to monitor, access, or act upon information across related activities and user objects in a particular domain, use a dashboard instead of multiple graphs or embedded analytics. For more information about determining when to use dashboards, see the Dashboard guideline.

Consider Using a Single Graph

Graphs can take a lot of screen space. Make sure that a single graph won't suffice before you decide to use multiple graphs. Users might find a single graph faster and easier to understand than multiple graphs because users must move their eyes back and forth more times to compare data displayed in multiple graphs.

Line, Clustered, and Stacked Bar Graphs

To determine if a single graph meet your needs, review the high-level tasks that users are trying to accomplish. Whatever graph you select must support users' primary task, and if possible, their secondary tasks as well. If the data that supports the primary and secondary tasks are in the same units of measure, plot both series in a single graph. For example, you could show a forecast and actual expenses over a common time period as two lines on a single line graph. For a large number of series that users may need to compare, consider providing parameters to enable users to show only the series they want to compare. For more information, see the previous Hiding and Showing Series section. As another example, you could use a clustered bar graph to show quarterly sales figures for several products over a common time period.

Dual-y and Split-y Graphs

You can use dual-y graphs for tasks that require users to compare data sets with different units or scales. Dual-y graphs use two vertical scales, one on each side of the graph, but share a common horizontal scale. If possible, use the same color for the plotted data and the associated scale. An alternative is a split-y graph, which takes up more screen space than a dual-y graph, but may help users read bar graphs or area graphs that would be otherwise be difficult to read in a dual-y graph.

Dual-Y Split-Y
dual y
split y
Figure 32. Dual-y and split-y graphs can be used to compare data in different scales or units.

Combination Graphs

You can also use a combination graph, which combines areas, lines, and bars in a single graph. Like dual-y graphs, combination graphs typically have a separate y-axis for different data sets.

Figure 33. Comination graph

To Show Only a Difference in Data Sets, Consider Transforming the Data

If the user's primary task is to illustrate a difference between two data sets, consider plotting the difference. For example, if the user's primary task is to appreciate the difference between forecast and actual expenses, you can plot the difference, instead of plotting both the forecast and actual expenses and expecting users to visually subtract the forecast from the actual amount.

Two Series Difference
Figure 34. In the graph on the left, users find it easier to appreciate a difference between two series. Users have more difficulty understanding the information when differences are calculated and plotted together as on the right.

Multiple Graphs: Graph Sets

Users can find applications with multiple graphs quite complex to use, so take the time to identify users’ most likely tasks, and identify the best possible graphs to support those tasks.

For more information on resources that are available to help you determine the best graph to use for particular tasks, see the Fusion GPS Information Display Design Patterns, the Fusion GPS Graph Selection Tool, and the Consider Using a Single Graph section of this document. Once you have determined the graphs you need, the guidelines in the following section can help you determine if you can embed the graphs directly or if you need to place the graph on a tab.

If you are designing a complex work area to support multiple tasks, you should attempt to establish mapping between graph sets that would be most appropriate for accomplishing the most likely user tasks. In advanced analytical applications, you may not be able to predict the most appropriate graphs to present. In this case, you may have to present users with options to choose which graphs they want to see in a secondary window or dynamic tab. For more information, see the sections that follow.

Your Graph Set Supports a Single Task

Embed Adjacent Graphs Directly on Your Page

You should use adjacent graphs and avoid using a list to switch between graphs whenever possible. Using a list to switch between graphs saves screen space, but users cannot easily compare graphs because they can see only one graph at a time. Review your layout to determine if the screen real estate allows enough room for adjacent graphs.

Embed Adjacent Graphs in a Tab

If you don’t have enough space to embed the graphs directly in your page, you should put them on an auxiliary tab labeled Analytics. Using a tab is less helpful than embedding the graphs directly in the context for users, but the graphs can be compared side-by-side and are still relatively easy to access.

adjacent in a tab
Figure 35. Placing graphs on an auxiliary tab labeled Analytics

Your Graph Sets Support Multiple Tasks

When you need to support multiple tasks, include a way for users to switch between multiple associated graph sets.

Switch Graph Sets by Selecting Table Rows

To update graph sets, you can use row selection on a table in which each row is associated with a task. In the Order Fulfillment application (see figure 37), backordered items are listed as rows in a notifications table. Selecting a row can automatically update the graph set displayed below the table. Place the most useful graphs first. These graphs show the availability of the item at other warehouses, the status of other items in the same order, and historical information about any previous late orders for the customer.

Table Rows
Figure 36. Using row selection on a table

Note that when graph sets get large, you can organize them into subgroups. In this example, you can organize the graph set to help users manage a back-ordered item in an Order Fulfillment flow of a Supply Chain Management application into three subgroups: graphs that show information about the back-ordered item, the associated order, and the associated customer. Within each group, display the most useful graph first. Use a list to enable users to access the other graphs in each group.

Use Tabs to Organize Tasks and Graph Sets

As an alternative to table row selection, you can use separate tabs to organize different tasks and their associated graph sets.

Table Rows
Figure 37. Using separate tabs to organize different tasks and their associated graph sets

Allow Users to Select Graphs to Compare

When designing analytical applications for advanced users, such as data analysts, enable users to select which graphs they want to compare. Users can navigate to graphs by clicking Compare Graphs in a list of available graphs. This opens a dialog box enabling them to select a number of graphs, which then appear in a secondary window.

Choosing Graphs to Compare
Step 1
Figure 38. A compare graphs item appears in a list of available graphs.
Step 2
Figure 39. A dialog box appears that enables users to select a number of graphs.
Step 3
Figure 40. After users make selections, the system displays the graphs in a secondary window.

General Guidelines for Using Multiple Adjacent Graphs

Share a Scale or Legend if Possible

Sharing a scale or a legend saves screen space. Users also find it easier to compare values that use the same scale and to compare graphs that use the same mapping of colors to categories. Of course, graphs can only share a single scale if they show quantities in the same range and units, and they can share only a legend if they show the same set of categories. If you need to use multiple gauges, consider using a gauge-set, which is designed to allow multiple gauges to share a single scale and legend.

Support Comparisons of Similarly Transformed Data

Presenting data in a form that supports comparison can be misleading and risky if the data has not been collected, measured, or transformed in a consistent manner. When users need to compare data that has been collected over time periods of different lengths, be sure to label the differences clearly. For example, in the Organizing tasks and graph sets with tabs example (see figure 38), the intent is to enable a warehouse manager to compare the current day’s metric to those of the previous day. But these comparisons are only valid at the end of a day. You may select to display comparisons between metrics from the previous 24-hour period and metrics from between the previous 48-24 hour period.

Use the Same Graph Types if Possible

Users find it is easier to compare graphs of the same type than graphs that are of different types. For example, instead of using a bar graph and a pie graph, consider using two bar graphs.

Check that Colors and Other Settings Are Used Consistently

While most graph settings are determined automatically for Oracle Fusion applications, you should ensure that the default settings for individual graphs minimize meaningless visual differences between multiple graphs. Users comparing graphs expect visual differences to be meaningful. For example, if one graph uses a certain color to display a particular category, make sure that category is displayed using the same color in every other graph on the page. Ensure that similar colors are used to indicate similar categories.

You may need to override other settings for graphs that display different amounts of data. For example, when using two pie graphs, users may be confused if one pie has labeled slices, while another does not. They may also be confused if the pies themselves are different sizes.

Displaying Analysis Options Shared by Several Analytics

If a group of analytics share some of the parameters or any other analysis options, you can group the shared analysis options either together or duplicated.

If you group the shared analysis options together, they should be grouped in a region preceding the analytics.

Possible placements of the shared analysis options region

Shared analysis options at the top of the two analytics regions

Figure 41. Shared analysis options on the start side of analytics

If you duplicate the analysis options between analytics, pass the selected option from one analytic to another.

Passing selected analysis options between analytics

Figure 42. In this example, the default selection for the Manager field is blank in both the Terminations and Turnover analytics. Once users select Nicolas Guardino as the manager in the Terminations region, the selection does not change when users move to the Turnover region.
About Oracle | Legal Notices | Terms of Use | Your Privacy Rights