I think you mean scrollbars.
Noted. Will refine what's there on both fronts. The scrollbar already has bigger box than what you see to help make it easier to grab - outlined in red in the image below. We can increase that a bit more, as well as improve the contrast of the visible part against the background.
Noted. The behaviour is definitely better than beta 3, but yes, still more work to be done when moving between the sections.
3 Likes
@Tinbum1 what browser/OS are you using? There's a known issue with the monaco editor - out of our hands: [Bug] Paste action in Context Menu does not work and cannot be removed by api · Issue #5068 · microsoft/monaco-editor · GitHub
1 Like
Firefox on W10 machine.
This comment is specific to the floating edit dialog (previously docked to sidebar). Please let me know if this thread isn't the best place for this comment (i.e. if it was perhaps introduced in a previous beta).
As the edit dialog is now floating, we have less usable height (e.g. for lines of code in a function node).
For comparison, with my current browser window size:
- Current version: I can see 18 lines of code
- NR 5 Beta 4: I can see 16 lines of code
Option 1: reclaim dead space
WARNING - the following is visually offensive!
Yeh obvs the above is gross. I would propose a complete re-design of the edit dialog.
Option 2: work on the "expand" mode to make it more usable
My current criticisms with expand mode:
- it requires an extra click to enter and exit, as well as opening and closing the edit dialog
- It introduces a small but noticeable delay because of the slide animation which must run twice when exiting expand mode and then the edit dialog
- the expand button is not accessible - no keyboard shortcut, small to visually locate and click (e.g. with trackpad on laptop)
- why do we have "Done" and "Cancel" buttons in expand mode? If you change your mind and want to abandon your code changes, you would just cancel out of the function node, not cancel out of expand mode to return the the function node. Perhaps the reason is UI consistency across the dialogs?
Either way I feel This UX can definitely be improved.
Option 2A - remember last view - not ideal
Introduce another expand button when already in expand mode: 
i.e. this will exit expand mode. Keep the Cancel / Done buttons, except this time, they will behave in a more intuitive way, i.e. they will actually cancel changes and exit, or confirm changes and exit. When you re-enter that function node, it remembers your last view (expanded / not expanded), preferably on a per-node basis.
This is not ideal, because (a) the behaviour of those buttons changing might annoy people (although it wouldn't result in lost work), (b) potentially more annoying when dealing with other node types that also happen to feature an editor. Sure you could press the expand mode toggle button to get back, but sometimes you want to hit Ctrl-Ent to get back to where you were before. BUT on balance, IMO this would be a huge improvement to workflow.
Option 2B
In expand mode, change the buttons, so instead of Cancel / Done, you'd have:
return to main edit dialog (whatever is in the text screen is returned to edit dialog. If user wants to abandon changes, they can just cancel out of the main dialog)
confirm changes and exit back to workspace (this button then takes on the same function as the main editor Done button).
Option 2C
(some other idea, more refined than the above)
3 Likes
Thanks for the useful feedback @hazymat
I had started playing with the edit dialog to see about improving its use of space. The only change between NR4 and 5 is that the bottom edge has pushed up slightly - but it all counts.
I did a quick experiment with moving the bottom edge down - so it doesn't align with the bottom of the sidebars. It was okayish, but the main issue was some quirks with the slide-in/out going over/under the sidebar tab buttons along the bottom. That led down the path of 'what if we got rid of the slide effect' - but it felt very abrupt when switching between the dialogs. I then remembered I was overdue to publish Beta 4, so parked all that work. So your feedback is very timely.
Another option is to move the done/cancel buttons to the bottom of the dialog and make better use of the space at the top. It's a far more traditional place for them... but when did we do traditional?
I really prefer the dialog buttons at the top!
Studying my own usage, I rarely use these buttons:
- properties
- description
- appearance
- help
- open library
- save to library
Perhaps they could be combined into a mini menu? Mocked up below (see button to right of "function 1")
That feels a bit linuxy / too minimal. But as it's such a massive real estate grab, it could cope with introducing back a little more nice spacing...
1 Like
Regarding the red shaded background.
Might be cool to show something useful about the state.
e.g. code validation.
Sometimes I close the editor without noticing my javascript code didn't validate (I missed the red wavy line 3 pages down...) so if the background is red, then I know code won't validate and it would save me from closing the dialog, realising it didn't validate, then having to re-open it again!
There was some discussion about the function node expand button at Make "Expand" button on function node config the same as on template node
Very interesting.
Though I'm not a fan of design by committee, might be a worthwhile exercise to discover how different users experience the Editor dialog. I could capture some of these points into a questionnaire and feedback results, let me know if that's useful to you @knolleary? e.g. something like this
.
.
Just a note that significant changes to layouts may break some existing nodes.
Not against some changes but it would likely need some careful coordination of the changes.
Oh, and just seen from the above screenshots. The gap between an edit tab line and the next row has disappeared so the layout in the new version now looks odd.
1 Like
Proud of you!
I really appreciate this and I want it said.
I do use [description] and [appearance] quite a lot. Actually I would like a "copy paste icon" functionality, extremely low importance though.
I write code in VSCode and copy paste, so I don't really notice this decrease of editing zone space / room (not a native english speaker).
I love the direction things are moving, proud excessive Node-RED user.
1 Like
I actually decided to have a little complaint before it's too late, I've made a video showing how I usually kept my zoom before the Beta. The O once and then a — (minus) once. That was perfect zoom for my screen, crisp, but in Beta the — zooms out too much, causing blur.
Looking around in the Live Demo (which makes it really easy to explore new stuff! 
) I realized that / it looks like the "slide in / slide out" handles of the (right hand & left hand) panels have fallen prey to the new design. There's still the action "Toggle sidebar" present - yet this only affects the right hand panels.
As a consequence, to move the panels out of sight, I now have to click 2 times (to deselect them) ... whereas before it was just once (to push them off screen). Technically, the result is the same - cognitive it's different.
I'd like to propose to bring this feature back into the editor.
A small idea regarding this:
(bottom right)
@kitwar that is the type of thing I've started mocking up.
The menu items to show/hide the sidebars are also in need of updating to reflect the new ability to move things around..
Just saw this:
I'm pretty convinced the nodes were vertically extended in earlier versions. Already documented?
System setup:
Welcome to Node-RED
===================
27 Mar 18:20:46 - [info] Node-RED version: v5.0.0-beta.4
27 Mar 18:20:46 - [info] Node.js version: v24.14.0
27 Mar 18:20:46 - [info] Darwin 25.3.0 arm64 LE
Browser >> Vivaldi:
Version: 7.9.3970.45 (Offizieller Build) (arm64)
Chromium Version: 146.0.7680.171
Plattform / OS: macOS Version 26.3.1 (a) (Build 25D771280a)
Hi @ralphwetzel
Can you check the core websocket nodes (in the network category) to see if they appear correctly? They look fine to me with Chrome. Can you share what modules you have that provide any of the nodes that don't look right?
Perhaps it was a false alert; sorry for that.
Portions of the DOM tree were significantly different ("broken"?) for those nodes that had the issue. Others were not affected & displayed correctly - both core and contributed ones. Refreshing the browser "fixed" it.
I'll report back if it happens again...
