This would provide the ability to dynamically show or hide any dashboard block based on the value of a context variable (or query parameter/attribute value).
Some questions here …
- Why, specifically, do you want to hide certain dashboard blocks based on dashboard context values? Is there sensitive information within blocks that you do not want to share with certain users?
- How would the dashboard layout change if a block in the middle is hidden? Is there just a hole where the block used to be? Does everything collapse into place as best as it can figure without human intervention? Is it up to the dashboard editor to manage these layouts manually?
Maybe if you can provide a little more information about your use case, we can come up with a solution or write up your request as a broader feature.
The use case for us is based on the fact that we have many customers that have differences that can be accomodated by different configurations of the contorl system. Let’s say that our device can accomodate up to 30 different types of sensor readings, but some applications may only be using 12 because some of the sensors don’t make sense for thier particular use case. For example, lets say its an engine. Some engines might be connected to generator which involves some sensor data realted to AC voltage, current, frequency. That AC data makes no sense to someone using an engine in a pumping application but the basic sensor data does make sense. For this person, we would disable the AC gauges and simply not show them.
What I envision is a more dynamic dashboard that prevents creating too many duplicates of dashboards with variations. Right now, we could make new dashboards for each customer but that creates an administrative burden.
The layout is somewhat of a delimma. There are two approaches I can think of. The first would involve creating sections and grouping things together so you can hide a group of gauges without it looking like something is missing. The second would be some kind of auto layout based on a criteria similar to what content management systems like Drupal would use. You could assign a “weight” to each gauge and change what order the gauge displays if its present.
In essence, any method that can prevent creating many duplicates with small variations, that would solve the problem. Perhaps some kind of object oriented approach might be helpful, where a base dashboard is specified and variations of the base could be specified quickly and easily and tied user or group tags? Just thinking out loud here.
I’m wondering if you’ve advanced your thinking on this topic? I keep coming back to this as I deploy more devices.
I’m thinking this kind of dynamic behavior mimics a lot of industrial UIs already, where the device IO configurations determine the screen elements that are shown. So I’d be surprised if it’s not a common IoT dilemma.
We don’t have any short-term plans to show or hide blocks based on context values.
Something we’ve kicked around internally - and we’re not sure we’ll do this and if we do we don’t have a timeline for its implementation - is the idea of building “graphs” or “visuals” more as a resource owned by an application and allowing dashboards to reference these visuals.
So, instead of configuring the same block in 25 different dashboards, you would configure the block once and in your 25 dashboards, you reference that block and give it a custom width, height and x/y position for that particular layout.
Does that make sense? And would something like that solve your use case?
Sorry, I’m not sure I grasped what you were describing. Let’s say we are talking about dial gauges for example, are you suggesting that concept of a “visual” would be a cluster of gauges that would build once, and the whole cluster would be configured from a dashboard?
Another use case. I would like to support an experience / dashboard which provides a BASIC and ADVANCED display. Use a context variable to indicate BASIC or ADVANCED. Only include the ADVANCED blocks when indicated by the context variable. Of course this could be done with two different dashboards, but will involve a lot of duplication and ongoing sync between the BASIC and ADVANCED dashboards (a sw dev anti-pattern).