# Discussion about a new Dashboard

**URL:** <https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119>\
**Category:** Dashboard\
**Created:** [16 September 2021 18:31 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119 "2021-09-16T18:31:02Z")\
**Posts on this page:** 20\
**Page:** 5

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [24 September 2021 15:33 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/82 "2021-09-24T15:33:32Z")

</div>

> [@dceejay](#):
>
> Not sure what you mean re packaging

My initial question was about why people find it so important that they can drag UI nodes into the flow, as opposed to, say, instantiating widgets in the dashboard directly. What Bart pointed out is that if getting new widgets requires a new community repository and a new install process then that's a bad idea. Or put differently, the fact that one can get new community UI nodes the same way one gets new non-UI NR nodes is an important plus.

---

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [24 September 2021 16:07 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/83 "2021-09-24T16:07:16Z")

</div>

> [@tve](#):
>
> My initial question was about why people find it so important that they can drag UI nodes into the flow, as opposed to, say, instantiating widgets in the dashboard directly.

If I instantiate a widget in the dashboard, do I then have to go back to the editor to wire it up?

Node-Red has a drag and drop user interface.  
Once I've explained that to my elderly neighbor or grandson, I don't want to have to explain "Ah but not for dashboard widgets. You have to go somewhere else and 'instantiate' them."

How does one install new widget types with FlexDash?

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [24 September 2021 16:12 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/84 "2021-09-24T16:12:05Z")

</div>

> [@jbudd](#):
>
> Node-Red has a drag and drop user interface.  
> Once I've explained that to my elderly neighbor or grandson, I don't want to have to explain "Ah but not for dashboard widgets. You have to go somewhere else and 'instantiate' them."

I'm not really understanding why it's not more natural to do the same drag and drop into the dashboard. E.g., in NR you drag and drop functional stuff. In the dashboard you drag and drop UI stuff. Then you hook them together.

The fact that you drag something into the NR editor and then it shows up elsewhere can also be described as really weird. Also, why do I have to go to a property pane and click around and the redeploy to resize a widget shown in the dashboard as opposed to just dragging the widget's corner the way I resize just about anything in just about any app on my desktop?

---

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [24 September 2021 16:15 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/85 "2021-09-24T16:15:33Z")

</div>

> [@tve](#):
>
> Also, why do I have to go to a property pane and click around and the redeploy to resize a widget shown in the dashboard as opposed to just dragging the widget's corner the way I resize just about anything in just about any app on my desktop?

Absolutely right. the ability to resize and move stuff around on the dashboard which FlexDash offers is a big bonus. It must be restricted to certain users though, which implies multi-user functionality.

Edit- dammit I thought I'd removed "functionality" from my dictionary. Seems my fingers still remember it 😁

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [24 September 2021 16:17 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/86 "2021-09-24T16:17:58Z")

</div>

I'm with you on the layout side - would make sense to have layout control and ui properties much more WYSIWYG... but what about admin/authentication.... it must be able to be locked/disabled (from the workflow editor side) so that once laid out beautifully by the app developer then end end users can't mess with the widgets/layout.

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [24 September 2021 16:24 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/87 "2021-09-24T16:24:37Z")

</div>

Q: any chance we could get a 'new dashboard' or 'alternate dashboard' tag? (I assume a category is not warranted at this point?) This discussion is in the dashboard category. Julian just created a new thread about getting started with uibuilder in the Share your Nodes category. The FlexDash stuff got moved to Share your Projects a few months back. uibuilder has a tag, others don't (I get why).

---

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [24 September 2021 16:25 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/88 "2021-09-24T16:25:28Z")

</div>

> [@tve](#):
>
> The fact that you drag something into the NR editor and then it shows up elsewhere can also be described as really weird.

There is a button in the editor to open the dashboard but it's far from prominent. And when you click on it it does not necessarily open the tab on which you have just created your widgets. Personally I always type the URL. At least /ui is a bit less cryptic than :1880 !

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [24 September 2021 16:38 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/89 "2021-09-24T16:38:39Z")

</div>

> [@dceejay](#):
>
> it must be able to be locked/disabled (from the workflow editor side) so that once laid out beautifully by the app developer then end end users can't mess with the widgets/layout.

In my view, it should be attached to the same ExpressJS app as the Node-RED Editor and so controlled by the Node-RED admin logins. Not by users of the resulting UI.

Personally I don't see a problem with having a layout page that is separate to both the Node-RED Editor and the resulting UI page.

However, I can see that doing a UI in an editor and then having to link the parts of the UI back to Node-RED nodes _would_ be problematic.

An extension of the current Dashboard capabilities would seem sensible:

- Install the appropriate node that contains a component.
- Add an instance of that node to the flow. Which automatically adds the component to the UI editor page.
- Use the UI editor for layout only, don't let new components be added from that page. Maybe you could allow deletion though.

That mirrors what happens now, its just that the UI layout page becomes a full page rather than just a panel?

I guess it _might_ be possible to add something to the UI layout page that would auto-create nodes in a flow, but where would they be positioned?

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [24 September 2021 16:58 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/90 "2021-09-24T16:58:28Z")

</div>

> [@TotallyInformation](#):
>
> I guess it _might_ be possible to add something to the UI layout page that would auto-create nodes in a flow, but where would they be positioned?

How is this different from the way things are now? You add a UI node to NR, where would it be positioned in the dashboard? (My experience: where I don't want it.)

I'm not suggesting this is the way to do things, but I did find it interesting to think about. E.g. in what you're suggesting in your extension to the current dashboard, the dashboard would need a holding place for UI nodes that need to exist but haven't been placed. The converse could work just as well: the NR editor could have a holding place for nodes that need to exist but haven't been placed.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [24 September 2021 17:06 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/91 "2021-09-24T17:06:11Z")

</div>

> [@tve](#):
>
> How is this different from the way things are now? You add a UI node to NR, where would it be positioned in the dashboard? (My experience: where I don't want it.)

It is the exact opposite. It would be like being able to add a new widget via the Dashboard panel's layout tab and you cannot currently do that.

What I'm saying, as I think other people are, that to have to add things in two steps would not be a good idea. Flow editors need to be able to add widgets in 1 step and I see the logic of wanting to do that in the flow because that's where all of their flow is happening. They need to have something to anchor the data flow into and that needs to be a node in the flow.

One of the ideas I'm looking into with uibuilder is whether you can have a generic node that links to installed web components and into the URL that defines a uibuilder instance.

That way, the packaging of components could remain as with any other front-end code (though maybe with some standard extension data for linking to uibuilder that would be ignored if using the component elsewhere). The metadata in the component would allow uibuilder to recognise it as complient and add it to the loaded catalogue of web components. The sender node would use the catalogue and you could select the appropriate entry.

The main difficulty of this approach would be how to provide a simple configuration editor so that general component configuration can be done easily given that each component would need different configuration settings.

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [24 September 2021 17:39 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/92 "2021-09-24T17:39:14Z")

</div>

Q: are there any instructions / how-to on how one writes UI nodes? Is it all "learn by example"?

---

<div class="post-metadata">

**Author:** ![i8beef](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/i8beef/32/3161_2.png) [@i8beef](https://discourse.nodered.org/u/i8beef)\
**Post date:** [24 September 2021 18:21 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/93 "2021-09-24T18:21:38Z")

</div>

> whole debate over being able to create a UI widget in the NR editor. I'm trying to understand why a lot of folks are so insistent on that.

Because that is the node-red message routing paradigm, and a "node-per-widget" is essentially following that in a way that aligns to route inputs / outputs from individual widgets. Any GENERAL USE dashboard approach (IMHO) should not break from this message routing approach.

If you're going to break from that model, you might as well just define a general use input / output contract with a single websocket endpoint handling communication, and then build the entire UI separately and handle all message routing, etc. manually (UI Builder I believe?).

Those are two different use cases requiring different skill potentials.. and I'd argue the second one is not a general use option.

There IS a third case: Take this out of node-red. I don't know if you could do that completely with UI Builder already as the communication foundation and then create a separate "dashboard ui builder" application... There's something nice about having options there (i.e., 5 different people could build different UI apps that just have an interface to node-red's message flows and you choose whichever one looks good to you). It just would give you a nice line in the sand between UI and node-red which will allow you to decouple auth, framework decisions, executing thread / host, and any number of other things.

Its just obviously a massive amount of work to stand up a whole new application base, and isn't really a "general use" option like node-red-dashboard currently fits... its more the case that UI Builder fits.

---

<div class="post-metadata">

**Author:** ![kreene1987](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kreene1987/32/32260_2.png) [@kreene1987](https://discourse.nodered.org/u/kreene1987)\
**Post date:** [24 September 2021 18:22 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/94 "2021-09-24T18:22:18Z")

</div>

This may sound insane but also might trigger some thought. Has anyone reached out over to the great guys at Home Assistant to see if further/tighter integration might be possible? Right now all of my inputs/outputs/modifications are being done in HA, but the logic is being done in HA.

It works flawlessly and I really enjoy the interface on both. Perhaps this could become a "recommended dashboard" or something like that.

---

<div class="post-metadata">

**Author:** ![i8beef](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/i8beef/32/3161_2.png) [@i8beef](https://discourse.nodered.org/u/i8beef)\
**Post date:** [24 September 2021 18:29 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/95 "2021-09-24T18:29:55Z")

</div>

> but what about admin/authentication

Does the node-red auth system not support role-based or claim-based authorization that we could use? There isn't a user friendly way to EDIT those users / roles right now, but I've always kinda thought that was an area node-red would eventually have to add anyway... maybe an argument for evaluating an overhaul of the auth system (Being able to more granularly lock down endpoints would be fantastic anyway, instead of proxying and adding per-endpoint auth in the proxy...).

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [24 September 2021 19:25 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/96 "2021-09-24T19:25:03Z")

</div>

> [@kreene1987](#):
>
> Has anyone reached out over to the great guys at Home Assistant to see if further/tighter integration might be possible?

HA is very popular, so a combination makes a lot of sense. That being said, there are many use-cases for NR where HA doesn't make sense, and there are people that don't want to have HA anywhere nearby (I'm one of them... 🤪). I don't think that HA as a default dashboard for NR makes sense.

---

<div class="post-metadata">

**Author:** ![johanon](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/johanon/32/3335_2.png) [@johanon](https://discourse.nodered.org/u/johanon)\
**Post date:** [24 September 2021 20:35 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/97 "2021-09-24T20:35:12Z")

</div>

Our digital world is built up of algorithms with information flowing through it. Usually hidden inside a magic box no one in the neighbourhood understands. Very much unlike a mechanical machine that any one interested enough can open up and investigate. I love NR because it gives me a feeling of actually opening that magic box. With the editor I can touch the algorithm and with the dashboard I get to interact with the information living inside. Absolutely fantastic!

My point, the dashboard is as important as the editor. Algorithms are nothing without the information flow.

I would prefer something close to the core even in its simplest form.

---

<div class="post-metadata">

**Author:** ![Gunner](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gunner/32/43582_2.png) [@Gunner](https://discourse.nodered.org/u/Gunner)\
**Post date:** [24 September 2021 21:03 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/98 "2021-09-24T21:03:34Z")

</div>

> [@tve](#):
>
> The whole thing requiring me to redeploy a hundred times and switch between the NR tab and the dashboard an equal number of times.

I use multi-monitors to allow me to do that same thing in the low dozens of times 🤣

But seriously, I like the drop a `ui_node` in the edit/logic aspect, as I can tell at a glance (or three) how my logic progresses to the appropriate UI point. I am a visual thinker that way.

That said, if a Dashboard had both the node-per-widget in the editor and the authorized editors option (a toggle in the editor?) for WYSIWYG adjustment in the Dashboard, I wouldn't complain 😉 The current layout method is clunky, but works for now.

---

<div class="post-metadata">

**Author:** ![meeki007](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/meeki007/32/12499_2.png) [@meeki007](https://discourse.nodered.org/u/meeki007)\
**Post date:** [24 September 2021 23:56 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/99 "2021-09-24T23:56:28Z")

</div>

My opinions on multi user support in the Dashboard.

I have talked about (with dceejay) and worked on solutions to this issue with the current dashboard.  
I even was close to finishing a solution of sorts ---\> [add support for ui: {disableFeedbackToAllSessions: true} by meeki007 · Pull Request #721 · node-red/node-red-dashboard · GitHub](https://github.com/node-red/node-red-dashboard/pull/721) with dceejay guiding me and giving me direction and ideas.

I had a shift in my thought. The basic Dashboard what ever one we as a community decide to use/support should not have the complexity and maintenance of multi user support. Sure it can be a widget add on but not part of the base. A dashboard needs to mimic node-red and be intuitive for a early user. One node-red instance to one node-red user.

Also dceejay is real awesome at herding us 'cats' and culturing and supporting ideas and work even if it ends up being a dead end and is not merged/added

I'm sure what ever direction this ends up going in **it would be far better for all of us as a comunity** to have his time spent as the project manager of this and not writing the whole thing himself.

When a direction to go in is decided I'll be happy to submit pull requests and start supporting what ever is.

Standing by for a consensus. . . .

---

<div class="post-metadata">

**Author:** ![wb666greene](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/wb666greene/32/6534_2.png) [@wb666greene](https://discourse.nodered.org/u/wb666greene)\
**Post date:** [25 September 2021 00:20 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/100 "2021-09-25T00:20:30Z")

</div>

> [@tve](#):
>
> Is it all "learn by example"?

IMHO learn by example is by far the best "documentation". If you don't believe me, take a look at the OpenCV extensive documentation (exceptional in depth and thoroughness) and try to accomplish anything without first finding an example (Open CV also has excellent tutorial examples). Once you "know" OpenCV the documentation quickly tells you the details you need, but when starting from "zero" it is pretty much worthless.

---

<div class="post-metadata">

**Author:** ![BartButenaers](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bartbutenaers/32/10476_2.png) [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)\
**Post date:** [25 September 2021 05:37 UTC](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/101 "2021-09-25T05:37:09Z")

</div>

> [@meeki007](#):
>
> I had a shift in my thought. The basic Dashboard what ever one we as a community decide to use/support should not have the complexity and maintenance of multi user support

Ok not sure whether my usage would be multi-user or not to be honest. We had a very interesting discussion about having 'affordable' [touch screen](https://discourse.nodered.org/t/wall-mounted-node-red-touch-screen-device-request-for-ideas-and-volunteers/51136) devices in the rooms of a house, where a Node-RED dashboard is being displayed. And each room needs to display another Node-RED dashboard: e.g. in the entrance hall you want to display a dashboard with an alarm keypad, in the bathroom you want to show temperature/humidity, and so on... To summarize: wall mount Amazon Fire 7 tablets which display a dashboard running on a central Raspberry, because such devices have not enough system resources to run Node-RED locally. _But it would be very pity if I had to install N Node-RED instances, to host N different dashboards._

Such typical home automation situations should be easy to implement using a single Node-RED instance IMHO ...

But perhaps you guys have already other solutions in mind for this.

> [@tve](#):
>
> which has a different set of benefits, such as being able to deal with the layout stuff easily and being able to create arrays of widgets programmatically.

Yes indeed that is something that is not easy to solve in the current model. Entirely correct. Going to ask some (perhaps stupid) questions to understand it a bit better:

- When you say "_ **programmatically** _" then you mean a code snippet in the layout manager, or something else? I have not needed something like that yet, but I can imagine that some folks program this kind of stuff in a UI template node currently? Or do you mean that it is currently (in a template node) only possible for basic widgets (e.g. md-button) and that you can e.g. not add N instances of my node-red-contrib-ui-svg node on a screen programmatically, to show the floorplans of N floors in my house?

- When you say "_ **layout stuff** _" do you mean an easy way to specify css styles, or an out-of-the-box available layout manager? Because I can indeed understand that you want to use an existing layout manager, to avoid reinventing hot water. It is not a secret anymore that I like the current model, so I am going to give it yet another try 🙄. @Steve-Mcl integrated some time ago a third party SVG editor inside our node-red-contrib-ui-svg node, because we didn't want to spend the remaining of our miserable lives to develop a graphical SVG drawing editor ourselves. So we _ **integrated** _ an existing SVG editor (DrawSvg) in our node. Isn't something like that possible perhaps. That you can access the third-party layout manager easily from the flow editor, and the layout manager shows and manages the UI nodes in Node-RED. I mean _ **dual way** _ (like we do with DrawSvg):

This was most probably my last attempt to keep having my belovely UI node concept in Node-RED. It is something I really like... Absolutely not because "_I got used to it_", but because it was one of my main reasons why I choose Node-RED at the time being. And I still like the concept, to have all my stuff in the same Node-RED way...

But if the developers of the new dashboard have another opinion about that, then I will rest my case from here on ...

[Previous page](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119.md?page=4)

[Next page](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119.md?page=6)