Best Practices for Designing Dashboards - Revision history

Ollvihe: /* Exporting data */

2022-03-31T11:47:34Z

Exporting data

← Older revision		Revision as of 11:47, 31 March 2022
Line 39:		Line 39:

	== Exporting data ==		== 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.		* When exporting large amount of data, use the CSV export, as it performs better for large dataset comparing to the Excel export. Note that when using the CSV export, you don't need to increase the ''Maximum rows'' setting, but instead set the ''Rows to export'' in the CSV export dialog (as the settings work independently of each other).
			* 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.

Ollvihe: /* Advanced performance optimization */

2022-03-31T09:26:24Z

Advanced performance optimization

← Older revision		Revision as of 09:26, 31 March 2022
Line 35:		Line 35:
	* Sampling the data improves performance significantly. The idea of sampling is to pick only a portion of the root objects for the dimension and measure calculation to improve performance. Still, in most charts sampling cannot be used, as it affects the analysis results, for example count of cases and events. See more of the [[QPR_ProcessAnalyzer_Chart#Analyzed_Data\|Analyzed objects sample size]] setting.		* Sampling the data improves performance significantly. The idea of sampling is to pick only a portion of the root objects for the dimension and measure calculation to improve performance. Still, in most charts sampling cannot be used, as it affects the analysis results, for example count of cases and events. See more of the [[QPR_ProcessAnalyzer_Chart#Analyzed_Data\|Analyzed objects sample size]] setting.
	* [[Calculated_Attributes_in_QPR_ProcessAnalyzer\|Calculated attributes]] can improve performance, as they can pre-calculate expressions already in the model loading. For example, event level information can be calculated to case level using calculated case attributes. Calculated attributes cannot be used when there is event type filtering applied, as the calculated attributes are calculated when the model is loaded and thus filtering doesn't affect them. Also, don't use calculated attributes unnecessarily, because they are stored into memory, and thus they consume memory similar to normal attributes.		* [[Calculated_Attributes_in_QPR_ProcessAnalyzer\|Calculated attributes]] can improve performance, as they can pre-calculate expressions already in the model loading. For example, event level information can be calculated to case level using calculated case attributes. Calculated attributes cannot be used when there is event type filtering applied, as the calculated attributes are calculated when the model is loaded and thus filtering doesn't affect them. Also, don't use calculated attributes unnecessarily, because they are stored into memory, and thus they consume memory similar to normal attributes.
	* In calculated attributes, avoid calculating anything from the entire model data, because it will lead to very slow performance in model loading. ~~Calculated~~ attributes ~~can~~ be used to refer to the case itself and its events.		* In calculated attributes, avoid calculating anything from the entire model data, because it will lead to very slow performance in model loading. Especially for large models, calculated attributes should be used to refer only to the case itself and its events.
	* 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.		* 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 ==		== 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.		* 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.

Ollvihe: /* Advanced performance optimization */

2022-03-31T09:25:29Z

Advanced performance optimization

← Older revision		Revision as of 09:25, 31 March 2022
Line 31:		Line 31:
	== Advanced performance optimization ==		== Advanced performance optimization ==
	* For slow performing charts, use the [[QPR ProcessAnalyzer Chart#Benchmark performance\|Benchmark Performance]] to experiment which settings provide the best performance. Usually the first thing to do is setting up a working chart, and if the chart shows too slowly, with the benchmark performance you can try to find an alternative and faster way to calculate the same chart.		* For slow performing charts, use the [[QPR ProcessAnalyzer Chart#Benchmark performance\|Benchmark Performance]] to experiment which settings provide the best performance. Usually the first thing to do is setting up a working chart, and if the chart shows too slowly, with the benchmark performance you can try to find an alternative and faster way to calculate the same chart.
	* [[Calculated_Attributes_in_QPR_ProcessAnalyzer\|Calculated attributes]] can improve performance, as they can pre-calculate expressions already in the model loading. For example, event level information can be calculated to case level using calculated case attributes. Calculated attributes cannot be used when there is event type filtering applied, as the calculated attributes are calculated when the model is loaded and thus filtering doesn't affect them. Also, don't use calculated attributes unnecessarily, because they are stored into memory, and thus they consume memory similar to normal attributes.
	* In calculated attributes, avoid calculating anything from the entire model data, because it will lead to very slow performance in model loading. Calculated attributes can be used to refer to the case itself and its events.
	* Avoid calculating same expressions multiple times in different measures of the same chart. 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.		* Avoid calculating same expressions multiple times in different measures of the same chart. 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 that give same result for all measures/dimensions, calculate that part separately in the [[QPR_ProcessAnalyzer_Chart#Working_with_custom_expressions\|Additional root expression]] and store the result to a variable. This way the calculation is done only once improving performance significantly. For example, if creating a measure that makes a comparison to the entire model, such as percentage of the entire model data, the model level part should be calculated in the Additional root expression.		* When using custom expressions, and there are parts of the expression that give same result for all measures/dimensions, calculate that part separately in the [[QPR_ProcessAnalyzer_Chart#Working_with_custom_expressions\|Additional root expression]] and store the result to a variable. This way the calculation is done only once improving performance significantly. For example, if creating a measure that makes a comparison to the entire model, such as percentage of the entire model data, the model level part should be calculated in the Additional root expression.
	* Sampling the data improves performance significantly. The idea of sampling is to pick only a portion of the root objects for the dimension and measure calculation to improve performance. Still, in most charts sampling cannot be used, as it affects the analysis results, for example count of cases and events. See more of the [[QPR_ProcessAnalyzer_Chart#Analyzed_Data\|Analyzed objects sample size]] setting.		* Sampling the data improves performance significantly. The idea of sampling is to pick only a portion of the root objects for the dimension and measure calculation to improve performance. Still, in most charts sampling cannot be used, as it affects the analysis results, for example count of cases and events. See more of the [[QPR_ProcessAnalyzer_Chart#Analyzed_Data\|Analyzed objects sample size]] setting.
			* [[Calculated_Attributes_in_QPR_ProcessAnalyzer\|Calculated attributes]] can improve performance, as they can pre-calculate expressions already in the model loading. For example, event level information can be calculated to case level using calculated case attributes. Calculated attributes cannot be used when there is event type filtering applied, as the calculated attributes are calculated when the model is loaded and thus filtering doesn't affect them. Also, don't use calculated attributes unnecessarily, because they are stored into memory, and thus they consume memory similar to normal attributes.
			* In calculated attributes, avoid calculating anything from the entire model data, because it will lead to very slow performance in model loading. Calculated attributes can be used to refer to the case itself and its events.
	* 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.		* 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 ==		== 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.		* 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.

Ollvihe: /* Advanced performance optimization */

2022-03-31T09:23:49Z

Advanced performance optimization

← Older revision		Revision as of 09:23, 31 March 2022
Line 32:		Line 32:
	* For slow performing charts, use the [[QPR ProcessAnalyzer Chart#Benchmark performance\|Benchmark Performance]] to experiment which settings provide the best performance. Usually the first thing to do is setting up a working chart, and if the chart shows too slowly, with the benchmark performance you can try to find an alternative and faster way to calculate the same chart.		* For slow performing charts, use the [[QPR ProcessAnalyzer Chart#Benchmark performance\|Benchmark Performance]] to experiment which settings provide the best performance. Usually the first thing to do is setting up a working chart, and if the chart shows too slowly, with the benchmark performance you can try to find an alternative and faster way to calculate the same chart.
	* [[Calculated_Attributes_in_QPR_ProcessAnalyzer\|Calculated attributes]] can improve performance, as they can pre-calculate expressions already in the model loading. For example, event level information can be calculated to case level using calculated case attributes. Calculated attributes cannot be used when there is event type filtering applied, as the calculated attributes are calculated when the model is loaded and thus filtering doesn't affect them. Also, don't use calculated attributes unnecessarily, because they are stored into memory, and thus they consume memory similar to normal attributes.		* [[Calculated_Attributes_in_QPR_ProcessAnalyzer\|Calculated attributes]] can improve performance, as they can pre-calculate expressions already in the model loading. For example, event level information can be calculated to case level using calculated case attributes. Calculated attributes cannot be used when there is event type filtering applied, as the calculated attributes are calculated when the model is loaded and thus filtering doesn't affect them. Also, don't use calculated attributes unnecessarily, because they are stored into memory, and thus they consume memory similar to normal attributes.
	* In calculated attributes, avoid calculating anything from the entire model data, because it will lead to very slow performance in model loading. Calculated attributes can be used to refer to the case itself and		* In calculated attributes, avoid calculating anything from the entire model data, because it will lead to very slow performance in model loading. Calculated attributes can be used to refer to the case itself and its events.
	its events.
	* Avoid calculating same expressions multiple times in different measures of the same chart. 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.		* Avoid calculating same expressions multiple times in different measures of the same chart. 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 that give same result for all measures/dimensions, calculate that part separately in the [[QPR_ProcessAnalyzer_Chart#Working_with_custom_expressions\|Additional root expression]] and store the result to a variable. This way the calculation is done only once improving performance significantly. For example, if creating a measure that makes a comparison to the entire model, such as percentage of the entire model data, the model level part should be calculated in the Additional root expression.		* When using custom expressions, and there are parts of the expression that give same result for all measures/dimensions, calculate that part separately in the [[QPR_ProcessAnalyzer_Chart#Working_with_custom_expressions\|Additional root expression]] and store the result to a variable. This way the calculation is done only once improving performance significantly. For example, if creating a measure that makes a comparison to the entire model, such as percentage of the entire model data, the model level part should be calculated in the Additional root expression.

Ollvihe: /* Advanced performance optimization */

2022-03-31T09:23:32Z

Advanced performance optimization

← Older revision		Revision as of 09:23, 31 March 2022
Line 32:		Line 32:
	* For slow performing charts, use the [[QPR ProcessAnalyzer Chart#Benchmark performance\|Benchmark Performance]] to experiment which settings provide the best performance. Usually the first thing to do is setting up a working chart, and if the chart shows too slowly, with the benchmark performance you can try to find an alternative and faster way to calculate the same chart.		* For slow performing charts, use the [[QPR ProcessAnalyzer Chart#Benchmark performance\|Benchmark Performance]] to experiment which settings provide the best performance. Usually the first thing to do is setting up a working chart, and if the chart shows too slowly, with the benchmark performance you can try to find an alternative and faster way to calculate the same chart.
	* [[Calculated_Attributes_in_QPR_ProcessAnalyzer\|Calculated attributes]] can improve performance, as they can pre-calculate expressions already in the model loading. For example, event level information can be calculated to case level using calculated case attributes. Calculated attributes cannot be used when there is event type filtering applied, as the calculated attributes are calculated when the model is loaded and thus filtering doesn't affect them. Also, don't use calculated attributes unnecessarily, because they are stored into memory, and thus they consume memory similar to normal attributes.		* [[Calculated_Attributes_in_QPR_ProcessAnalyzer\|Calculated attributes]] can improve performance, as they can pre-calculate expressions already in the model loading. For example, event level information can be calculated to case level using calculated case attributes. Calculated attributes cannot be used when there is event type filtering applied, as the calculated attributes are calculated when the model is loaded and thus filtering doesn't affect them. Also, 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 calculated attributes expressions~~, because it will lead to very slow performance in model loading.		* In calculated attributes, avoid calculating anything from the entire model data, because it will lead to very slow performance in model loading. Calculated attributes can be used to refer to the case itself and
			its events.
	* Avoid calculating same expressions multiple times in different measures of the same chart. 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.		* Avoid calculating same expressions multiple times in different measures of the same chart. 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 that give same result for all measures/dimensions, calculate that part separately in the [[QPR_ProcessAnalyzer_Chart#Working_with_custom_expressions\|Additional root expression]] and store the result to a variable. This way the calculation is done only once improving performance significantly. For example, if creating a measure that makes a comparison to the entire model, such as percentage of the entire model data, the model level part should be calculated in the Additional root expression.		* When using custom expressions, and there are parts of the expression that give same result for all measures/dimensions, calculate that part separately in the [[QPR_ProcessAnalyzer_Chart#Working_with_custom_expressions\|Additional root expression]] and store the result to a variable. This way the calculation is done only once improving performance significantly. For example, if creating a measure that makes a comparison to the entire model, such as percentage of the entire model data, the model level part should be calculated in the Additional root expression.

Ollvihe at 09:20, 31 March 2022

2022-03-31T09:20:10Z

← Older revision		Revision as of 09:20, 31 March 2022
Line 6:		Line 6:
	* Mappings from measures and dimensions to visualization, such as X- and Y-axis can be set freely, so dimensions don't always need to go to the X-axis and measures to the Y-axis. For some special analysis, it might be easier to use the table to first configure the desired measures and dimensions, and then switch to the desired graphical visualization (such as column, bar or line chart) and map the table columns to the chart.		* Mappings from measures and dimensions to visualization, such as X- and Y-axis can be set freely, so dimensions don't always need to go to the X-axis and measures to the Y-axis. For some special analysis, it might be easier to use the table to first configure the desired measures and dimensions, and then switch to the desired graphical visualization (such as column, bar or line chart) and map the table columns to the chart.
	* Use presets as basis when creating charts. The presets 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 starting from a preset, and continue modifying the chart settings for your customized needs.		* Use presets as basis when creating charts. The presets 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 starting from a preset, and continue modifying the chart settings for your customized needs.
	* Avoid the [[QPR_ProcessAnalyzer_Chart#Visual_Settings\|Custom Layout settings]] (JSON) as their compatibility with future QPR ProcessAnalyzer releases might not be maintained in a stable way. Use the custom layout settings only when it's absolutely necessary to achieve the desired visualization.

	== Data visualization ==		== Data visualization ==
Line 13:		Line 12:
	* Note how the [[Measure, Dimension and Column Settings#Special values\|special values]], such as nulls and empty strings, are presented by setting descriptive labels for them. For example, when showing duration between events, cases which don't have the events which the duration is calculated from, are shown as nulls, and instead of an empty label, the label can be "Events missing" etc.		* Note how the [[Measure, Dimension and Column Settings#Special values\|special values]], such as nulls and empty strings, are presented by setting descriptive labels for them. For example, when showing duration between events, cases which don't have the events which the duration is calculated from, are shown as nulls, and instead of an empty label, the label can be "Events missing" etc.
	* Use the conditional formatting to improve KPI's visualization, especially in [[QPR_ProcessAnalyzer_Table#Conditional_formatting_examples\|tables]] where the bare numbers are slow to read. There are variety of visualization options, such as background color, databar and icons. Colors can be based on predefined traffic lights or continuous color scales.		* Use the conditional formatting to improve KPI's visualization, especially in [[QPR_ProcessAnalyzer_Table#Conditional_formatting_examples\|tables]] where the bare numbers are slow to read. There are variety of visualization options, such as background color, databar and icons. Colors can be based on predefined traffic lights or continuous color scales.
			* Avoid the [[QPR_ProcessAnalyzer_Chart#Visual_Settings\|Custom Layout settings]] (JSON) as their compatibility with future QPR ProcessAnalyzer releases might not be maintained in a stable way. Use the custom layout settings only when it's absolutely necessary to achieve the desired visualization.

	== Using filters ==		== Using filters ==

Ollvihe at 09:05, 31 March 2022

2022-03-31T09:05:09Z

Ollvihe at 00:28, 31 March 2022

2022-03-31T00:28:08Z

← Older revision		Revision as of 00:28, 31 March 2022
Line 20:		Line 20:

	== Performance optimization ==		== Performance optimization ==
	* For the ''Analyzed objects'' setting, prefer ''Cases'' ~~over~~ ''Events'', as calculating from events is slower than cases, ~~because usually~~ there are more events than cases. Some measures, even though calculated from the event data, can still be calculated from ~~cases~~. Also ''Variations'', ''Event types'' and ''Flows'' are generally fast~~. On the other hand~~, ''Flow Occurrences'' is slow, as there are even more flow occurrence objects than events.		* For the ''Analyzed objects'' setting, prefer ''Cases'' and ''Events'' only when required, as calculating from events is slower than cases, as there are more events than cases. Some measures, even though calculated from the event level data, can still be calculated from measures and dimensions available in ''Cases''. Also ''Variations'', ''Event types'' and ''Flows'' are generally fast, whereas ''Flow Occurrences'' is slow, as there are even more flow occurrence objects than events.
	* 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 [[Label and Link\|links]] created to navigate between them.		* The more there are charts in the dashboard, the more it takes to open the dashboard and all charts shown. This is because each chart performs a calculation which are all done at the same time in the server. If the dashboard opens slowly, charts could be divided into multiple dashboards and [[Label and Link\|links]] created to navigate between them.
	* Prefer ready-made measures and dimensions, and create custom only 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 formula in an inefficient way.		* Prefer ready-made measures and dimensions, and create custom only when there is 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 formula in an inefficient way.
	* ~~For some simple calculations,~~ the [[Measure, Dimension and Column Settings#Statistical calculations\|Statistical calculations]] can be used instead of need to write a custom expression. Also the [[Measure, Dimension and Column Settings#Advanced settings\|Adjustment expression]] is useful in avoiding a fully custom expressions in some occasions.		* Limit the number of returned rows by using the [[QPR_ProcessAnalyzer_Chart#Analyzed_Data\|Maximum Rows]] setting. The less there are rows, the better the performance as there is less data to calculate, less data to transfer, and less data to visualize. In many dashboards, limiting the amount of shown data also improves usability, as it avoids overflow of too detailed information.
	* Limit number of returned rows by using the [[QPR_ProcessAnalyzer_Chart#Analyzed_Data\|Maximum Rows]] setting. The less there are rows, the better performance as there is less data to calculate, transfer and visualize. In many dashboards, limiting the amount of shown data is also ~~desired for~~ usability, ~~e.g., show only the top-20 most important items~~.
	* ''Sorting'' the data affects performance, so use sorting only when it's relevant for the analysis.		* ''Sorting'' the data affects performance, so use sorting only when it's relevant for the analysis.
			* There are occasions when the [[Measure, Dimension and Column Settings#Statistical calculations\|Statistical calculations]] can be used instead of going to a custom expression. Also the [[Measure, Dimension and Column Settings#Advanced settings\|Adjustment expression]] may be useful in avoiding a custom expressions in some KPI's.
	* ''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.		* ''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.
	* ~~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.		* [[QPR_ProcessAnalyzer_Chart#Analyzed_Data\|Dimensioning]] is not needed, when there is a row for each analyzed object (case, event, etc.). 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, which will improve performance.

	== Advanced performance optimization ==		== Advanced performance optimization ==

Ollvihe at 00:16, 31 March 2022

2022-03-31T00:16:08Z

← Older revision		Revision as of 00:16, 31 March 2022
Line 1:		Line 1:
	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.		This article describes common best practices that should be followed when working with dashboards. Following these best practices make sure that dashboards are easy to maintain, respond quickly and are understandable and illustrative.

			== Usability ==
			* Use the [[QPR_ProcessAnalyzer_Chart#On-screen_Settings\|on-screen settings]] for settings that often users want to change, as they are easier to access than opening the settings dialog. They also guide users to variate and adjust parameters that are relevant for the analysis.
			* Limit the shown case and event attributes and event types, if there are some that are not used in the analysis. This will make the dropdown lists shorter making it easier for users to find the relevant selections. The shorter lists don't have performance impact, though.
			* Mappings from measures and dimensions to visualization, such as X- and Y-axis can be set freely, so dimensions don't always need to go to the X-axis and measures to the Y-axis. For some special analysis, it might be easier to use the table to first configure the desired measures and dimensions, and then switch to the desired graphical visualization (such as column, bar or line chart) and map the table columns to the chart.
			* Use presets as basis when creating charts. The presets 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 starting from a preset, and continue modifying the chart settings for your customized needs.
			* Avoid the [[QPR_ProcessAnalyzer_Chart#Visual_Settings\|Custom Layout json settings]] as their compatibility with future QPR ProcessAnalyzer releases might not be maintained in a stable way. Use the custom layout json only when it's absolutely necessary to achieve the desired visualization.

	== Visualization ==		== Visualization ==
	* ~~Define a custom title for the chart, if~~ the automatically generated title is not descriptive.		* If the automatically generated title is not descriptive enough, use a [[QPR_ProcessAnalyzer_Chart#Visual_Settings\|custom title]]. Also define custom labels for measures and dimensions if they describe the them better. The measure and dimension labels are shown in chart axes, tooltips and table headers. In many measures and dimensions, the automatically generated titles are suitable.
	* 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 process mining terms "cases" and "events" might be replaced with what they actually represent, such as orders, incidents etc.
	* 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 how the [[Measure, Dimension and Column Settings#Special values\|special values]], such as nulls and empty strings, are presented and set descriptive labels for them. For example, when showing duration between events, cases which don't have the events which the duration is calculated from, are shown as nulls. Instead of an empty label, the label can be "Events missing" etc.
	* Note ~~also~~ how the [[Measure, Dimension and Column Settings#Special values\|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 formatting to improve KPI visualization, especially in [[QPR_ProcessAnalyzer_Table#Conditional_formatting_examples\|tables]] where the pure numbers are slow to read. There are variety of visualization options, such as background color, data bar or icons. Colors can be based on predefined traffic lights or continuous color scales.
	* 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 [[QPR_ProcessAnalyzer_Chart#Visual_Settings\|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 ==		== Working with filters ==

Ollvihe: /* Advanced performance optimization */

2022-03-29T22:43:14Z

Advanced performance optimization

← Older revision		Revision as of 22:43, 29 March 2022
Line 31:		Line 31:

	== Advanced performance optimization ==		== Advanced performance optimization ==
	* For slow charts, use the [[QPR ProcessAnalyzer Chart#Benchmark performance\|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.		* For slow performing charts, use the [[QPR ProcessAnalyzer Chart#Benchmark performance\|Benchmark Performance]] to experiment which settings provide the best performance. Usually the first thing to do is setting up a working chart, and if the chart shows too slowly, with the benchmark performance you can try to find an alternative and faster way to calculate the same chart.
	* [[Calculated_Attributes_in_QPR_ProcessAnalyzer\|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.		* [[Calculated_Attributes_in_QPR_ProcessAnalyzer\|Calculated attributes]] can improve performance, as they can pre-calculate expressions already in the model loading. For example, event level information can be calculated to case level using calculated case attributes. Calculated attributes cannot be used when there is event type filtering applied, as the calculated attributes are calculated when the model is loaded and thus filtering doesn't affect them. Also, 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.		* Don't calculate anything from the entire model level in calculated attributes expressions, 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.		* Avoid calculating same expressions multiple times in different measures of the same chart. 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.		* When using custom expressions, and there are parts of the expression that give same result for all measures/dimensions, calculate that part separately in the [[QPR_ProcessAnalyzer_Chart#Working_with_custom_expressions\|Additional root expression]] and store the result to a variable. This way the calculation is done only once improving performance significantly. For example, if creating a measure that makes a comparison to the entire model, such as percentage of the entire model data, the model level part should 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~~.		* Sampling the data improves performance significantly. The idea of sampling is to pick only a portion of the root objects for the dimension and measure calculation to improve performance. Still, in most charts sampling cannot be used, as it affects the analysis results, for example count of cases and events. See more of the [[QPR_ProcessAnalyzer_Chart#Analyzed_Data\|Analyzed objects sample size]] setting.
	* 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.		* 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 ==		== 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.		* 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.

← Older revision		Revision as of 09:05, 31 March 2022
Line 1:		Line 1:
	This article describes common best practices that should be followed when working with dashboards. Following these best practices make sure that dashboards are easy to maintain, respond quickly and are understandable and illustrative.		This article describes common best practices that should be followed when working with dashboards. Following these best practices make sure that dashboards are easy to maintain, respond quickly and are understandable and illustrative.

	== ~~Usability~~ ==		== Easiness of use ==
	* Use the [[QPR_ProcessAnalyzer_Chart#On-screen_Settings\|on-screen settings]] for settings that often users want to change, as they are easier to access than opening the settings dialog. They also guide users to variate and adjust parameters that are relevant for the analysis.		* Use the [[QPR_ProcessAnalyzer_Chart#On-screen_Settings\|on-screen settings]] for settings that often users want to change, as they are easier to access than opening the settings dialog. They also guide users to variate and adjust parameters that are relevant for the analysis.
	* Limit the shown case and event attributes and event types, if there are some that are not used in the analysis. This will make the dropdown lists shorter making it easier for users to find the relevant selections. The shorter lists don't have performance impact, though.		* Limit the shown case and event attributes and event types, if there are some that are not used in the analysis. This will make the dropdown lists shorter making it easier for users to find the relevant selections. The shorter lists don't have performance impact, though.
	* Mappings from measures and dimensions to visualization, such as X- and Y-axis can be set freely, so dimensions don't always need to go to the X-axis and measures to the Y-axis. For some special analysis, it might be easier to use the table to first configure the desired measures and dimensions, and then switch to the desired graphical visualization (such as column, bar or line chart) and map the table columns to the chart.		* Mappings from measures and dimensions to visualization, such as X- and Y-axis can be set freely, so dimensions don't always need to go to the X-axis and measures to the Y-axis. For some special analysis, it might be easier to use the table to first configure the desired measures and dimensions, and then switch to the desired graphical visualization (such as column, bar or line chart) and map the table columns to the chart.
	* Use presets as basis when creating charts. The presets 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 starting from a preset, and continue modifying the chart settings for your customized needs.		* Use presets as basis when creating charts. The presets 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 starting from a preset, and continue modifying the chart settings for your customized needs.
	* Avoid the [[QPR_ProcessAnalyzer_Chart#Visual_Settings\|Custom Layout ~~json~~ settings]] as their compatibility with future QPR ProcessAnalyzer releases might not be maintained in a stable way. Use the custom layout ~~json~~ only when it's absolutely necessary to achieve the desired visualization.		* Avoid the [[QPR_ProcessAnalyzer_Chart#Visual_Settings\|Custom Layout settings]] (JSON) as their compatibility with future QPR ProcessAnalyzer releases might not be maintained in a stable way. Use the custom layout settings only when it's absolutely necessary to achieve the desired visualization.

	== ~~Visualization~~ ==		== Data visualization ==
	* If the automatically generated title is not descriptive enough, use a [[QPR_ProcessAnalyzer_Chart#Visual_Settings\|custom title]]. Also define custom labels for measures and dimensions if they describe the them better. The measure and dimension labels are shown in chart axes, tooltips and table headers. In many measures and dimensions, the automatically generated titles are suitable.		* If the automatically generated title is not descriptive enough, use a [[QPR_ProcessAnalyzer_Chart#Visual_Settings\|custom title]]. Also define custom labels for measures and dimensions if they describe the them better. The measure and dimension labels are shown in chart axes, tooltips and table headers. In many measures and dimensions, the automatically generated titles are suitable.
	* Check that each measure and dimension has a descriptive unit. For example, the generic process mining terms "cases" and "events" might be replaced with what they actually represent, such as orders, incidents etc.		* Check that each measure and dimension has a descriptive unit. For example, the generic process mining terms "cases" and "events" might be replaced with what they actually represent, such as orders, incidents etc.
	* Note how the [[Measure, Dimension and Column Settings#Special values\|special values]], such as nulls and empty strings, are presented ~~and set~~ descriptive labels for them. For example, when showing duration between events, cases which don't have the events which the duration is calculated from, are shown as nulls~~. Instead~~ of an empty label, the label can be "Events missing" etc.		* Note how the [[Measure, Dimension and Column Settings#Special values\|special values]], such as nulls and empty strings, are presented by setting descriptive labels for them. For example, when showing duration between events, cases which don't have the events which the duration is calculated from, are shown as nulls, and instead of an empty label, the label can be "Events missing" etc.
	* Use conditional formatting to improve KPI visualization, especially in [[QPR_ProcessAnalyzer_Table#Conditional_formatting_examples\|tables]] where the ~~pure~~ numbers are slow to read. There are variety of visualization options, such as background color, ~~data bar or~~ icons. Colors can be based on predefined traffic lights or continuous color scales.		* Use the conditional formatting to improve KPI's visualization, especially in [[QPR_ProcessAnalyzer_Table#Conditional_formatting_examples\|tables]] where the bare numbers are slow to read. There are variety of visualization options, such as background color, databar and icons. Colors can be based on predefined traffic lights or continuous color scales.

	== ~~Working with~~ filters ==		== Using filters ==
	* Filters can be added both to the dashboard level (affecting all charts) and to individual ~~chart level~~. For filters that will be used by most ~~of the~~ charts, are usually best to set to the dashboard level. For those charts that don't use the common filters, the [[QPR ProcessAnalyzer Chart#Filtering Settings\|Chart Follows Dashboards Filters]] setting can be disabled. ~~Difference~~ between the dashboard and chart ~~level~~ filters, is that the dashboard ~~level~~ filters are all the time visible in the dashboard, and they can ~~also~~ be easily changed by users. From the performance viewpoint, it doesn't matter in which level the filters are defined.		* Filters can be added both to the dashboard level (affecting all charts) and to individual charts. For filters that will be used by most charts, are usually best to set to the dashboard level. For those charts that don't use the common filters, the [[QPR ProcessAnalyzer Chart#Filtering Settings\|Chart Follows Dashboards Filters]] setting can be disabled. Notable difference between the dashboard and chart filters is that the dashboard filters are all the time visible in the dashboard, and they can be easily changed by users. 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 object in the model. The dashboard anyways stores the filter rules, so saving the filter is not ~~necessary~~. The 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.		* Dashboard filter can either be an ''Unsaved filter'' or it can be saved as a separate filter object in the model. The dashboard anyways stores the filter rules, so saving the filter separately is not required. The difference is that the saved filter has a descriptive name which is visible below the model name. Also when the dashboard level filter rules are changed, the original filter can be restored by selecting the saved filter in the filters menu.
	* If no meaningful filters can be created from a chart, disable the [[QPR_ProcessAnalyzer_Chart#Filtering_Settings\|Create Filters from Chart]] setting. When filtering is disabled, the cursor indicates that there are no clickable items in the chart.		* If no meaningful filters can be created from a chart, disable the [[QPR_ProcessAnalyzer_Chart#Filtering_Settings\|Create Filters from Chart]] setting. When filtering is disabled, the cursor indicates that there are no clickable items in the chart, and users don't accidentally create filters that have no meaning in the analysis.

	== Performance optimization ==		== Performance optimization ==