Best Practices for Designing Dashboards

This article describes commonly used best practices that should be followed when designing and editing dashboards. Following these best practices make sure that the dashboards are easy to maintain, respond quickly and are understandable and illustrative.

Visualization

• Define a custom title for the chart, if the automatically generated title is not descriptive.
• Define a custom label text if they describe the measures and dimensions better. Still, in many measures and dimensions, the automatically generated title is suitable.
• Check that each measure and dimension has a descriptive unit. For example, the generic terms "cases" and "events" might not describe the counts best, and cases might be orders, incidents etc.
• Note also how the special values , such as null and empty strings, are presented and set a descriptive label name. For example, when showing duration between events, cases which don't have the events, are shown as nulls. Instead of empty label, the label can be "Events missing".
• Use conditional formattings to improve KPI visualization, especially in tables.

Usability

• Use on-screen settings for settings that often users want to change, as they are easier to use than opening the settings. They also guide users to change parameters that might be relevant from the analysis viewpoint.
• Limit the shown case/event attributes and event types, if there are some that are not needed. This will make the dropdown lists shorter making it easier for users to find the important selections. This doesn't have performance impact, though.
• Mappings from measures and dimensions to visualization, such as X-and Y axis can be done freely, so dimensions don't always need to go to the X-axis and measures go to the Y-axis. For some special analysis, it might be easier to use the table to first set the desired measures and dimensions to get the needed data, and then switch to the graphical visualization (such as column, bar or line chart) and map the table columns to the chart.
• Use preset as basis when designing dashboards. The preset contain commonly needed analysis, so in many cases, you'll find what you are looking for from the presets. It's easy to create a chart by taking a preset as a basis, and continue modifying the chart settings for your customized needs.
• Avoid Custom Layout json settings as their compatibility with future QPR ProcessAnalyzer versions might not be maintained. Use the custom layout json only when it's absolutely necessary to achieve the desired visualization.

Working with filters

• If there are no meaningful filters that can be created from the chart, disable creating filters from chart. When filtering is disabled, the cursor doesn't indicate clickable items which would otherwise attract users from making clicks leading to dead end.
• Filters can be added both to the dashboard level (affecting all charts) and to individual chart level. For filters that are common among most of the charts, are usually best to set to the dashboard level. For those charts that don't use the common filters, the Chart Follows Dashboards Filters setting can be disabled. Also a difference between the dashboard and chart level filters, is that the dashboard level filters are also clearly visible in the dashboard, and they can be easily changed in an ad-hoc basis. From the performance viewpoint, it doesn't matter in which level the filters are defined.
• The dashboard level filter can either be an Unsaved filter or it can be saved as a separate filter in the model. The dashboard anyways stores the filter rules, so saving the filter is not necessary. One difference is that the stored filter has a name which is visible below the model name. Also if the dashboard level filter rules are changed, the original filter can be restored by selecting the saved filter in the filters menu.

Performance optimization

• When choosing the Analyzed objects setting, prefer Cases over Events, as calculating from events is notably slower than cases, because in usual models there are lot more events than cases. Some KPI's, even though using the event level data, can be calculated from the cases. Also Variations, Event types and Flows are generally fast. On the other hand, Flow Occurrences is slow, as the number of the for occurrence objects is even more than the event count.
• Prefer ready-made measures and dimensions, and create a custom when there no ready-made available. This is because the ready-made measures and dimensions have been optimized for performance. When creating a custom measure or dimension, you need to be careful not to write the calculation logic in an non-optimal way.
• For some simple calculations, the Statistical calculations may be used instead of writing a custom expression. Also the Adjustment expression is useful in avoiding custom expressions in certain cases..
• Limit number of returned rows: The Max rows setting determines the number of returned rows. The less there are rows the better performance. Usually in dashboards, limiting the amount of shown data is desired also for usability, e.g., show only the top-20 items etc.
• The more there are charts in the dashboard, the more it takes to get the dashboard opened and all chart shown. This is because each chart requests a calculation which all need to be done at the same time in the server. If the dashboard opens slowly, charts could be divided into multiple dashboards and links created to navigate between them.
• Sorting the data affects performance, so use sorting only when it's relevant for the analysis.
• Group Rows Exceeding Maximum goes through all rows that otherwise would be left out of the calculation, which has an impact on the performance, so use it only when the information is useful for the analysis.
• Alternative to chart filter is Analyzed objects containing filtering, e.g. ... might improve performance
• Don't use dimensioning when it's not needed. When desire is to have a row for each root object, dimensioning is unnecessary. For example, Cases as Analyzed objects and dimensioning by case id will lead to a row for each case, but the same result can be achieved by disabling dimensioning.

Advanced performance optimization

• For slow charts, use the Benchmark Performance to find the fastest settings. Usually settings up a working chart is the first thing to do, and if the chart appears too slow, you can try to find another, faster way to calculate the same chart.
• Calculated attributes can improve performance, as they can pre-calculate event level information to case level. Calculated attributes cannot be used when there is event type filtering applied, as the calculated attributes are only calculated when the model is loaded and thus filtering doesn't affect the calculated attributes. On the other hand, don't use calculated attributes unnecessarily, because they are stored into memory, and thus they consume memory similar to normal attributes.
• Don't calculate anything from the entire model level in the calculated attributes expression, because it will lead to very slow performance in model loading.
• Avoid making same calculations multiple times in different measures. If there are repeating expressions, create a separate measure for the repeating part, and define the measure as a variable, which can then be referenced from other measures.
• When using custom expressions, and there are parts of the expression produce same result for each measure/dimension, calculate that part separately in the Additional root expression and store the result to a variable. There the calculation is done only once improving performance. For example, if creating measure that makes a comparison to the entire model, the model level part can be calculated in the Additional root expression.
• Sampling improves performance in cases when it can be used. The idea of sampling is to pick only a portion of the root objects for the dimension and measure calculation to improve performance. Unfortunately, in most cases, it cannot be used, as it affects the analysis results, for example in object counts.
• Different models can be used in the same dashboard, and for example filtering still works if the models use same case/event attribute and event type names. This allows to create models optimized for specific charts, which might improve performance.

Exporting data

• When exporting large amount of data, use the CSV export, as it performs better for large data comparing to the Excel export. Very large datasets (such as over million rows) cannot be exported even with the CSV export in one run. To get the data exported, the dataset can be divided into smaller parts by using the Start at row and Rows to export settings.