🎉 Node-RED 5 Beta 3 now available

News
42

Can you position the mouse pointer on the highlighted node?
There is an option in Windows and Linux to highlight the cursor position when Ctrl key is pressed. I suspect this is turned on already for most people with eyesight problems, which currently does include me.

Can the highlighted node be placed at the centre of the editor screen?

43

I just searched the code and found it was disabled.

44

Quite possibly an oversight when I reviewed the changes. Will revisit to see how it looks with the new tab style.

45

I'm working on it now and can open a PR soon.

46

Done.

47

Hi Nick.

I dont want to be "that guy" (again) but NR5 beta still does not scroll the workspace horizontally with modifier + mouse wheel.

I know it was mentioned (and acknowledged) on a prev beta but cannot see an issue in the NR tracker (happy to admit my search foo may be off its game but I did search a few terms)

For reference: In NR4 and below, SHIFT + mouse scroll scrolls the workspace horizontally. In NR5 betas, the SHIFT modifier does not seem to work (workspace continues to scroll vertically)

Chrome latest on Windows 11.

Happy to raise an issue too if required.

48

Shift-scroll is scrolling horizontally for me with the beta on Chrome and Firefox on Mac.

Maybe a windows specific thing...?

49

I dont think so Nick:

50

I see the problem too, with Brave and Edge on Ubuntu with Gnome. The shift key appears to have no effect with the scroll wheel.

51

So basically, every OS/browser other than the combination I tested with....

Issue raised: UX: Shift-scroll not scrolling horizontally for some OS/browsers · Issue #5557 · node-red/node-red · GitHub

1 Like
52

So its a Mac thing then. :wink: :rofl:

Safari, the new IE. :frowning:

53

Curiously, this was Chrome on Mac. Either way, the fix is in (and confirmed by Steve) - Handle shift-scroll more robustly by knolleary · Pull Request #5559 · node-red/node-red · GitHub

1 Like
54

Experimenting with a better node highlight appearance:

  1. Use a halo around the node, rather than just its existing border - a better visual target to spot.
  2. Doesn't flash - could be contentious...
  3. Says in place for ~5s and then fades out.

image
image1084×596 30.1 KB

Thoughts?

3 Likes
55

Certainly an improvement in my view. :+1:

1 Like
56

Maybe 10 seconds?

2 Likes
57

If the mechanism is that the target node temporarily acquires a class "targetted" then we could highlight it as we wish via CSS, right up to throbbing and spinning if that meets our accessibility criteria.

58

Honestly, I sometimes find the node only and/or only fast BECAUSE it "flashes".

I call the current "flashing" subtle, not flashy. Perhaps an animation in a non obtrusive moving ants style?

I don't want to be offered more time findig the node. I want to find it fast.

BTW: A halo must not collide w/ node status etc.

A single "highlighted" (is this proper English?) node could be centered on the workspace w/o need of any further scrolling. Right now its location on the screen seems … random..

Cheers, Uwe

59

How about making it configurable?

60
  1. The color shall be one which is not common in the editor or e.g. an "inverter" color.
  2. Test it please also in zoomed out editor. Even there it shall be good recognizable.
  3. Better to use a thick line than a thin one.
  4. Since you cannot do it that way that everyone will like it, try to make it as configurable as possible (and then you will see, people won't use the configuration).
  5. I could image it also that way, that the cursor will be moved (additionally to those visual effects) to the node (but this feature must be configurable or a checkbox in the search form!), thus, a double click with the mouse would always open the found node.
  6. At the very end every improvement to the current situation would be greatly appreciated.
61

I know a random opinion from the internet won't change anything, but the previous UI and UX had much more sense to me.

Tabs in the browser and tabs in the Node-RED were working like briefcase tabs, connected visually with the content.
I click on the tab to see the page [in the browser].
I click on the tab to see nodes [in NR].
From top to bottom, like a proper hierarchy,

The new buttons are visually disconnected from the content, does not resemble mentioned logical briefcase tabs. Also, part UI for selecting content is on top [tabs, sorry - buttons for the editor], some on the bottom [tabs for the side panel] - striking lack of consistency.

My vote won't change the roadmap but still decided to write about it.

tabs
tabs1195×220 19.3 KB

3 Likes