Entering node selection

[johannesmutter]

Entering node selection (desktop + mobile)
Consolidates #248, the selection sub-thread in #322 (comments), and the mobile aspect of #259. Related: #53, #336.

Problem — The only ways into node selection today are the ESC key and the toolbar's select-parent button. That is an extra step, not discoverable for new users, and pointer/touch users have no direct path (#248).

Constraints (per discussion in #322) — Desktop-first ¹, one implementation path, no mobile-only code paths ². Nothing may battle native selection while we rely on it. Editing infrastructure is at its code-size limit. Ideal end state: no visible chrome at all; ESC stays as a keyboard shortcut only.

Approaches side by side

Approach	Desktop	Mobile	Discoverable	Conflict risk	Cost
ESC + toolbar << (status quo)	yes	yes	low	none	done
Direct click/tap on node frame (Figma-like, #248)	yes	yes	medium	edges occupied by node gaps and text hit areas; tricky hit box design	medium
Floating handle / action zone (⠿ Notion, Craft)	yes	yes	high	occupies layout space; but can fit where whitespace is likely: bottom right near edge or top left near edge	medium
Meta key + click	yes	no	low	none	low
Swipe left on node, repeat to ascend (Craft)	only trackpad	yes	medium	back and forward navigation. (no risk for: native selection, scrolling ... as falsely assumed) mobile-first code path	high
Long press	no / (right click)	yes	low	iOS callout and preview gestures	medium

Swipe gestures and direct node click is the only chrome-free approach (matches the ideal end state), with a lot of work it can work identically on both platforms. It doesn't fight native selection, only back and forward navigation, but also manageable. A visible handle scores highest on discoverability and could later double as drag-to-reorder and menu anchor, but it is permanent chrome, but it can also be designed to be unobtrusive.

Proposal

• For now: keep and optimize ESC + << (contextual, hidden at top level).
• Mid term: clicking/tapping a node's non-text area selects it (needs exploration first);
• Later: Gestures (app land only?)

To experiment

• Prototype direct node click in empty space;
• Edge case testing for "no native-selection interference on iOS/Android"
• Decide descend/ascend click semantics

Footnotes

1. Desktop first needs a more clear definition, e.g. is it meant as "desktop only" or "no mobile optimizations". Need to clarify if this is about priority of tasks, or something else e.g. principles like low LOC. Also not clear if desktop first refers to fine pointer input vs. touch screen or screen size, as an iPad Pro is desktop in size but touch and a remarkable with stylus is fine pointer, but small screen. Or is it very specific like: Chrome on a MacBook Pro with trackpad/ mouse? ↩

2. no mobile-only code paths: needs clarification because clearly there are already dozens of mobile related optimizations. What is the difference between a viewport size optimization and a pointer (touch vs. click) optimization? E.g. is meant that there should not be mobile only or desktop only features. So unclarity is mainly about where to draw the line. ↩

[michael]

Thanks for consolidating the related issues.

Few clarifications:

• by desktop-first, mobile-second I just mean: The main navigation paradigm is aimed at a desktop with a keyboard (ipad with an external keyboard i also consider a desktop). I expect 90% of editing time spent on desktops. But mobile support is an important thing, even if less time is spent mobile editing. You can make quick fixes, upload an image right after shooting it etc. The web-platform (especially Safari deliberately) is degraded on mobile for editing, so we have to live with certain limits, and also consider that it takes considerably more time and workarounds to make mobile behave as you want it. E.g. for the input/composition events it took nearly 5x time than make all desktop browsers work. So with mobile-second I mean, "I only want to invest a reasonable amount of time to make everything work on mobile (that includes reviewing and testing, and the risk of regressions when improvements are made)."
• No-mobile-only code path is too strict: As little as possible and justifiable.
• If swipe left/right only overrides back/forward navigation and not conflict with click/drag-to-select that would actually be perfect. Just not sure if people will get that, because mobile apps with that swipe-to-delete/archive etc. gesture allow you to start the swipe from the middle of the screen. Not sure if the back/forward gesture is very discoverable?

[johannesmutter]

Not sure if the back/forward gesture is very discoverable

Yes discoverability is not great. But also not worse than the escape icon button. There's no familiar symbol to "select parent" yet, so this also has to be taught to the user. An additional label "select parent" would make it more discoverable, but at the cost of space in the toolbar.

For the gesture one could do what iOS did with slide to unlock: a shimmering animation that visualises the gesture to first time users.