Enter key behaviour when on a block

[cpcallen]

What should happen when you navigate to a block on the workspace and then press enter?

• Select (for copy/paste)?
  • But at the moment navigating to a block selects it automatically, so this would be a no-op currently.
• "Pick up" the block to begin dragging it?
  • See Make it possible to move blocks on the workspace #106.
• Move cursor to toolbox to replace?
  • This is similar to the behaviour planned for connections in Make placing blocks using the marker more intuitive #102.
• Move to first/only field (possibly on shadow block?) and edit it?
  • This would help address Add affordance to indicate users can navigate within blocks #105.

[rachel-fenichel]

Summary of discussions between micro:bit and Blockly on November 12-13, 2024:

Most locations have multiple possible actions, and the default action would vary significantly by location type. This means that the user needs to already know a lot about the system to predict the behaviour of a default action, and a user who didn't know the system would struggle to understand why Blockly responded the way it did.

Instead, we decided that:

• Rather than try to intelligently guess which action to take, we're going to make Enter open the context menu.
  • Tracking issue: Keyboard navigable context menus #130
• The context menu will contain a list of available actions
• Each action will have a keyboard shortcut noted next to it
  • The shortcut will work from within the context menu, but will also work directly from the workspace at that location.
• Onboarding/tutorials would teach the user that they can press Enter to see available actions, but can also bypass the context menu and use the shortcuts directly.

[rachel-fenichel]

There is a long list of available options on a block. We will likely implement all of these and then experiment and trim down the list to make it manageable.

Possible actions:

• Edit
  • Only visible if the block has a single field
  • Opens that field's editor.
• Replace
  • Opens the toolbox to select a replacement block. Bumps the replaced block out to the workspace, as we do with dragging.
• Disconnect (or a different verb)
  • Disconnect the block and pick it up to start "dragging" with the keyboard.
• Delete
  • Delete the block
• Copy
• Duplicate
• View tooltip
• View help

[joreneng]

Currently, pressing Enter on an input socket opens the last-used toolbox category. One of the questions the users posed was: Would it be possible to modify the flyout to show a contextually relevant category or blocks to the input socket in focus?

[cpcallen]

We have certainly discussed having the toolbox only show blocks relevant to the current cursor location. This made a lot of sense when we had only a location-first workflow for inserting blocks, where the user had to select the location to insert a new block and then choose the block.

Now that users can choose the block first, and then decide where to place it this is less essential than it was, and moreover there is a new problem: we previously had the i insert shortcut, which could be taken as signalling the user's intention to insert a new block at the current location, but this was removed in favour of the (now essentially identical) t move to toolbox shortcut, so the question is how to tell whether the user intends to insert a block in the current cursor location (in which case showing only relevant blocks would be useful) or whether they are only intending to select a block to place somewhere (in which case all blocks to be shown).

The enter key on empty connections would certainly be a useful signal here, but it is essentially vestigial: we previously allowed the user to put the cursor on any connection, but now only unconnected value connections are legal cursor locations, and many developers that use the Zelos renderer make such heavy use of shadow blocks that there are few even of those.

So I think the idea still has merit, but it's no longer clear exactly how it should work.