Non-transparent background needed for Editor status and horizontal scroll

I've tried to like the new Editor styling but one thing is really bugging me I'm afraid.

  1. The lack of a full horizontal scroll bar space is a fairly horrid UX as it can be really hard to find the bar itself. The example I've provided is actually not so bad but when you've been moving around the Editor, perhaps clicking on a debug message and so you may not really know where on the "page" you are, it can be really disturbing to try and find the thing.
  2. Similarly, the bar of icons is quite hard to identify on the screen, it would be much easier if that section or the whole bottom line were blocked with a non-transparent bar.

My eyesight is still under-par right now and so I am really noticing more and more of these UX/accessibility issues.

The vertical scroll area should also be blocked out for better visibility, on a really busy flow page, it is as bad as the horizontal. It could also be attached to the sidebar panel, it really doesn't need a separate gap, that's just a waste of space.

Not suggesting that this looks particularly good but it is certainly easier to see:

Using Stylus to override the defaults:

#red-ui-workspace-footer {
    background: hsl(208 35 79 / .5);
}

.red-ui-workspace-scrollbar {
    background: hsl(17 35 79 / .5);
}

I find this non-ideal too.

One of the first things that struck me on moving to version 5. I don't like it either

I know Nick is away from his computer this week but it would be interesting to know the thinking behind extending the workspace behind the right sidebar and bottom buttons.

I suspect it involved a lot of work and confers little noticeable gain. Perhaps it was made necessary by some other feature of the v5 interface?

Ps I posted an alternative CSS snippet to stimulate 'normal' scrollbars, it was on one of the beta release posts I think

I actually got used to the scrollbars but I did add some code to fade them out completely because I gave up giving them any consideration. So mostly I don't see them or need them, and hence the last thing I would need is a background colour for them.

(function(){
    var hidescrollers = () => {
        $('#red-ui-workspace-scroll-v').fadeOut(300)
        $('#red-ui-workspace-scroll-h').fadeOut(300)
    };

    var hiderscrollerstimeoutid = setTimeout(hidescrollers, 1500)

    var eventHandler = () => {
        clearTimeout(hiderscrollerstimeoutid)
        hiderscrollerstimeoutid = setTimeout(hidescrollers, 1500)
    }

    RED.events.off('view:navigate', eventHandler)
    RED.events.on('view:navigate', eventHandler)
})();

Taking a guess, it's the test to see whether floating windows would be a good idea. I think, atm, with the left side fixed and the right side fixed but "floating", it's confusing and irritating (see my comments of having hidden nodes when using find).

It's not the best thing about NRv5 but I'm thankful that there is an alternative to the fixed sidebar.

I've been thinking this a lot recently. I mean, it's jolly useful being able to see through the gaps isn't it?

I initially assumed it was going to be some kind of "Glass UI", where the sidebars could gain transparency / blur or something. Realising that wasn't the case, my eyes have become accustomed to the look, but I do find it makes the overall feel a bit messy.

What I really don't get is why the left bar doesn't get the peek-a-boo seethrough bits, it's a solid sidebar, but the right bar does. Yet they are conceptually the same in that you can drag things from one to the other.

I agree with this. To me, it seems like an attempt to make something look more modern. But this combined with the more overall "white" feel of all the page elements, and as you say - lack of blocking out - it feels difficult.

Small detail but case in point (about flattening visual elements and making everything light): no visual separation between flow bar across top and left sidebar:

I understand the need to move away from blocky, grey UIs towards something more stripped back. But I find the overall design somewhat unexpressive, and not significantly more useful either. It's the design equivalent of choosing a new grey sofa: a defensible decision that rarely becomes anyone's favourite part of the room.

I probably sound harsher than I intend here, and I don't mean this as a criticism of the work overall. Going back to my previous point, though: if it's genuinely difficult for the eye to spot a scrollbar, I do think that's a usability issue.

I feel the same. Personally I don't use them because I always have either a side-scrolling mouse to work with, or two-finger gesture on touchpad. When I am using the mouse, I often whizz around the screen with Ctrl-scroll to zoom in and out of a single point, very quickly, then left-right and up-down scroll with the mouse. I couldn't really imagine being without the side-scrolling mouse OR the enormous multitouch touchpad on my laptop.

Would I use the scrollbars if they were blocked out and usable? Probably 20% of the time.

I completely agree with this. The UI refresh has probably taken many hours of work, but from a user’s point of view, the practical benefit is essentially zero.

That's a little harsh considering the major advantage is being overlooked here: there are now 4 sidebars essentially. That is, there are four places where plugins can put their content. Which is a huge success IMHO because I really use a lot of sidebar elements:

Screenshot 2026-08-05 at 07.26.54

So I have spread these out over left/right, top/bottom to make my workflows faster - depending on what I am doing.

This reminds me of something I said somewhere else concerning how folks experiences with Node-RED totally differ depending on their input devices. If I hadn't got a largish touchpad (macbook) and instead would continually be reaching over for a corded mouse, then I would find the overall experience annoying - too much mouse usage, too much hand movement, too much distraction.

As it stands, using a laptop with keyboard and touchpad speeds everything up. I also use a cordless mouse with a scroller and third button - both make it also simpler to use NR. Again, because my mouse has a middle scroller and button, there are more things I can do with the mouse. If I was using purely a two button mouse, the experience wouldn't be half as good.

I think statements like "the practical benefit is essentially zero" don't help considering how much effort was put into making this redesign, which is overall, fantastic (documention popover, far better zoom, four sidebars etc).

It's very simple to overlook the effort put in simply because one does not have to pay for it. That's the nice thing about open source. What isn't nice is when folks simple come along and say it's shiet. That is discouraging, rude and essentially doesn't help anyone.

And also, you don't have to upgrade - you can stay on the 4.1.x branch and continue to use that. If you don't and are using the 5 branch, perhaps consider listing those things that do work for you so that folks can benefit from the positive feedback.

I agree, there are some really good ideas that have surfaced in the new design. But also some unhelpful UX to go with them unfortunately.

The Node-RED Editor is an incredibly powerful app. So it needs a complex UI for sure. But the more complex the UI, the easier it is to get the UX wrong. Especially, as you've said, different people will have - and need - very different needs.

It currently feels as though the Node-RED Editor is in a transition state. Moving from its original design (now well over 10 years old) to a more modern and flexible design. Feels like Node-RED is growing up! :smiley: But, as with any teenage transition, the growth periods can be uncomfortable along the way. :rofl:

Thank goodness we've got this excellent "village" of people willing and able to chip in to help that transition.

The fact that Node-RED is free and open source does not place it beyond criticism; acknowledging the time and effort devoted to a piece of work does not necessarily mean that its outcome must be regarded as successful or particularly useful.
Expressing a critical opinion does not mean belittling those who worked on the project, it simply means observing that, in this case, the considerable amount of work involved does not appear to have produced an equally significant practical benefit for users.

The official announcement itself describes Node-RED 5.0 as “the biggest change to the editor experience in the history of the project” and, given such an ambitious claim, it was entirely reasonable to expect a substantial and immediately noticeable change in the day-to-day experience; to date, however, I still struggle to see it, since the editor has certainly received a different arrangement of some elements and various visual changes, but the way it is used in practice has remained essentially unchanged.

At this point, one can almost wonder whether such an emphatic presentation was also intended to shape users’ perception in advance of the concrete benefits the work would actually provide. :grinning_face_with_smiling_eyes:

And yes, I will give careful consideration to the suggestion that I should not upgrade and simply remain on version 4.1.x.

Did you provide feedback during the extended period of discussion and feedback for the several beta versions prior to release?

Taking this argument and applying it to the relationship between a parent and their child would mean that if the child came back from school without top marks, it might have as well stayed at home and done nothing.

It's a very subjective argument and one that holds for you but definitely not for me since I see the work as having had a great benefit for my personal usage of Node RED. So, for me, your argument doesn't hold water.

Again, a subjective opinion. I have definitely changed the way I work with Node-RED and have even added to that by creating the presentation mode plugin.

It is also the aim of the revamp not to interfere with how you work with Node-RED. Unlike the giant tech corps that seem to enjoy inflicting new ways of doing old things upon their users (looking at you Apple and glass BS), Node-RED tries to keep the old methods of working but adds new stuff to allow for new approaches to using NR.

So here I see your complaint more of a complement that you can continue using NR as you have been but can also now try a different approach, if you so choose. I have chosen to take a completely different approach to how I use NR and now have difficulties using NRv4 because it now seems very constraining for me.

Indeed but just to criticise without having feedback or positive suggestions is pretty pointless in an open source project, i.e., it doesn't help anyone. You criticisms seem very personal and not generally applicable, so that makes it even less valuable since there aren't useful positive alternatives that you suggest.

What criticism does do (as opposed to constructive feedback), is to reduce the motivation to do anything for the project. It's a force for negativity.

Again, going back to the parent-child relationship: telling the child that it's stupid because it didn't get top marks doesn't help. Helping the child to understand what it doesn't understand would be a force for good.