Discussion about a new Dashboard – #106 by Paul-Reed – Dashboard

I spent a bit of time looking at the current dashboard code and trying to decompose the functionality of a dashboard. The parts that I come up with are:

• overall layout of tabs, groups, widgets
• placement of each widget
• visual representation of each widget (color, size, font, …)
• functional settings for each widget (send on change, min/max settings, …)
• NR editor representation of each widget (“UI node”)
• data cache to populate new dashboard instances
• data structure (registry) representing the dashboard configuration
• data pipes representing the connections to the dashboard instances

As I go down the list, I’d like the overall layout, placement, and visual representation to be managed in the dashboard itself. For two reasons. First because that’s where it can be changed interactively with immediate feedback. Second because different dashboard implementations could do it very differently and allow for very different looks&feel.

Skipping the “functional settings”, the next set of functions (UI node and data cache) belong in NR for sure. They’re relatively independent of the front-end dashboard. Maybe there are some parameters on how the data cache functions that are front-end dependent, but I’m not sure that’s really necessary.

The functional settings for each widget are a bit of a mixed bag. Some things clearly belong to the NR flow and should be managed there, for example whether you want the widget to output changes. That really depends on whether you’re wiring up the UI node’s output or not and it not something that should be tweaked interactively in the dashboard.

But there’s quite a grey zone. For example, the min/max range of a chart. Is that a functional element (min/max of the data being sent) or is that visual element (how the chart looks)? And thus should it be something set in a UI node property sheet or should it be something adjusted live in the dashboard?

Perhaps a different way to think about it is whether the same UI node configured the same way could have its data represented in different ways. For min/max that’s certainly the case: it’s easy to imagine two charts with different min/max settings. A different case might be the label for each chart series. It really is an attribute of the data and not of the looks. Thus it should be set in NR. (There a grey zone, one might want a short or a long version, or different languages, …)

The second-last item on my list is the data structure representing the dashboard configuration. That has to be stored in NR but is really shared between NR and the dashboard. That means it needs to have a well-defined API to add/remove/modify its elements.

What I’m wondering now is whether there’s an opportunity to create a front-end independent layer in NR onto which multiple dashboard implementations can be layered. Basically this would take the existing UI nodes and some of the machinery, but remove all the “visual” stuff. Then it would need a well-defined interface to hook up to the data structure representing the dashboard config and to the pipe connecting the clients. For the latter, the common layer could provide auth/access-ctrl support.

I believe that such a common layer could preserve a lot of the current dashboard’s functionality, while opening up possibilities for having very different front-ends.