Rationalise the context menu

[microbit-matt-hillsdon]

Block context menu via mouse:

• Duplicate
• Add Comment
• External Inputs
• Collapse Block
• Disable Block
• Delete 2 Blocks (Del)
• Cut (Ctrl + X)
• Copy (Ctrl + C)
• Paste (Ctrl + V）

Context menu via keyboard:

• Duplicate
• Add Comment
• External Inputs
• Collapse Block
• Disable Block
• Move Block (M)
• Insert Block (I)
• Edit Block contents (→)
• Delete 2 Blocks (Del)
• Cut (Ctrl + X)
• Copy (Ctrl + C)
• Paste (Ctrl + V）

Questions:

• Are there any we just want to drop at this point?
  • We've moved to signposting users to the help rather than the context menu when they hit enter on a block (via toast in feat: toasts for move/cut/copy and enter on a block #230). Do we still need "Edit Block contents"?
  • I think I could be persuaded to drop almost anything at this point. Needs broader input on whether the new items are
    • useful for discovery still
    • useful for users who have issues accessing certain keys / benefit from being able to use functions with fewer keys needed
• Do we want the keyboard shortcuts there for mouse users? I think yes, but I think we have to make them pretty (i.e. right aligned, maybe grey, compare OS renderings).
• The ordering feels arbitrary to me for keyboard users. If we think these actions belong on the context menu then I think there's a case for them being at the top:
  • Move Block (M)
  • Edit Block contents (→)
  • Insert Block (I)
• "Insert Block" feels like the odd one out to me as it doesn't act on the block as such, but relative to it.

This is something of a brain dump issue and would benefit from more input and then some discussion. I guess I'd really like to sample everyone's level of happiness with the status quo.

[rachel-fenichel]

Discussion question for tomorrow:

• Do we still want to have non-mouse items available in the context menu (conditionally)?

My thoughts:

• I originally was very in favour of this because I thought it was important to give users an option to directly trigger actions from a list, rather than needing to open the help sidebar, look for the action, and then press the appropriate keycode/combination.
• I thought this was a way to reduce necessary mental overhead, particularly when the shortcut menu visually obscured the entire block workspace, requiring the user to hold their blocks in working memory.
• I am less convinced now that we have an example of a help menu that opens to the side and does not obscure blocks.
• I would be fine with getting rid of the keyboard nav options in core, if the following are met:
  • Shortcuts can be triggered on the workspace while the shortcut help menu is open
  • Opening the shortcut help menu bumps the blocks over so that the block context is still visible while the menu is open. (I'm slightly concerned that this is impossible at high levels of zoom)
  • Onboarding teaches the user the main keyboard shortcuts (insert, delete, drag) and teaches them how to open the shortcut help menu.
• Ideally also it would be possible to navigate through the shortcut menu to a specific item, and press enter to activate it.

[rachel-fenichel]

Second question for tomorrow (can split into a new ticket if we decide to do more work here):

Do we want the keyboard shortcuts there for mouse users? I think yes, but I think we have to make them pretty (i.e. right aligned, maybe grey, compare OS renderings).

[kmcnaught]

Do we want the keyboard shortcuts there for mouse users? I think yes, but I think we have to make them pretty (i.e. right aligned, maybe grey, compare OS renderings).

Yes please

The ordering feels arbitrary to me for keyboard users. If we think these actions belong on the context menu then I think there's a case for them being at the top:

Agreed re placement. The only one still feeling significantly useful in terms of sign-posting is "Move block (M)". We are potentially losing "I to insert" and relying on onboarding to teach region navigation and right arrow. Is there an argument for "Move block (M)" being in the context menu unconditionally? It would add discoverability to keyboard controls for mouse users who might benefit.

[rachel-fenichel]

Conclusions from discussion today:

• On the Blockly side, we will default to not showing the context menu items for actions
• On the Blockly side, we will export functions to install actions into the context menu
• MakeCode/micro:bit still need to decide which actions they want to show (but that's a per-application decision)
• @gonfunko will make the keyboard shortcuts look nicer when present in the context menu