🎉 Node-RED 5 Beta 3 now available

[knolleary]

The third beta release of Node-RED 5 is now available!

This is the next iteration of the UI changes. We've diverged a bit from the original concept designs, but it feels like we're getting to a good place. It also feels like most of the major changes have now been made; it will be mostly fine-tuning from here.

Notable changes:

• Editor tabs have moved up into the header
• The sidebar buttons are now along the bottom
• The status widgets have been rearranged

At this point, I need to switch gears somewhat to work on some of the other tasks we want to get done for Node-RED 5 - a lot around the project infrastructure. These will be less exciting for end users, but hopefully bring some joy to developers who want to contribute to the codebase.

That said, I know there are a small number of UX quirks we want to get resolved:

• adding a dark theme (yes - it will happen. no - you don't need to ask for it again)
• the sidebar buttons/status widgets don't play nice when the window is too narrow for them all

We're also working on adding a way for the community to be able to interactively preview these changes without having to install anything. Follow Add WebContainer-based branch preview deployments by dimitrieh · Pull Request #5475 · node-red/node-red · GitHub if you're interested in how we're doing that.

---

Installing the beta

If you want to try out the beta, you will need specify node-red@next when you use npm to update. Without the @next you'll still get 4.1.x

So on a Pi you'd do:

sudo npm install -g --unsafe-perm node-red@next

Docker images

The beta images will be available soon - all being well with Ben on holiday. They will be available under nodered/node-red-dev:v5.0.0-beta.3 - with the default image being based on Node 24.

Reporting problems

If you hit any problems, please report them either as a reply on this topic, or in the #core-dev slack channel. Please do not post new topics to the forum regarding the beta as that could confuse users who are not using the beta.

What's Next

The Node-RED 5.0 work is being tracked in this issue. From there you'll find sub-issues for the various strands of activity going into Node-RED 5.

For the UX updates, you can follow this issue - with a number of sub-issues already raised for the next betas to address.

[knolleary]

If you want to preview the beta without installing it, you can do so here: https://dev--node-red-preview.netlify.app/

This will run Node-RED inside your browser; any flows you deploy are running inside your browser and will be lost when you reload the page.

Still working through the configuration to get this hosted on a proper url - but for now use: https://dev--node-red-preview.netlify.app/

[TotallyInformation]

Sorry Nick, but the right-hand panel is now very different to the left-hand panel in looks and it certainly triggers my sense of balance. I just can't really see any justification for it, nor does it seem to add any value. It might make sense to be able to see the underlying flow panel if the right-hand panel were two separate panels, each of which could be minimised and/or closed. But as it is, it is simply confusing.

What is worse, the drag behaviour of flow nodes as you hit the panel seems inconsistent, especially at the bottom.

From a UX perspective, the right-hand and left-hand panels really should have matching, balanced designs.

[TotallyInformation]

In addition, the behaviour of the icons under the left-hand panel is inconsistent. If you drag the palette to the top section and try to drag the flows to the bottom section, it mostly doesn't work.

Actually, the same is true for the icons in the right-hand panel as well.

---

Oh, and the "Search flows" input does not stretch the full width of the panel.

[Buckskin]

I liked the ability to drag & drop the contents of the panels, this is no longer possible. If drag and drop is no longer an option the order of icon selection could be used to position the panel contents (first click is at the top)
The icons on the bottom is OK but it would be better if they were in a footer along with the zoom controls etc. This would allow them to be more visible when the panels are removed (by unselecting all icons). This is currently gives more space than the previous reduction to the edge panel.

[knolleary]

@TotallyInformation

but the right-hand panel is now very different to the left-hand panel in looks and it certainly triggers my sense of balance.

This is a deliberate design choice I've written about previously. The idea of have a left-to-right information hierarchy from 'outside' the workspace to 'inside' the workspace. I'll be interested to hear what other's think of it.

Part of the rationale for having the right hand panels appear to be floating over the flows is to give the flows more sense of space - even if its space you can't directly interact with. It moves the hard border to the edge of the screen.

@TotallyInformation

What is worse, the drag behaviour of flow nodes as you hit the panel seems inconsistent, especially at the bottom.

Looks like something is interrupting the mouse events - probably the virtual scroll bar. Should be a simple fix.

@TotallyInformation

If you drag the palette to the top section and try to drag the flows to the bottom section, it mostly doesn't work.

Yeah, this is something to work on. I've grown used to it whilst getting everything else working; but does need making more reliable.

@TotallyInformation

Oh, and the "Search flows" input does not stretch the full width of the panel.

Nor does it in Node-RED 2, 3 or 4.... so at least we're being consistent There is a thought to removing that search box entirely in favour of a search button that opens the standard Ctrl-f dialog.

@Buckskin

I liked the ability to drag & drop the contents of the panels, this is no longer possible. If drag and drop is no longer an option the order of icon selection could be used to position the panel contents (first click is at the top)

I don't quite follow what you mean here. We've never supported drag & drop of the panels themselves; the reordering is done by dragging the buttons around. But the currently implementation is a bit too fiddly - as @TotallyInformation has commented on.

@Buckskin

The icons on the bottom is OK but it would be better if they were in a footer along with the zoom controls etc.

One of the design concepts is to reduce the number of hard borders in the editor and have content floating over the workspace. Clearly there's a balance to be struck here.

[Buckskin]

@knolleary

We've never supported drag & drop of the panels themselves; the reordering is done by dragging the buttons around.

I had forgotten that. However, moving the buttons is a bit iffy. As soon as one is clicked and dragged the others either disappear or bunch up so it is tricky working out where to drop the dragged icon. Having only two buttons (as the default left side) works OK.

Is only allowing 2 pane contents deliberate?

It is also difficult to select more than 1 icon at times. Not sure what affects the selection but sometimes it works, and then it doesn't. When it works once it continues to work until an icon is moved.

[dceejay]

So far I'm liking it... - I guess I may be biased - but it's much better than previous beta - and is definitely better than 4.x IMHO.
Only wrinkle for me so far is the CSS rounding and left alignment of tabs in top bar compared to the neighbouring panels. Also the unused tabs should have some distinct outline at least, rather than just floating.

EDIT - actually there is a separator between the tabs that is visible in a real browser... just not when running the beta in netlify. However then the "tabs" seem a bit jammed up against the top bar...

[jbudd]

I'm afraid that allowing nodes to peek under the left and right columns does not sit well with me.

And now that debug node is down there, I cannot grab hold of it to move it back, the pointer never changes to the drag handle.

This is as far as it will let me drag a node to on the left

I don't intuitively understand those buttons, nor the thick grey line.
Once again, having dragged the node down there I can't drag it away again, though I can scroll down somewhat till it clears the buttons.

I am afraid I don't get a feeling of "more space" in the editor, sorry, it just seems faulty.

Mind you, it's much nicer without the left and right columns of buttons

[knolleary]

@dceejay

Only wrinkle for me so far is the CSS rounding and left alignment of tabs in top bar compared to the neighbouring panels.

Issue raised

@dceejay

EDIT - actually there is a separator between the tabs that is visible in a real browser... just not when running the beta in netlify. However then the "tabs" seem a bit jammed up against the top bar...

What browser is that with? It displays correctly in chrome (as per the screenshot at the start of the thread)

[dceejay]

Not on my Mac -
Chrome

Safari

Firefox

All consistent - Checked they were all at zoom 100%

[Aaqu]

Can the contrast be increased while editing the node? It's barely visible.

[TotallyInformation]

@knolleary

at least we're being consistent

But just not consistent within the new interface.

@dceejay

So far I'm liking it... - I guess I may be biased - but it's much better than previous beta

I apologise if I sounded negative. Overall, things are moving to a better place for sure.

Personally though I find the differing left/right panel design differences to induce some significant cognitive dissonance that is rather triggering.

@dceejay

Only wrinkle for me so far is the CSS rounding and left alignment of tabs in top bar compared to the neighbouring panels. Also the unused tabs should have some distinct outline at least, rather than just floating.

Now that you've mentioned the tabs, I can't say I like the current design. I agree that the unused tabs should indeed be a bit more outlined. Also, while the current white-space around them looks nice when you only have a few tabs, I think that anyone with a significant number is going to get frustrated by the large gaps. I will surely be reducing those using Stylus if they remain (just as I've reduced the excessive size and spacing of the Discourse edit panels! )

@dceejay

Not on my Mac

Nor on Vivaldi on Windows 11:

[cymplecy]

Just passing this on in case it's a bug - I'me pretty certain I didn't leave all this space above my flows but now I seem to have it since I upgraded from previous beta

[knolleary]

@Aaqu

Can the contrast be increased while editing the node? It's barely visible.

@Aaqu which bit in particular are you refering to? What is barely visible? Maybe a screenshot would help?

[knolleary]

@TotallyInformation

Nor on Vivaldi on Windows 11:

@TotallyInformation what is this 'nor' refering to specifically? Dave shared screenshots showing the tabs squashed to the top of the screen. Your screenshot looks as expected to me... Unless in missing what you're trying to highlight.

@dceejay the fact it's consistently misaligned for you suggests something else is causing that. Do you have any custom themeing applied? Can you share a list of contrib nodes you have installed (privately) in case one of them is doing something dodgy with unscoped CSS changes.

[Aaqu]

I think this needs improvement, the background dimming during node editing should be darker.
Especially when returning to a flow with a node still open after briefly looking away.

no edit

when edit

[dceejay]

why ? I still want to be able to read the rest of the flow to check status etc - and we don't want to make WCAG any worse than it is already by reducing contrast unnecessarily.

[Aaqu]

to make it more visible that I'm in editing and not in flow

[knolleary]

The level of shade applied when a modal dialog is open has been a topic of debate. There is one line of thought saying the shade should be gotten rid of entirely (I'm not personally in that camp).

With the beta, we lightened the shade to make it a more subtle effect. Having lived with it for a while, I am inclined to agree that it doesn't help bring focus to the edit dialog.

If we compare the before/after of 4.1 vs 5, you can see we had a much darker shade providing better contrast for 10+ years. So I think there is room for adjustment here.

|