Yes... a bit. I was thinking of writing something similar to gridster.js with some extra features (adapting the positions/sizes on smaller screens) and without the jQuery dependency. I guess the users could also write the layout since it can be saved/interpreted in/from any format... But I guess it depends if someone needs it... I don't think people prefer defining the layout by text when you can do it by drag&drop.
Could be, though I don't think the current form of uibuilder allows the use case that I'm thinking of but it can always be extended. (the one of the classic dashboard with a widget/node). We can create many layers of modular functionality...
There are several other like Gridster, like Gridstack, Muuri, etc - which are being considered I think. (though I can't help feeling there ought to be a css grid based version somewhere....)
The other "feature" that keeps coming up (along with all the other already mentioned) is the ability to support ui_widgets within subflows that are reused multiple times... some thought required.
I think that you would at least need to be able to extend to tabs as well.
Maybe most people wouldn't choose to do it via a text configuration. However, the great advantage of supporting it (even if you also have the visual layout too) is that you can then export/import so that you can develop on a device and share the layout to any number of other devices (or customers!). Something that I would say would be a massive win.
For VueJS, there is vue-grid-layout, More can be seen at this list. Actually, some of the examples in that last link are quite close to what you are looking for I think.
Gridstack (at least) allows nested grids - eg http://gridstackjs.com/demo/two.html
so widgets inside groups and groups can then be ordered... and could then extend to tabs also (though that may need some ui thinking... maybe more of a drag/drop target - but I think we still want the groups to be responsive to layout.
vue-grid-layout also nice but a) main dashboard not using Vue... and b) doesn't seem to support nested grids... still all good ideas
No, I realise that but just making sure people know about Vue's capabilities in case they are thinking about radical new approaches.
Good point. I didn't check the others I'm afraid as I was trying to get uibuilder v1.1.0 deployed (a reward to myself for finishing clearing the loft!).
@cinhcet, @TotallyInformation : I absolutely understand that a lot of users expect more flexibility, compared to the current dashboard. But it would be nice to have a single dashboard that offers both flexibility and basic out-of-the-box functionality (if that would be possible anyhow?).
Currently there are already a number of dashboards:
All these nice pieces of software are build by developers in their free time, with very good intentions. But as a Node-RED node contributor, I only have time to develop nodes for one of these dashboards. And when I want functionality from another dashboard, then I'm screwed ...
I see that all the experienced Node-RED dashboard contributors have joined this discussion today. So I REALLY hope they can agree on some technology and architecture ...
node-red-dashboard, node-red-contrib-polymer , node-red-contrib-mdashboard : They all have the same philosophy, for example about how the dashboard is configured and also the code is structured similarly in the sense that the dashboard is defined in node-red and then this configuration is send via a websocket to the browser where programmatically the pages are created. They also look similar and you can achieve similar things with them.
node-red-contrib-uibuilder does not impose any web technology, meaning total flexibility. It provides you a convenient communication layer with node-red. However, everything goes through a single node.
node-red-contrib-component-dashboard is based on web-component technology (although this is not completely true, you can also use the framework I developed to create a dashboard without touching web-components, similar to uibuilder). The main idea is that each widget has a node in node-red AND a web-component for the ui. Creating the page means to plug together html tags.
I am also amazed that many people joined this discussion
I totally agree, in principle. However, there are two things to consider:
First, if there are different philosophies about the dashboard, it is difficult to find a common denominator. I for example would not be interested in the possibility to design the dashboard ui via an editor that does not edit text, since this would always be limiting.
Secondly, many of us do that in our free (limited) time, mainly motivated by our own purposes. I, for example, needed more flexibility to create an upnp music controller/library browser in the dashboard. Then I was also amazed by web-components and wanted to do something with them But, since this is the beauty of open-source, I at least try to share it with the community. However, since I spend many hours on this project AND it is working for me, I don't think that I would now start to migrate to another dashboard again, since I am sure that it would require a lot of changes. I guess something similar holds for Julian and the uibuilder users (which are also many, I think).
But still, again sorry if I step on somebody's toes here (in german you would say to step on somebody's foot), I personally think that web-components are the ideal technology for developing a dashboard. And as I outlined above, you could create within the framework I developed such an editor such that you do not have to write html. You could also make a web-component that is configurable via node-red similar to the existing dashboard that creates the dashboard. I also have to say that I would not program such an editor, since I would never use it, but it would be much effort I think. But if someone wants to talk with me about how one could realize this within my framework, I am happy to do so.
I think that in principle, it would be possible to realize the behavior of uibuilder, the dashboard and my stuff within one framework (....e.g. with web-components....) However, however, however, I anticipate that doing this in an "easy-to-migrate" way would require a lot of thought....
Yes, everything does currently go through a single node. You can pass any data to it of course and I use link nodes to integrate from other flows. I've looked at creating additional nodes but you don't actually gain much other than a cluttered palette.
What I am planning is to define some data schemas that would automatically load web components. At that point, it would doubtless make sense to introduce additional nodes.
The problem with going down the web components route is that, at the moment, in order to get good coverage across browsers (especially mobile), you cannot use the draft web component standards and that forces you to commit to a framework - something that I want to delay as long as possible since the whole point of uibuilder is to be able to use any framework you like (or no framework at all since the fe library gives you enough to be able to hand code things if you like).
So any component work that I do will most likely be a new, complementary node that chooses a specific framework (most likely VueJS) with uibuilder being used as a core. This is also why I'm interested in collaborating with others who may wish to chose a different framework also with uibuilder as a core.
This is always going to be the case. For the basics (and for most people), the underlying framework doesn't matter much as long as it works across a wide range of both desktop and mobile browsers.
But once you go beyond that, you need access to the full framework, something that not only does Dashboard not allow but even if it did, the framework is very complex.
So we are always going to have tools that leverage different frameworks to deliver UI's.
Well, I don't actually know how many people use uibuilder actively. I'm certainly seeing plenty of downloads but not masses of feedback so either it just works or not so many people are using it.
Either way, I'm using it myself of course so I'm never going to want to mess it up. But I do want to keep building on it and I recognise that there is plenty I could do to improve it.
My experience recently using Vue and bootstrap-vue shows me that the core is pretty solid and plenty flexible enough to do anything you like. It also shows me the way forward for delivering pre-defined components that are easier for users to consume without causing the core to become limited to a single framework - e.g. making a companion library.
I've no doubt that someone far cleverer and more experienced in coding that me will eventually come along and make uibuilder redundant. Then I'll be able to "retire" and relax
So, this thread has certainly got me thinking again about how uibuilder can be leveraged as already discussed. To play with the ideas, I'm starting a new set of nodes called node-red-contrib-uibvue.
Head over to the repo if you'd like to see my thoughts evolve and to contribute if you like. The WIKI will contain the details.
The idea here is to use uibuilder as a peer while making use of VueJS's component capabilities to provide some standard components with matching nodes.
You will most likely still need to do some coding but the initial aim will be to minimise that. Most of the complexity will be hidden away in VueJS components. Eventually, we may be able to add a drag and drop designer such as one of those mentioned above but that certainly would not be in early releases.
Bridging this gap will certainly help the community.
Speaking for myself, since I began tinkering with Node-Red and JavaScript, I have become a little more experienced and diving into a little more complex situations. Although, I am not at all experienced enough to use uibuilder on its own. I could, but the dashboard would be very 1995.
Having a stepping stone between node-red-dashboard and uibuilder would be great. For me, the jump from NR dashboard to uibuilder is too far.
No problem. Of course I really enjoy doing this stuff and it is a pleasant change from the big enterprise Information Systems design and Information Security that I do for a living.
Well do then have a play with VueJS and bootstrap-vue - as detailed in my home dashboard post from a while ago. That requires virtually no skill to get a good looking layout! It isn't has hard as you think - as with much IT.
I did a bit of research and angularjs supports bootstrapping on a single element so it should be possible to bootstrap a small application that renders the template on each widget that uses the old templates (AngularJS). There is no teardown method but it seems that $rootScope.destroy does the trick, combined with removing the element from the DOM (How to destroy an angularjs app? - Stack Overflow).
That is nice! I believe that the basic infrastructure I created for node-red-component-dashboard would be a good starting point (of course, as people always like their own stuff and want to promote it, blabla....)
If you are interested, have a look at what I have done so far. I am just very busy for the next two to three weeks, but I could answer questions, I think. Also things like multiple dashboards, ajax communication in addition to the standard websocket (which is, for example, super useful for displaying data), are already implemented.
The ideal roadmap would be to recreate ALL current node-red-dashboard widgets as web-components and create such an angularjs template widget. Then at least one could create the same functionality of the current dashboard with less transition effort. The next step (which I would not do myself) would be to create a designer for easy dashboard creation. In the long term, it would more ideal to get rid of angularjs templates and create a new template designer. Since web-components are more or less such templates, this should also be doable.
What I have so far (basic stuff, not counting widgets for my very own needs) is:
button
switch
icon switch/icon button
text widget
gauge (nearly publishable)
chart (not yet publishable due to countless options)
basic layout stuff like cards and groups
app drawer layout
Creating things like dropdown, textinput etc. should be very quick to make.
I would also like to get rid of the polymer library in the near future and use lit-element or even just native web-components with lit-html rendering. I would then create a new button for example, but leaving the api identical, so that you only have to change the html tag name and get the same functionality.
The biggest problem I always have is whether I should make all options available or not, since sometimes it also makes sense to create a new component, instead of many options.
our basic philosophy has always been that
a) less options is easier for beginners/users to understand
b) don't add options unless users actually request them (no WIBNIs)
c) early real world feedback is better than trying to guess
d) it's easier to add options than remove them
e) think twice before adding them - does the simple solution restrict future options ?
f) a node should (try to) do it's thing well and not try to do too much... - but yes, tricky with charts...
you edited your post when I already answered Yeah, I find charts generally the most tricky part to get right from a user perspective. Maybe I just start with publishing a line chart widget and then wait for feedback on bar charts etc.
Yes - as usual folk will probably want all types - and the balance is always do you add one node per type - or several to one node. Of course - if they will now be separately installable then again it's ok not to install the ones you don't need, and just add them when you do.
Also there are several use cases for charts that are quite different...
One is live data (which is what the existing dashboard tries to do) - so simply adding a point should be easy...
Within this there is historical data eg a line chart
and then just the latest values - bars, pie, etc
Another is just plotting a data dump from a database - which is what a lot of users then have to force the existing dashboard to do - so this use case could possibly be made somewhat easier
Hi!
I just published a new project on github/npm - a new Dashboard. Funny coincidence that this discussion started a few days ago
It's a Polymer 3 based Dashboard UI with WYSIWYG Editor, utilizing Web Components, Custom Elements and the Shadow DOM. The Editor aims to be similar to the Node-RED Flow Editor, all html attributes and styles can be directly set by sending messages to the node. Every Event that is emmited by an Element will be outputted by the Node.
Currently everything is positioned absolute, but I plan to add special elements for different (responsive) layouts.
Right now everything is Polymer, but I plan to get it "Framework Agnostic", so in future it should support elements that are created with Polymer, lit-html, vue, ... - everything that is a Custom Element should work.
Another thing that is worth mentioning: there is no "MVC" or "MVVM" or something. The DOM is the View and the Model at the same time, the controllers are encapsulated in Custom Elements. This goes so far that also the persistance of the "views" is just plain HTML. Place some Elements, Deploy and see what you find in your Node-RED directory
Feedback is highly appreciated!
Yup, that's that I was thinking. Each widget should use the properties: msg, state, config and emit the events sendMsg, updateState (or something similar).
Taking this to the next level, you could have any number of widgets defined for a node type and select the one you want to use when you design the dashboard (edit widget, change type?). Meaning a chart node can have 10 widgets that can represent the same data and node-red/flow-editor doesn't care which one is used in the dashboard.
A disadvantage in this case would be that along with the flow you also need to copy the dashboard config file to get the same look'n'feel.
It isn't has hard as you think - as with much IT.
- so this use case could possibly be made somewhat easier
