Incubator-superset: Choose dimension to split with at the dashboard level

Created on 30 Nov 2017  路  9Comments  路  Source: apache/incubator-superset

We are in a situation where we want to split the exact same dashboard with a different dimension depending on what we're testing.
Right now the only solution we've found is to duplicate every slice in the dashboard, change the dimension we use to split data for every single slice, and recreate a new dashboard with all these new slices.
It is very time consuming, and it is quite hard to keep all these dashboard up-to-date as we add metrics in a slice and so on.

It would really save us a lot of time if we could have a single dashboard and choose which dimension(s) we split the data on at the dashboard level.
A way to acheive this would be to add an (optional) "split" field in the filter slice, in which we could specify which dimensions we want to split data on for all the slices in the dashboard

inactive

Most helpful comment

Great feedback. A few other notes:

  • loading different dimensions could be parallelized on the backend to make things faster
  • cascading filters (where the list of values is based on a previously selected filter) are great for hierarchies (think: continent->country-> city). Currently it's doable only by having multiple FilterBox slices where one refreshes based on the other, but not the other way around (you can make the first filterbox immune to filtering). It's pretty common for BI tools to know about hierarchies and we could add support for that in our semantic layer and cascade things accordingly based on that.

All 9 comments

There are a few challenges around this but it's on the roadmap. While the "Filter Box" slice type is useful, it's pretty limited in what it can do and I've been thinking it needs to be re-written in a more generic way. Currently for instance it does not allow for per-dimension-configuration (all dims are based off the same metric for instance and sorted based on the same rule).

We need a more generic "dashboard controller" dashboard section or viz type. Folks at Airbnb are re-designing the whole dashboard app so that it can have nested "scoped" sections, tabs, filters that apply only to sub sections, ... Many of these dashboard components shouldn't be modeled as a visualization types but instead as dashboard primitives.

Note that dashboard-level controls are in scope I think, meaning bringing a "GroupBy" control (or any other control) to a dashboard section can affect many charts.

One challenge specific to this is the fact that controls are pretty heterogenous across viz types and we may need metadata that binds some of the most similar and comonly used controls.

@williaster can you share your mocks?

I believe Eli is working on the mocks, will post or get him to once they're done (likely next week)

@mistercrunch will share as soon as we have something worked up next week.

Awesome, glad to hear this is in the works! Would definitely appreciate if you can share the mockups once you have a first version to show

Great to hear it's on the roadmap indeed! The "scoped" dashboard section would be a dream come true to be honest. Here is a list of the limitations we tend to bump into on top of the "dimension split on the dashboard level" if that helps you in any way with the design:

  • Mixing various data sources in one dashboard is doable but difficult since Filter Box will apply to all slice (so if the filtered dimension is not in one of the datasource, those slices won't display any data)
  • We have a few sets of filters that we want to apply to a group of slices only, which atm forces us to reload the entire dashboard when we use the Filter Box (which can be pretty heavy if you don't take precautions)
  • The per-dimensions-configuration would indeed be a nice addition
  • We have ~15 dimensions on which we regularly apply filters so we had to break the Filter Box in smaller ones to allow for fast load of the Filter Box itself (the first filter box only contains the time filtering and our main dimension, the second ones contains more advanced dimensions, and a third only contains dimensions that are rarely used). This is working fine but require a bit of juggling with Apply button and FilterBox Force Refresh Button.

Don't hesitate to ask for more details if you need. Thank you!

Great feedback. A few other notes:

  • loading different dimensions could be parallelized on the backend to make things faster
  • cascading filters (where the list of values is based on a previously selected filter) are great for hierarchies (think: continent->country-> city). Currently it's doable only by having multiple FilterBox slices where one refreshes based on the other, but not the other way around (you can make the first filterbox immune to filtering). It's pretty common for BI tools to know about hierarchies and we could add support for that in our semantic layer and cascade things accordingly based on that.

Is this feature still being developed? It seems a long time since the last update.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Hello, is there any news around this ?

Was this page helpful?
0 / 5 - 0 ratings