UX for inserting top level blocks

[kmcnaught]

Starting a discussion to confirm different people's expectations of how a user would deliberately choose to insert a top-level block. Note that:

1. For micro:bit upcoming user tests, we are happy with the current behaviour (your cursor can be anywhere, but a top level block gets pushed out to the top level) and we will keep an eye out for other user expectations.
2. For MakeCode, this UX is much less important than for other applications. In micro:bit MakeCode AFAIU, event-driven "C shaped blocks which could have a hat" (please give me better language for these!) can only be placed at a top level, and blocks with an in/out connection cannot be placed at a top level. So the current behaviour doesn't prevent anyone achieving what they want because there is no ambiguity. It just might be confusing for some people who are thinking more deliberately about where to place a block.
3. For MakeCode, the exact positioning of blocks is much less relevant since top level blocks are generally event driven, so the relative x,y position is rarely significant. Most users would never need to precisely control it, although we expect users to want to reposition for aesthetic / structure (e.g onButtonA adjacent to onButtonB)
4. For other applications that can exectute any block at the "top level" this will be much more important

In all cases, I think we are agreed that trying to add a top level block when your cursor is in the middle of a stack of blocks should result in a successful insert, at a new top-level location. What is less clear is how a user chooses this location first, if they so desire.

From my perspective, there are a few different versions of UX flows that we might be heading towards, which I just wanted to clarify what people are picturing...

Version 1 - modal switch to workspace 2D navigation

• User's cursor is originally inline between/on code blocks when they decide to place a new top-level block
• User presses a key/shortcut combo to switch to 'workspace navigation'
• Cursor moves to somewhere sensible (??) nearby on the workspace (not sure what to expect here, presumably 'close but clearly separate from the blocks' ?)
• Arrow keys navigate the cursor on the workspace
• Pressing 't' for toolbox or Enter or some context-menu based insertion flow (consistent with elsewhere) takes you to the toolbox
• Select a block
• It gets placed at the top level
• Cursor is placed inline under it, or in it (for a C shaped block)

Version 2 - modifier-key based 2D navigation

I think this is mentioned in #129, similar to above but non-modal

• User's cursor is originally inline between/on code blocks when they decide to place a new top-level block
• User holds down a modifier to switch to 'workspace navigation'
• Arrow keys (with modifier) move the cursor in 2D until they have put it where they want their new block to be placed
• Pressing 't' for toolbox or Enter or some context-menu based insertion flow (consistent with elsewhere) takes you to the toolbox
• Select a block
• It gets placed at the top level
• Cursor is placed inline under it, or in it (for a C shaped block)

I suspect this is where @cpcallen is heading. I like that it's not modal. It also makes the choice of where to put the cursor when you 'disconnect' simpler, since you are actively dragging it around.

Version 3 - extra cursor location(s) available on workspace without 2D nav

This version does not preclude the need for @cpcallen's arbitrary 2D nav, but gives a simpler option for users who don't require exact 2d positioning (e.g. in MakeCode). I am in favour of considering this.

• User's cursor is originally inline between/on code blocks when they decide to place a new top-level block
• User presses up/down to navigate through, and then leave the current stack of blocks
• There is a single workspace cursor location at the end / between each stack of blocks
• The user moves to one of these workspace locations
• Pressing 't' for toolbox or Enter or some context-menu based insertion flow (consistent with elsewhere) takes you to the toolbox
• Select a block
• It gets placed at the top level
• Cursor is placed inline under it, or in it (for a C shaped block)

There's some slight nuance in where you would put the workspace cursor location, and how it might interfere with overlapping block layouts etc, but I think it's workable. A bit like the 'insert new item' UX in a kanban-style github project:

It would be helpful to clarify if version 2 is definitely the way you are heading, and if there's scope for something like version 3 as an option, or if you have opinions on any nuance on the different UX flows.

[Edit 21/02/25: hopefully improved some language describing different blocks]

[rachel-fenichel]

event-driven "C shaped blocks which could have a hat" (please give me better language for these!)

We just call them "hat blocks". The fact that it's C-shaped isn't actually critical. Scratch does hat blocks with no statement input to represent the same thing: