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.
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?
2 Likes
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?
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 
1 Like
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.
7 Likes
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).
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 !
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?
1 Like
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.
1 Like
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.
2 Likes
Q: are there any instructions / how-to on how one writes UI nodes? Is it all "learn by example"?
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.
1 Like
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.
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...).
1 Like
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.
7 Likes
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.
4 Likes
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.
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 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. . . .
3 Likes
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.
1 Like
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 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.
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):- I see in my Twitter feeds that a nice new UI node has been developed.
- I have a look at flows.nodered.org what it is all about. Yes I need to have it ...
- I install the UI node via the "Manage Palette" menu in my flow editor.
- I drag the UI node in my flow.
- I double click it and change some properties in its config page.
- I have a look at the node's info panel in the sidebar, when something is not clear to me.
- I hit the "dashboard layout manager" button and the (third party) layout manager opens. While opening the manager, all the installed UI nodes and the properties of all UI node instances are passed to the layout manager.
- In the layout manager you can change properties of existing UI nodes, remove existing UI nodes, or create new UI nodes (based on the set of installed UI nodes). But here you are working with the UI node's widget counterpart.
- When you leave the layout manager all node instances (and their properties) are returned to the flow editor and updated in the flows.
- Now I can start adding wires to my new UI node instances.
- I hit the "Deploy" button and my updated dashboard is up and running.
That way would be perfect for me: I can use UI nodes in Node-RED exactly the same as non-UI nodes, and I can also enjoy the power of a full blown existing third-party layout manager.
I have absolutely no idea if there is a layout manager available that allows such level of integration. And I am also aware that this might need to require new functionality (in the core?): e.g. in step 9 the flow editor has no idea where to add newly added UI nodes (in which flow tabsheet or at which location). So something new is required, like e.g. a visual backpack or something else where such "draft" nodes are being stored until you drag and drop them in a flow.
And perhaps there are other disadvantages that I have not thought about, which redirects my proposal directly to the garbage bin ...
But such a setup would make life easier for me as node developer: all things that I have learned from my non-UI node developments, I can reuse for UI node developments. For example I know how to create a complex node config screen. I could easily keep doing that: my new ui-svg node could have a complex config screen in Node-RED, while it has a very simple properties screen in the third party layout manager. That way I don't have to start studying again how I have to create complex property screens in the layout manager. I hope that makes sense somehow?
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 ...
4 Likes
