The goal of most dashboards is to magnify specific points of data, making them easy for users to identify. To achieve this goal effectively, you must make certain decisions before you begin creating your dashboard. The best practices described below are grouped into the following sections:
You can use existing reports and documents as datasets in a new dashboard. This can save you time and help avoid unnecessary duplication in your MicroStrategy metadata. You can also create new datasets for your dashboard.
A dataset should have enough data to be useful as a rich source of analysis for many users, but it should not have extra data that is not needed on the dashboard. For example, do not include product item information when you only want to display product category information.
As you gather or create datasets, focus on important indicators such as performance stakes, trends, and variances.
Users typically browse a large number of reports somewhat randomly, looking for interesting trends. You can gather related reports to use on your dashboard, so that all the data is available together in a single context. Users can locate the data more easily and analyze it more efficiently.
When choosing reports to incorporate into a single layer on a dashboard (a dashboard page or panel), consider the ratio of graph to grid reports to display. Common graph:grid ratios range from 4:1 to 1:3. The average graph:grid ratio from a general sample of dashboards was approximately 2:1.
Consider using a dashboard in place of 8-12 existing reports in your MicroStrategy project. You will generally use 3-5 reports on each layer of the dashboard; dashboards generally have from one to three layers (see About layering data in dashboards: Panels and panel stacks).
Consider using a dashboard to replace three to four existing documents in your MicroStrategy project. If you have three documents that contain data from a related subject area, you can use each document as a single layer or panel of your dashboard. Having all this related information in one dashboard can provide a more productive analysis experience for your users.
For example, you have three documents for your human resources department. Each document is related to salaries and other benefits, headcounts, or hiring. Create a dashboard with a panel stack sized to take up the entire screen. Add two more panels so you have three panels in the panel stack. Then re-create the first document on the first panel of the dashboard, the second document on the second panel, and so on. Add a selector of three tabs (buttons) at the top of the panel stack. Users can tab between the layers of human resources data, depending on whether they are interested in headcounts, hiring, or salaries. For a sample of this dashboard, see the MicroStrategy Report Services Document Creation Guide.
Plan to have from one to three layers for your dashboard. You can visualize these layers as pages of your dashboard; analysts will see one page at a time. Multiple layers allow you to design a dashboard that contains much more information overall, but presents only a reasonable subset of that information in the layer currently being displayed.
Create layers by adding a panel stack to your dashboard. Size the panel stack so it is large enough to take up the entire screen. Then place enough panels on the panel stack to equal the number of layers needed in your dashboard. Each panel becomes one layer of your dashboard. Finally, create a set of tabs above the panel stack by adding a selector made of buttons, one tab (button) for each layer (panel).
Consider grouping data by layers according to subject areas or business dimensions, with one subject area or business dimension per layer. For example, one layer might show income at the corporate level, while a second layer might also show income but at a departmental level or a regional level. The final layer might show detailed income data. This lets you serve diverse user communities without overwhelming users, as they can each flip to and work with the dashboard layer that specifically interests them.
Consider grouping data by layers according to regions of the country or regions of the world, so that, for example, sales metrics can be displayed within a given regional context.
Use Microsoft Excel, Paint, PowerPoint, or another tool to create a mockup of the dashboard. The mock-up should convey a clear vision of the information, structure, layout, and formatting. Send the mock-up to your user community to gather feedback on its usefulness. This can save time creating and formatting a complex, finished dashboard that may need to be redone.
Group related reports so they can be placed in a small panel stack, each panel displaying a single report. As users flip through the panels, they will be flipping through the related reports. The reports in a panel stack should not be reports that a user might want to see side by side in a dashboard; rather, the reports should show different levels of detail about the same or closely related data.
Plan to provide visualizations. These can include any of the available widgets, such as a gauge, thermometer, heat map, and so on, which can help users understand data at a glance. Consider the following best practice:
Do not add so many graphical objects that the focus of the dashboard is no longer the data. Too many visualizations can detract from the importance of the data.
Plan to provide interactivity. This can include any of the available selectors, such as tabs, buttons, and sliders, which let users change a report’s metrics, attribute elements, and filters. Interactive features let users customize the display of data without needing a developer or designer to perform any work.
Consider common user workflows when designing a dashboard. Think about how analysts are going to move through the dashboard, what links they will want to click, and so on. Try to embed this workflow directly into the dashboard. Do this by placing objects so that data can be interpreted from the top left to the bottom right.
Granularity should increase from top to bottom on a dashboard. For example, place objects that display key performance indicators at the top of the dashboard. These objects might include large graphs such as a funnel graph (also called a pipeline), a pie graph, widgets such as a gauge, and so on.
Decide which objects on the dashboard should share the same formatting styles, and which objects should be physically aligned with each other. These decisions are important time-savers if you make them before you spend a lot of time actually formatting objects and fine-tuning object placement.
for trends, summaries, and other high-level data. If users want to analyze
details in a report, too many effects can make it difficult to understand
more detailed data.
For example, if you apply the curved effect to the line in a line graph, the exact points where the line hits the graph are adjusted so that the line can be curved smoothly. This looks nice, but users who rely on seeing every detail will have difficulty. If you want to apply the curved effect, you can also provide a grid report alongside showing exact values. An alternative is adding tooltips (a mouseover) which display actual values for points on the graph.
Place reports into appropriate areas on the dashboard, and then resize them as needed to achieve your planned appearance. Placement should take into account the user workflow and granularity discussions in Layering information in a dashboard.
Keep the number of objects on the screen to a minimum to achieve a clean look. Use graphical objects sparingly. Make use of abbreviated text in text fields as appropriate, to make the best use of space. You can add a tooltip (a mouseover) to explain any abbreviations that may not be clear to all users.
For any graph or widget, provide a tooltip (a mouseover) so that users who are interested in specific details can see the actual values behind the general trends displayed by graphic visualizations. This is an excellent way to support two sets of users who need widely differing levels of information on the same subjects.
Provide a quick switch capability for all graph reports, so users can switch with a single click between the graphical display of data and its corresponding grid report showing individual cells with specific values.
Provide a title bar on reports (Grid/Graphs) on the dashboard so users can maximize and minimize the individual reports. This ability to minimize and maximize reports provides users with a portal-like environment, with each report behaving like a portlet window. This allows users to control how space is used on their screens, and to focus on the data they are interested in. The title bar also allows the user to examine the dataset report contained in the Grid/Graph directly from the dashboard.
If you have a panel stack on the dashboard, add a selector so users can flip between the panels on the panel stack.
Sliders are best used on graphs that specify a date range. Sliders can not only change the time frame of the data displayed in a report or set of reports, they can also change the span of time being analyzed.
If you have related reports on a dashboard layer, add a selector to one of the reports and connect it to the related report. When users choose to see a certain aspect of the first report, the second report automatically changes to display the related data. When the user clicks on one grid or graph, his selection serves as a filter for the related grid or graph. For example, in a pie graph showing revenue for all products, a user clicks a slice of the pie graph representing electronics revenue. The connected report below the pie graph, displaying detailed sales numbers, automatically updates its data to reflect the user’s selection, displaying sales numbers for various electronic products.
Add selectors to different parts of the dashboard so users can customize the data they see at many levels. For example, add a selector at the top of the dashboard itself, so users can switch between layers of the dashboard. Then add a selector at the top of an individual layer, so users can change metrics, for example, to change the focus of that layer of the dashboard. Finally, add a selector to each of the reports on that layer, so users can focus the details of their analysis on a specific area.
Use as few datasets as possible when designing the dashboard. For example, one dataset report with 1000 rows displays faster than ten smaller dataset reports. However, be aware that combining dataset reports can create a Cartesian join, which inflates the size of the combined dataset and results in slower performance. For more information about dataset joining, refer to the MicroStrategy Report Services Document Creation Guide.
Having all the data in the rows negatively impacts the rendering time for Editable Mode and Interactive Mode.
A selector with many items (for example, the buttons or check boxes) increases the time it takes for the dashboard to execute. For example, if you increase the number of items by a factor of ten, server execution times can increase up to 50%. In essence, a larger number of items translates into a larger dataset.
Flash Mode provides better performance when selectors have many targets, that is, the Grid/Graphs and/or panel stacks affected by the selectors.
A selector that controls attributes displayed on a Grid/Graph performs faster than a selector that controls attributes that are displayed on a panel.
Nesting panel stacks (that is, placing a panel stack on a panel) increases client rendering time. To reduce that time, include data in both panel stacks, not just the nested panel stack.
In Flash Mode, after the dashboard is initially loaded, manipulations such as choosing a selector item are executed on the client machine. In contrast, such manipulations in Interactive Mode send additional requests from Web Server to Intelligence Server. Since Flash Mode uses minimal server resources after the initial load is complete, system overhead is reduced for multiple users concurrently manipulating their dashboards. Therefore, Flash Mode has faster response times for manipulations, regardless of the number of users accessing the dashboard. However, these same users must accept longer document execution times due to the initial loading of Flash.
Graphs perform better in Flash Mode than in Editable Mode and Interactive Mode.