Will do yes
2 Likes
I disagree. I think a lot of folks have / are going to turn away from NR when faced with Dash 2.
Its interesting to see so many echo my findings from a year ago (I started rebuilding my dash 1 website in dash 2 on March 24th 2024 - a year later and I'm not even close to having parity).
If I had to start with dash2 out the gate, I am quite sure my site would not have been built or ended up where it is today.
This well states what I have been struggling to describe. Dash2 raises the no code/low code bar into programmer / programming experience required territory.
It seems to put it on the same level as UIBUILDER.
I never felt the need to retain a programmer on staff till I got to working with Dash2.
I've put my 'responsive' bugs and glitches on the github, but it's hard to put a ticket in for the impressions and experiences shared in this thread.
I guess I just want to say @craigcurtin its not just you, there are quite a few that feel this way, so be encouraged to just keep picking up the mouse and whacking at dash2, you are not alone.
For 'migration' from dash 1 to dash 2, I just have this critical (for my site) tip.
Be aware that dash2 'leaks' ALL the msg.xxxx data to the browser. You can end up sending a LOT of crud over the wire that you never intended.
Clean up your msg payloads BEFORE sending it to a dash2 node.
2 Likes
Hi @thebaldgeek
I would really appreciate if you could share a few examples of things you don't consider low code anymore. It would really be helpful, for me at least. Perhaps the outcome is that it cannot be solved, because D2 is - for some reasons - way too technical for a (large or small?) subset of our community. But then at least we all know, and that might be useful for some folks here to decide how to continue. It doesn't matter to me anymore what the outcome is, at condition that the discussion is polite and constructive. To everybody: always keep in mind that a handfull of people have put their hard and soul and time in D2, in order to deliver free software to strangers...
I have been trying to help as much as possible to solve D2 issues. But I am wearing all the time my very technical glasses, so I might be responsible for some of the stuff that makes your heart bleed. Without even being aware of it 
. That is imho a big problem of low code software: you need very technical people to build it, so you need to be very careful not going into the wrong direction...
Recently I have tried to explain my son how Node-RED works, by adding a simple button to my dashboard. Thought it would be piece of cake. Although he did really effort to understand it, it was kind of a failure. That was the first time ever that I started understanding why lots of people find our software way too technical. It was a real eye opener for me 
.
So shoot...
3 Likes
Perhaps what I was trying to say was more nuanced and I failed. And I was nitpicking about "newbies" 
Getting into Node-RED in the first place was a battle - there are no comparable tools, no programming language that is flow based, i.e., pure message passing. So the underlying concepts of Node-RED are already foreign. So to understand the basics of Node-RED and feel like you can do something is already a major step.
Remember if I learn to program C++, then doing Java is a piece of cake. If I know Java, then Javascript is a given. The hardest part of programming - some might agree with me here - is to decide between Emacs or VI as you editor!
For Node-RED there is no such comparison - perhaps if someone has used Yahoo Pipes then Node-RED would make sense but is there anything else?
I come from a programming background and it took me a while to understand how DB1 worked i.e., what are the underlying concepts of page, tab, button, etc mean and admittedly the individual UI elements are inconsistent in how they work (e.g. no all send a message on change or rather don't send the right value and so you have to query the value).
But again there is nothing I could have known (or used) beforehand that would have given me a clue as to how DB1 worked.
So what is the "standard" way to create a Web UI using a low-code, flow based programming environment? There is none. UIBUILDER is one attempt, just using the template and http nodes is another. But there isn't the standard paradigm for creating such a UI.
Also web based frontends are notoriously difficult to get right - I come from a time when the table element was used for layout ... then css came along and divs took over to scss and markdown. inbetween Javascript was born and initially we all turned it off! But Flash made us turn on Javascript. Then Flash disappeared...
If you then look at "proper" UI paradigms (as - arguable - found in languages such as Swift and Obj-C with Xcode before it or even Tcl/Tk) then you will notice that HTML and Javascript emulate (i.e. badly) what is a proper frontend definition language should be doing. So the whole thing is built on quicksand - for me - Node-RED DB1or2 is a high rise building built on top of the sands of the Sahara!
My point is that DB2 is another attempt (after DB1) to create a dashboarding framework for a flow based programming tool on technologies that are standardised themselves (i.e. HTML, CSS + JS). Think mobile v. desktop, chrome v. safari v. edge, jquery v. react v. vue v. ....
I'm thankful that I don't have to do all this dashboarding in pure JS + HTML with a sprinkling of CSS!
This thread perfectly illustrates the divide between those with knowledge of coding and various development frameworks, and the non negligible amount of users who simply just want to get on with it, basically who use Node-Red Dashboard as they would Word or Excel...
There was always going to be a learning curve involved in moving to DB2, things change and that is fine. I am sure most of us were expecting to have to deal with rendering or sizing issues, or to have to add or remove a few wires here and there, or change a few (or a lot) of properties.
But I wasn't expecting to have to use CSS overrides to replicate the standard behaviour of core DB1 nodes in equivalent core DB2 nodes, yes I consider this coding, and I think this will be raising the bar for a lot of people. It certainly does for me. Aligning the led to centre in ui-led would be such an example.
A quick glance at DB2 queries on this forum would quickly show that a lot of solutions involve some coding. I don't remember experiencing this in my early days with DB1, at the time most queries I remember reading seemed related to payload formatting.
A few lines of css are not "low effort" or "easy" for a lot of NR DB users. What matters to a lot of people is the functionality and ease of getting something up and running quickly with a few drag-and-drops and parameter configurations, without having to spend a lot of time researching one or the other development framework to be able to get a message sent at the click of a button or align an element to centre. This is something DB1 did very well and I fear is slowly getting lost in DB2.
This will no doubt impact the onboarding of new users, which is a shame because despite the whingeing on display, I think DB2 has a lot to offer.
2 Likes
I have had a fair few issues with Dashboard 2.
Some were bugs, some related to appearance, some to usability and some just down to me misunderstanding.
But @BartButenaers has perfectly reasonably asked for specific examples where DB2 requires more coding than DB1.
The first example that jumps to my mind is with the gauge - how to represent a value of 1234.56789 as 1,234.57%.
Please note, I don't claim that this is a sensible thing to want to do.
Nor am I asking for this widget to be fixed.
It is just an example where DB2 requires more code than DB1. A function or Jsonata and CSS.
DB1
Angular filters let you do this right in the gauge config.
DB2
You need to massage the payload, most likely with a function node.
msg.payload = msg.payload.toFixed(2)
return msg;
I tried formatting the number with commas but it breaks the gauge.
Look at the result:
The DB1 gauge has an appropriate choice of font size and positioning. The limiting values are below and outside the coloured band leaving plenty of space for the value.
No doubt it can be enhanced but I am sufficiently happy with this to use it in a dashboard and move on.
The DB2 gauge.
The value is displayed in too large a font and too far up into the semicircle, reducing the available space.
The limit values occupy space inside the semicircle which could be used for the value.
The pointer seems unnecessarily small.
I don't feel this gauge can be left as is. At the very least it needs significant CSS work, more likely a different (contrib) widget.
2 Likes
This is a simple example of the difficulties encountered realizing a simple dashboard ...
@Steve-Mcl try to help me but without success and writes ...
OMG! I just wanted align two group..... This is the final result, patience, it will stay that way ...
1 Like
@Giamma, @jbudd, @Mrb32
Thanks for illuminating me with some examples! That is really helpfull!
I will also add my own feedback: I really like most of dashboard D2 and I really enjoyed working together with Joe in my free time. Don't understand why more contributors popup, because Joe is very constructive 
. But I find it rather hard to get refactor the ui nodes without introducing breaking changes, mostly by the state and data store related code snippets. There have been a lot of good improvements in that area, but it is still a bit too complex for me.
If I conclude correctly, most of the problems listed above is related to CSS that the user needs to apply by his own. I feel your pain, because I am also not best friends with CSS. Don't have time to read about, and doubting whether my old brain will ever be able to understand it. Yes I agree that a CSS should only be required for experienced users that want to tweak the widgets to build next level dashboards. The standard CSS of the widgets should be sufficient for common use cases.
In fact that is NOT a fundamental problem, because it can be solved. The only thing we need to solve that is some people from our community with CSS knowledge start contributing. Or some professional users from our community that earn money by selling the dashboard, which can pay somebody to contribute CSS fixes to the dashboard. That is imho the least they can do in return for our community.
But until now ZERO people help, so that is a real fundamentel problem. The result is a huge pile of issues on Github. You will see that indeed a lot of those are CSS related. Which is the reason - beside a severe lack of free time - that I don't solve any of those issues myself. Because just like you guys, I have a lack of CSS knowledge. Which is why you guys now have to enter your own CSS rules to get things right, and you have no clue how to do that...
For me the situation is rather simple: if no group of people pops up to start helping, then imho dashboard D2 is doomed to die very soon. Similar to how our community (including myself!) has not supported Thorsten in any way with his magnificent Flexdash dashboard. As the only current contributor of the dashboard D2 I have lost completely all my enthousiasm to fix issues or to migrate my own ui nodes to D2. Writing js code that is not going to live long, is not my idea of a fun hobby. I have been begging all over the place for help, but that wasn't quite a success...
So the choice is up to this community: start contributing like a real open-source community or you won't have any dashboard left soon. Of course you can start praying that somebody suddenly pops up to develop the perfect dashboard in the next months for you, but not sure if that is very realistic (seen the contribution enthousiam of our community). It is as simple as that...
Writing code that might never be used is not my idea of a fun hobby. Therefore I will now focus from now on my personal home automation instead, and stop contributing to Node-RED. In case the community should decide to start contributing to dashboard D2, I will perhaps join again. Don't know yet. Only future will tell. I will look meanwhile for alternatives that fit my use case, but I know that won't be easy...
P.S. I have some (nearly finished) code of the ui-chart node, which works with Echarts under the cover instead of ChartJs. I can push my latest commits to my fork on Github, if anybody is interested.
Good luck everybody!!!
3 Likes
similar issues here. have been trying to get this fixed. for some specific reasons, i want the widgets in their own group. but i cant get the groups height at same level.
I wonder if the choice of grid as the default ui-page layout has made it more likely that layout issues such as @Giamma and @smanjunath211 report will arise.
This forum has very many threads discussing CSS tweeks to DB2.
I'm sad you don't see them as helpful contributions.
As well most of the people here know my middle name is CSS I'm absolutely not agree that CSS override should be last resort.
Everything on the page looks like it looks and is positioned as it is because of CSS. This is fundamental.
So whenever the default look doesn't satisfy your needs, the thing to change is CSS.
But as there is countless of opinions and wishes, there is no way to satisfy them all by making configuration options for everything.
Somewhere you must draw the line what is reasonable to have as configuration option. I tend to support the "less is more" way. Because if less, then it is easier to manage and easier also to override.
DB2 is about 98% better than DB1.
That's all.
2 Likes
I believe he is referring contribution to CORE and not quickfixes...
the layout i have used is FIXED, but GRID style also doesn't have any improvement in vertical height adjustment.
I use same layout (FIXED), except one dashboard the other are show on tablet / mobile for my home-automation ...
This is because you already know how to do it, so you find this easier.
A part of the DB1 user community simply has no clue about this, this includes me... The behaviour of DB1 didn't require interventions of this type for a lot of people either, so this comes as a shock for all idiots like us.
DB1 was never meant to be anything more than a way for people to put a UI together quickly. If you wanted more, you needed to either develop your own nodes or chose another dashboard. DB2 is much more capable and better in many ways.
The overrides and other non CSS tweaks shouldn't be last resort, they should just be delayed a bit more in the process in DB2... This would require aligning the core nodes' default behaviours between DB1 and DB2 a tiny bit better, may be by offering one more box to tick here and there.
The project backlog seems to indicate this is happening: it is full of layout and style related stuff, so I think that, over time, things will become easier for those among us who are not in the fortunate position to be able to code...
I am optimistic 
and I appreciate all the efforts and help provided by the community.
Your expectation is absolutely spot on. We wouldn't expect anyone to have to do this, but without issues being raised, we don't see them, so can't fix them. I want to be very clear, our intention with Dashboard 2.0 is low/no code all round. Any friction you're facing is never intentional or as-designed.
For the Grid alignment, of course we don't want to see that. We made a switch to CSS-driven layouts so that mobile responsiveness was supported out of the box (not the case in Dashboard 1.0), as a consequence we lost the automated height alignment.
For the gauge label sizing and formatting, we have a PR opened to address that by @Steve-Mcl, but both Steve and I are working full time on other projects within FlowFuse too.
As @BartButenaers has kindly put out too, Dashboard 2.0 was a one-man band (me) for 12-18 months. It's not my full time job, and I've not had a chance to contribute at all for the past 3-6 months because of my switch of focus to the Node-RED Academy, and my other jobs at FlowFuse.
2 Likes
Why not ask @BartButenaers if he would like commit rights to the repo as co-maintainer? I'm sure he would be a great maintainer as he has proven his abilities in many Node-RED related projects.
I hope that I am wrong, but I didn't read it like that.
Perhaps @jbudd you could clarify what you meant by that comment.
