Analytic Display Guidelines
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.
The Oracle Fusion Guidelines, Patterns, and Standards (GPS) site offers several resources to help you with this and other questions:
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.
*For the typical height, always inspect the runtime presentation and adjust the height as needed.
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.
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.
Note: Small graphs currently default to two-column legends, which cause most values to be severely truncated.Dealing with Small Graphs
Follow these tips for squeezing graphs into the narrow Oracle Fusion side areas:
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.
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.
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|
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.
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.
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.
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.
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.
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:
For more information about these options, see the Graph specifications.
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:
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:
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).
Here are the sage guidelines for the term percentage and the % symbol in analytics interfaces:
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|
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.
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:
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.
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.
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.
Examples of incorrect labels: Metric, Measure, Fact, Views.
Make the unit of measure part of the analytics title. For example:
Avoid Unit of Measure choice lists.
Note: Separating a metric and a unit of measure into choice lists is not supported by OBIEE.
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.
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.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.”
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.
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.
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:
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
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.
|Clarifying the Presentation|
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.
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.
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.
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.
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 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.
Examples of incorrect labels: Chart, View, Display
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.
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:
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.
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.
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.
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.
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.
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.
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|
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
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.
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.
You can directly embed spark charts in the context of words, numbers, and images.
|Using Multiple Graphs or Embedded Analytics|
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
When you need to support multiple tasks, include a way for users to switch between multiple associated graph sets.
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.
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.
As an alternative to table row selection, you can use separate tabs to organize different tasks and their associated graph sets.
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.
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.
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.
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.
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.
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.
If you duplicate the analysis options between analytics, pass the selected option from one analytic to another.