[5377] UX: Ensure menus handle vertical overflow #5448
[5377] UX: Ensure menus handle vertical overflow #5448knolleary merged 4 commits intonode-red:devfrom
Conversation
Node-RED Contribution: Written Explanation 📝🧪 See my test plan and proposed changes here. 1. What did you choose to build, and why?Problem Selection 🎯I chose to address Issue #5377: "UX: Ensure menus handle vertical overflow" from the Node-RED repository. The original issue: "Our current menus (main menu, context menu) do not cope well if there is not enough vertical space to show them. If the bottom is off-screen, the options need to be scrollable so they can be accessed." Why this problem:
My Interpretation 🧩The core challenge was: How do you enable vertical scrolling on a menu while allowing submenus to escape horizontally? The submenu problem I discovered: While testing the initial vertical scrolling implementation, I noticed a critical UX issue: when adding This wasn't explicitly mentioned in the original issue, but I recognized it would create a poor user experience. Users wouldn't be able to access submenu items if the parent menu needed to scroll. I decided to scope this into the fix to ensure a complete, polished solution. What I Focused On ⚡Core functionality:
Implementation locations:
What I Intentionally Left Out 🔪Scope decisions:
Implementation Tradeoffs ⚖️Architectural choices:
Accepted technical debt:
These are acceptable tradeoffs for the timebox, but would be good candidates for follow-up improvements if the implementation is adopted. 2. How and why did I use AI? 🦾I used Claude (Anthropic's AI assistant) extensively throughout this work. Here's how: The Brainstorming Phase: What Didn't Work 🪦I explored several CSS-only approaches (wrapper elements, overflow tricks, The Final Solution: Taking Modern Libraries as Inspiration 💡After these dead ends, I realized this is a solved problem in the positioning library space. Libraries like Floating UI (the modern successor to Popper.js) exist specifically to handle floating element positioning - tooltips, dropdowns, and popovers that need to escape overflow containers with intelligent collision detection and flip behavior. This sparked the key insight: rather than reinventing the wheel, study how battle-tested libraries solve this problem, then adapt those patterns to Node-RED's vanilla JS architecture. 🔍 AI helped me research Floating UI's approach and understand its core algorithms, but the strategic decision was mine: instead of adding the dependency, replicate its core positioning patterns in vanilla JS matching Node-RED's existing style. Why not just use Floating UI directly? Floating UI would have solved this elegantly, but Node-RED intentionally avoids frontend dependencies (the editor package.json has zero npm dependencies). Adding it would introduce new maintenance overhead and set a precedent inconsistent with the existing editor architecture. Instead, replicating Floating UI's well-documented positioning patterns in vanilla JS respected the project's philosophy while delivering the same functionality. What AI Helped With & What I Did Myself 🤖 🧠AI handled (80% of code generation):
I handled (100% of decision-making):
Tradeoffs in AI usage: 🎭 I chose to use AI heavily for code generation because:
I retained control over decisions because:
This balance let me deliver a working solution within the timebox while ensuring it fit Node-RED's architecture and standards. Summary 🎬This contribution was intentionally scoped to fit a 2–3 hour timebox while still delivering a complete, user-safe solution. I focused on solving the underlying UX problem rather than applying a partial fix, even when that meant identifying edge cases not explicitly called out in the original issue. I made deliberate tradeoffs to align with Node-RED's existing architecture and philosophy, favoring minimal dependencies, small surface area changes, and predictable behavior. AI was used as an accelerator for exploration and implementation, but all architectural decisions, scoping choices, and UX validation were made deliberately by me to ensure the solution fit Node-RED's standards and user needs. |
|
Thanks for the contribution and write up @n-lark I'll review the details and feedback. |
…serving submenu pop-out behavior
…th keyboard shortcuts and icons on submenus
n-lark
force-pushed
the
5377/ux-menu-vertical-overflow
branch
from
3c3a2f1 to
b6cb9e0
Compare
n-lark
changed the title
knolleary
left a comment
knolleary
left a comment
There was a problem hiding this comment.
A couple of suggested changes to fix up a couple behaviours that didn't feel right to me.
- Context menu: move it up if possible to avoid scrolling. If scrolling unavoidable, use the full height available.
- First tier of Submenus: make them scrollable if necessary.
knolleary
left a comment
knolleary
left a comment
There was a problem hiding this comment.
Have applied a couple changes - looking good now
2 participants
Proposed changes
Resolves #5377
🧪 See my test plan and proposed changes here.
📜 See my written explanation here.
Checklist
npm run testto verify the unit tests passNote on CI test failure:
The 1 failing test
watch Node - should watch a file to be changedis unrelated to my changes - it also fails on master.My changes only touch menu/UI files (menu.js, tabs.js, contextMenu.js, SCSS), none of which interact with the file watcher node that I am aware of. Happy to log a separate issue for this test if helpful!