[Controls] Do Not Load Dashboard Panels Until Control Selection is Made

[mykael22000]

Describe the feature:

When one or more fields in a dashboard control panel has a 'single selection' flag set, KIbana should not display visualizations containing data for multiple values for the field.

• This can be done by either suspending the visualizations on the dashboard (other than the control panel) until the user has selected a value for (all of) the field(s) with 'single select' set or by dynamically determining a valid set of default values for any single select fields.
• Even if the latter is done, the visualizations should still be suspended until the user hits 'apply update' (if that option is active), which gives them the opportunity to change the filters before requesting the visualization.

What's the Problem?

When a user launches a dashboard with a control panel, there is the potential for the dashboard to display 'garbage' data. This can occur when the data is gathered and reported in such a way that it is only statistically valid when displayed within a set of filters. For example, a 'sales percent by product' field that adds to 100 for each country. If the dashboard has been saved without a filter, then the initial visualizations on the dashboard will be showing data from multiple countries, which makes the percentage values nonsensical. For example, if, in Country 1 we sold 100 A and 100 B then the sales share by product are 50% and 50%, but in Country 2 we sold 900 A and only100 B, then the share by sales in country B are 90% and 10%. If you present all the data in one report you show 140 A and 60 B (out of 100), when the actual numbers for the overall display should be 84% and 16% (this is shown on a different dashboard from a different aggregation). In the real example there are hundreds of products.

There is also an adverse performance impact on the dashboard and the database from querying all of the data in the range, when the user only wants to see a small portion of it.

What is needed is the ability for a dashboard to suspend it's update for the visualization (i.e. don't 'go off to elastic search and query all available data for the selected time range and then graph it'). Only once the user has set their query up in the controls and pressed 'apply filters' should the dashboard send off its first data query and provide data to it's visualizations. Having the visualizations show 'no data' or 'make a query' until then would be better than having them show incorrect or nonsensical data.

Ideally it would be inferred from the presence of a control with 'single select' on the dashboard, but I could live with having to specify it (and identify the control visualization?) at the dashboard level.

Describe a specific use case for the feature:

Elastic search has an index containing sales information from several countries, split by country and product. Within the aggregated data for each product in each country is a calculated percentage of that products share of sales within that country. As the sales volumes in each country is different, it is not mathematically valid to simply add up the percentages from each country and present it as the overall sales percentage. You'd need to do a weighted sum to get the correct answer. The country percentage data is maintained as part of an ongoing aggregation process to, amongst other things, improve the performance of the dashboard presenting it.

We then create a Kibana dashboard with a control panel that lets me select a country and see a visualization that shows the breakdown of product sales by percentage within that country. I save the dashboard without any filters in place (different users are only allowed to see data from a different subset of countries, so there is no 'universal' default country that could be saved that everyone would be able to see and I'd sooner not code a default that could trigger security alerts).

The issue this feature would address is that when the dashboard is first launched, the user is presented with a graph in the visualization area that is made up from a mathematically invalid aggregation of the data for all of the countries they can access. If the user doesn't realize this and starts making business decisions on the basis of the invalid data Kibana is presenting, there may be significant negative impacts on the business. This make it, potentially, an expensive way for a customer to learn that they can't trust the data Kibana displays.

Implementing the feature would limit the dashboard to only displaying valid aggregations of data - sales percentage by product for a single country, which is data that they can trust. When one or more of the control panel filters has a single select setting, the visualizations should not display data from multiple values of the filtered field.

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[monfera]

True, not all data transformations that can be mechanically computed make sense. For example, if percentages or ratios are represented as numbers, multiple of them can be added together, which is nonsensical. A weighted average would indeed be needed, though what the weighting should be based on isn't always known to the system, if the information is present at all, and sometimes there are multiple weighting options that'd make sense.

We have at least one similar request though it's important that your issue is going into details about the motive.

Often, the system has insufficient information on what operations are sensible and what aren't. We're looking into where it'd be possible to add metadata, or preserve such information—for example, when Kibana builds the query, it has information on aggregation steps of its own making.

One current possibility is the use of underlying values directly, eg. the sums or counts on which ratios or averages are computed, in which case, downstream operators will behave robustly and do the right thing.

Even the most dedicated visual analytics systems suffer from the lack of metadata, for example, Tableau applies a SUM aggregation by default. Also, while the simpler cases are trivial to think about, constructing an airtight, robust type system even atop of well annotated data is a difficult problem, not to mention, on data with gaps, noise, erroneous values and sometimes less than clear meaning of the input. Also, a full solution would require automatic recovery of functional dependencies, key candidates, possible normal forms etc. and have them shown to the user for approval.

We're discussing ways of enriching or inferring metadata, and there are some related issues filed.

I'd be in favor of not showing anything until all single selection fields are reined in. There would be users whose problem in this case would be that they don't see anything. Reconciling it needs a feedback mechanism eg. a status display of what's still missing.

[mykael22000]

Yeah, regardless of the presentation technology, you need a way to tell it how to correctly look at the data.

Please remember the performance aspects when considering going back to the source data and re-aggregating it. My current design uses transforms running under elastic search to aggregate the data as it is collected specifically to avoid the need to re-aggregate the data every time someone displays it. This is primarily to give a prompt and responsive display, especially in scenarios where simply throwing hardware at the elastic search farm isn't an option. This is the sort of information that might be appearing on a 24x7 dashboard with frequent (10 second) refresh intervals (although maybe not for the sales breakdown numbers used in this example). The dashboard needs to be able to quickly and efficiently pull the data out, not lock the entire elastic search farm up.

I'll be happy with a cart with wheels that don't fall off. I don't need an over engineered Rolls Royce solution here to make a significant improvement in our user experience.

[nikola6789]

Hi Elastic team,

Any word/progress made on this? Can we somehow stop loading visualizations until some input controls is selected? Any known workaround(s) for Kibana 7.16.2? Thanks.

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[ThomThomson]

Hi @nikola6789, we're introducing a new Controls system in Kibana 8.3.0. This new system actually does delay dashboard loading until all controls are ready.

That means that this functionality will be possible in the future. We could implement it as follows:

• When an Options List Control is set to single select, show another checkbox require selection.
• If require selection is checked, a user in View mode will be unable to deselect a selected option.
• On dashboard load, if there is at least one Control with require selection which does not have a selection, do not load the dashboard, and show a message like Selection required.

I've estimated this as loe:week because there are some UX pieces to think through.

[nikola6789]

Hi @ThomThomson,

Thanks for answering so quickly, it sounds like that would be what we want to have.

I suppose this will apply only to the new Kibana. We are tied currently to specific Kibana version 7.16.2, are there any plans to create a feature patch or if you know some workarounds for this particular version until we upgrade to next new Kibana?

[ThomThomson]

We generally don't backport features to older versions of Kibana, so you would likely have to upgrade to get this new feature.

I am racking my brain, but can't think of a good workaround for this for the time being.

[robcowart]

I would add to this that when single select is enabled, it should also be possible to define a default value. This is something that other tools, e.g. Chronograf allows (see screenshot). If a default value is provided the dashboard will be able to load immediately, but the single select value will be the default value.

Additionally, if navigating to the dashboard a pinned (i.e. global) filter is set on the same field that is used by the input control, the single select value should be the value from the pinned filter. This would also mean that this issue is related to https://github.com/elastic/kibana/issues/101040 and https://github.com/elastic/kibana/issues/136650.

[ThomThomson]

Hey @robcowart! While we don't yet have the ability to set a control value on navigation, we do have the ability to set a default selection which is loaded on each dashboard load. This works with the new Controls for both single-select and multi-select controls.

1. Start editing a dashboard with a control
2. Make a selection on that control. The Unsaved Changes badge should appear.
3. Click Save. Now the selection for that Control is saved into the dashboard, and any time the dashboard loads, that selection will automatically filter the data.

[robcowart]

Thanks for that @ThomThomson . We are currently going through some of the latest changes for an update to the ElastiFlow dashboards. We will check this out as well.

[jack-morrison]

My organization would also greatly benefit from the idea of requiring selections before populating a dashboard. I find myself telling end-users / writing markdown instructions to say "what you're seeing isn't valid if ___ doesn't have a selection!"

To further this, it would be great if I could build a dashboard where a multi-select Control must have N selections.