I'm not against of base widgets. The question is rather "how much can the one man carry". Current situation is not unique. In computers world things go old very fast. And that takes to be at the position to make your move at the right time. The less you have to maintain, the easier it will be.
To draw the line somewhere is hard decision. Must be made wisely.
2 Likes
Not only for the developers of the ui nodes, also for all of us who have used them designing dashboards, this will be a pain. I assume no migration tool will be provided? What will still survive is my old implementation in pure html/javascript code
The mentioning of multi-user is very important, also don't miss out multi-tenant if those parts can be satisfied just with a new dashboard design. But I thought both those requirements would also involve necessary surgery of the server part as well??
1 Like
Indeed some decisions may affect the core (or want to) - which is also why we want to discuss them now, so we can get any necessary hooks in place.
At risk of repeating myself - I have no intention of dropping/withdrawing the current dashboard - just that it will become "unsupported" in the more formal sense of the word. So no-one has to move if they don't want to - like there are still users of Windows7 and XP behind closed doors...
(of course the more time I have to spend doing this - the less I can help with any new efforts)
8 Likes
The biggest failing in the current dashboard in my humble opinion is not being able to add components on the fly, e.g say i have data for 20 lights, i would have to add them all manually. I would like to see the ability to feed a array/object in to a dashboard switch and it produce the 20 switches on the fly. So when adding new switchs all that is required is updating the array. same for gauges button charts etc.
This can be done in the current ui-template, but this is beyond novice users abilities.
So the idea would be a selectable list of components that can be styled and told which part of the object they should use.
1 Like
Agree that we don't give Dave anywhere near enough praise for supporting and developing this complex but immensly useful tool - thanks Dave! While I don't use it much now, I really do appreciate the work that went into it and still goes into it, it is a vital component that makes Node-RED successful.
I totally agree with that and uibuilder was only ever meant either for people prepared to code or as a base to build on. I think we all recognise the need for Node-RED's low-code back-end approach to be matched with a low-code front-end tool.
I fear we must agree to disagree there. I had already used and discarded Angular by the time UI came along. It is OK for big, complex developments with a dedicated development team but not terribly useful elsewhere. I think this has been demonstrated by the market moving on to other frameworks.
Nice of you to say so. And I would be more than happy to give up bits or all of uibuilder if it helps the community. Or hand over to the core and be a contributer or work with others to build something new.
As I've said many times. I see uibuilder as a core for building ui's - it lets people code directly using tools they are familiar with, and it is capable of becoming a building block for more advanced (simpler to use) layers. But it certainly isn't the only approach and might not be the best either, not for me to say. But as it now stands, it is quite modular (and getting better in each release), and very flexible.
But even if used, it would only be a small part of the answer for Node-RED. As Nick and Dave have said, there are requirements that need to be met such as the low/no-code layout builder and standards around comms. Also, I'm far from happy with the work I've done on the security part of uibuilder. It would certainly need some work to be better integrated to Node-RED.
The whole area of widgets and uibuilder has been discussed before and is certainly doable as I've demonstrated with some simple examples. Really any modern front-end framework will be able to deal with this issue as they all support components. The hard part is that the way frameworks (and HTML itself) support components is not the way that the UI components were architected. And therefore any approach that moves to modern component management is going to mean some pain in migrating the current ones to a future solution. I have previously tried to lay out ideas for how this might work in a way that continues to leverage commonly used web design patterns and minimises the comms traffic between NR and the front-end.
It is absolutely certain that components/widgets must be creatable by the community. And they must be as easy to install and use as any Node-RED node.
Which is why I am trying to get people to think about using web standards as far as possible. Use what others have already tried and that is already in wide usage so that we try to avoid ending up back in a similar situation in the future.
Good point. And sorry to sound like a broken record, but this is exactly the kind of benefit that would happen automatically if using a more standard approach to defining components - which is to say leveraging the existing wealth and maturity of web development. Separating out the bulk of the component design/build from the internals of Node-RED.
Doesn't mean that you can't use Node-RED to help. Nor does it mean that you can't have Node-RED nodes as the editor-facing instantiation. But it does mean that you can use common tools and frameworks to define the visual component and any local logic and then easily consume and communicate with it from Node-RED..
2 Likes
Here are a few requirements bullets. I've been trying to think about the basic requirements for a good Node-RED dashboard. I'm sure there are many more but these are the ones that have come to mind fairly immediately. Maybe they will help in understanding what needs to be built?
- Communications between Node-RED and the front-end page and components
- Ability to define UI components that can:
- Be reused
- Be communicated with to/from Node-RED
- Can be incorporated into page layouts
- Can be written independently of the core
- Can be easily installed by Node-RED admins/editors using npm & the existing Palette Manager
- Can be used via code by developers AND via nodes for non-developers
- Easy, no-code layout screen builder tool
- Multiple pages. Not just multiple tabs.
- Back-end authentication and authorisation - plug & play extendable, custom extendable, session capable, self-service capable, security tested
- Front-end user authentication and authorisation helpers - Standard library for: A function and component for doing logon/logoff, extensible by configuration to allow for user metadata, a component for self-sign-up
- Some common components would be needed - these could be core or contributed but probably best as core:
- Page container
- Tabs container
- Card container (displays a card with other content within it)
- Dialogue box (modal and non-modal, options for buttons, rich content)
- Alert (auto-expire and manual clear, different categories)
- Basic chart
- Basic output (text, numbers, dates, times, ...)
- Basic inputs (text, numbers, dates, times, passwords, extended text)
8 Likes
I'll add input as a user... I would never have pursued NodeRED if I hadn't seen simple widgets placed on the dashboard first. It's close enough to WYSIWYG and No Code for me. Prior to NodeRED I was using C# and Windows.
NodeRED allows me to use a simple PIZERO where I would have had to program in C, C++ on an Arduino Mini. The Dashboard has just been the icing on the cake.
Whatever follows, it cannot be as hard to implement as the UIBuilder... It has to maintain that drop your widgets and wire them up to other nodes in a flow, just like all of the other NodeRED nodes. If not, you'll alienate folks.
Thank yuo DeeCJay for yolur continued support and you others for all of the widgets/nodes that you've developed. Good stuff all around.
9 Likes
Please correct me if I am wrong, UiBuilder can have what you are asking.
Actually, I am looking for the same thing too: A low code UI tool. Easy to use, but flexible and powerful too. You can drag and drop the nodes. Ideally, the user can adjust the window size easily too.
Professionals can always use a more rarified solution for polished dashboards, the "official" dashboard is great for rapid deployment and inexperienced users.
I'd say that the perfect dashboard for inexperienced users would have:
- Drag nodes from the palette into the flow and they automatically appear on the dashboard.
- A WYSIWYG drag and drop editor to move the widgets around, group and resize them (not from the /ui view)
- Ability to work without creating a Tab and Group (default values?).
- Zero requirement to create/edit javascript to make it work - because the slightest error in js and everything tends to disappear. Of course there must be javascript somewhere in the Dashboard internal workings, but I'm blissfully ignorant of it.
- A core set of good looking widgets which can be customised by CSS
The current Node-Red dashboard is pretty good for a beginner. The most approachable I've come across and it's the reason I got interested in Node-Red.
5 Likes
Has anybody checked out GrapesJS?
Hmm, that looks really interesting and might well be pretty easy to add to uibuilder. Thanks for the reference.
I seems to create standard HTML so it should be easy enough to make the HTML save to uibuilder's folder structure.
Offering up the editor is hopefully just a matter of adding a new uibuilder end-point page.
I'll have a go with it and see if it is actually useful.
3 Likes
Some things I think the current dashboard gets right:
- "Node per UI element" is absolutely a great fit, which others have said.
- The "template" node with actual input/output support has allowed for some really cool stuff. I know its tied to Angular, but would really need something equivalent in a new system.
- Core set of nodes that serve most cases, that are largely following the same UI rules. I think for the most part, the existing node configs are well thought out in particular... you run the risk of overcomplicating these UIs with feature requests, and I think a very good line has been walked here to keep these generally useful.
Some sticking points I've had with Dashboard over the years that I'd love to see in the next generation solution:
- Not being able to put authentication around a dashboard in isolation of other things. I'd be happy with just a dashboard authentication system, preferably separate from the core node-red one, and not an actual full claims based authorization scheme around nodes, etc.
- Only being able to have a single dashboard UI at a single URL. Would be nice to have a new top level "dashboard" construct that lets you set different URLs for multiple dashboards.
- The layout system has served surprisingly well, but feels... limited. I think I would prefer something (a) based on a grid system that (b) allows for user defined layouts of "blocks" that widget groups can be dropped into. The current layout approach works ok WITHIN a widget group, but would like some more control of the actual layout without having to go full UIBuilder.
- The graph nodes serve, but leave something to be desired. A lot of us go all the way to a grafana embedded chart for what we need, which is fine for our more complicated cases, and the "vega" node offers some awesome power... if you can figure out how to build one
. At the least I think there's probably some better graphing libs around now than might not have been around back then. I wonder if a vega based graph that is configurable by UI to the point that the current ones are for the simple cases, but then allows for much more advanced graphing if desired would be awesome. - (Architectural) Where can we eliminate dependencies? Specifically is there a reason that UI nodes need to be built on top of whatever framework is chosen here, vs. an abstraction layer over said framework so that we wouldn't have to scrap and rewrite the entire set of dashboard widgets at least every time this happens? Im not familiar enough with the implementation to know if thats feasible, but if it was it could be a good first step to rebase all of the existing widgets on said abstraction layer and THEN switch out the underlying framework providing layout / communication foundation.
I kind of like the idea of something like:
- UI Builder gives you a good communication backend to build off.
- A new dashboards, tabs and layout system (I think a lot of the good work can be done here).
- Basically reimplemented versions of the current dashboard nodes that can be embedded into the layout system (and hopefully abstracted FROM the UI framework).
1 Like
I've been using both the dashboard and UI builder with a lot of fun and success. So my thanks to all of you who have put so much hard work into this amazing Node Red!
The only feature my buddy and I miss, is a multi user system where we both can be logged in and change underlying data through various front end elements.
Therefor, I was already staring at unified-red (node) - Node-RED and thought about going down that road.
For me as an outstanding developer who has no insights into the details each of your projects, it looks like 'Node Red' and 'Unified Node Red' go very different paths, yet with this very discussion I cannot help but see synergies if there was a true "unification"... ? 
Sorry I don't mean to go offtopic here, but I thought I should drop this link and ask if you and these developers (who just recently published an update) might not have some cool ideas to share and brew together?
The main issue I see that is that unified-red has the same problem as Dashboard itself - as a fork, it has the same relatively short shelf-life before Angular v1 is no longer under active support.
I certainly wish I were a better developer and so had finished the security aspects of uibuilder. Or that some better programmers than I would chip in and help.
1 Like
The readme says...
New responsive UI rewritten in Angular 9 and Bootstrap 4
I don't know how Ive not seen this? 
1 Like
Can this be run alongside of the stock dashboard, or is it a commitment of one or other? I ask as it seems to have the same address to access and I am unwilling to mess up my existing system to install/test it or even ui_builder before knowing this.
Honestly, I'm one of the users who was also attracted to Node Red by the presence of an official and easy-to-use dashboard.
Having an official dashboard available allows you to develop important projects knowing that you will have technical support and constant updates (by the way, thank you very much @dceejay).
I agree with the request for a multi-user dashboard: the need to be able to manage pages and widgets based on the logged in user is often present in the various projects.
I always use the official dashboard and integrate with the nodes created by users for any extra needs (see ui-table), certainly not all nodes are maintained but some still work very well.
I think an official dashboard is a great plus, of course there are various limitations in the current one but that's why there is ui builder, if you want something more you go under and learn how to use it.
However, I would like to take advantage of this post to thank ALL the Node Red team because this project is incredibly unique, the learning curve is very fast, the team responds quickly to support requests, the community is very helpful and very prepared.
After so much wandering here I really feel at home.
8 Likes
I think the concept of the dashboard is fantastic, but I can see it is/will be hard to maintain in the long run.
It is extremely valuable to the node-red as a whole, but a different technical approach would make it easier to maintain and will survive the aging of frameworks.
There is so much that can be done with only css grids (especially in combination with css variables! it is truly kind of absurd how good this works) that can do most of the heavy lifting for the layout setup, and I would keep/control that in the page itself instead of being dictated by a component (sidenote).
Example;
I use http-in/out, websocket nodes and use template nodes as "components" and i use it in the same way as node-red-dashboard; send only the relevant values to the component, which are updated with using the websocket with vanilla js.
That way is very versatile, the project could provide the basic building blocks, if someone wants more, they can create and share their own "components". No aging dependencies, truly flexible layouts and interactions.
Yes it might require a bit more "programming" from the user if one wants something different, but it is relatively lightweight compared to vue/react/angular-like frameworks but less maintenance burden on the team, win win.
Like vue and react frameworks are cool, but they change a lot too, which would require the same maintenance.
1 Like
Unified-red dashboard... first I've even heard of it... If they have re-written it and it is largely compatible (unknown at this point) - it would have been nice to have had a heads up a while back.
6 Likes
