Organise context menu for user testing with shortcut information

[microbit-matt-hillsdon]

Status quo

In the demo, the context menu for a block contains

• Duplicate
• Add Comment
• Collapse Block
• Disable Block
• Delete N Blocks
• Keyboard Navigation: delete
• Keyboard Navigation: copy
• Insert block above

It's already quite a confusing sequence. Separate issues also plan to add "Cut", "Copy" and "Paste".

Proposal

How about something like:

• Insert block above (I) [or more suitable text depending on nature of insert action, if we go with I then depending on font there's potential for I vs L confusion here]
• Delete N Blocks (Del)
• Duplicate

---

• Cut (Cmd + X)
• Copy (Cmd + C)
• Paste (Cmd+V)

---

• Add Comment
• Collapse Block
• Disable Block

Organisation is core keyboard nav actions, copy/paste, less commonly used actions. Likely I've missed some. I don't have a strong view re Duplicate.

On an "Edit" menu it's common for delete to be below paste but I think it makes sense paired with insert here.

Not sure if there's support for separators or how pretty we can make the shortcuts, ideally right aligned like this:

...but anything that exposes them is a bit step forward for user testing.

Tagging @kmcnaught for input.

[kmcnaught]

I'm generally very aligned with your approach @microbit-matt-hillsdon. I'm in favour of re-ordering to favour most common actions, and grouping with separators if possible.

A few random thoughts..

1. Q: Will the context menu content be different depending if it's triggered from a keyboard or mouse? If so, do we need the same/comparable ordering, or can they be completely independent?
2. Q: Which blocks are intended to have "Collapse Block" ? Currently in MakeCode I've only seen it in top-level blocks, but in blockly currently it's always present.
3. "Comment": probably needs a shortcut key, once comments are keyboard-navigable. I imagine many people don't comment, but once you start commenting, you probably do it quite a lot.
4. "Delete N Blocks": I still find this really confusing, especially with a Zelos/MakeCode-style renderer. Semantically I view myself to be deleting one block, and it happens to have children which naturally get culled too. Can we just call it "Delete Block"? Is this something someone else feels strongly about? In MakeCode currently it is actually "Delete Blocks" without the number, we weren't sure if that was intentional or an i18n oopsie. It makes more sense in geras, but I still view it similarly.
5. In MakeCode we have "Help". I presume we need to keep it, not sure if it comes from Blockly or MakeCode?
6. Since "Duplicate" is pre-existing, I'd probably by default put it where you have, but also have no strong view.
7. "Insert above" - I don't understand why the standard behaviour would be "above" and not "below", in the case where "here" is not appropriate. I'd expect children to build programs from top to bottom, so generally inserting below the last block. I can see that if you skip stack connections then you need "insert above" to get anything to go above the top-most block in a stack, but for me that's another argument against skipping stack connections 😆 In the case where you don't skip stack connections, I'm not even sure we need an "insert" at all, for a block with prev/next connections.

[rachel-fenichel]

https://github.com/google/blockly/pull/8767/files will add support for separators (but not before testing, since it's against rc/v12).

Q: Will the context menu content be different depending if it's triggered from a keyboard or mouse? If so, do we need the same/comparable ordering, or can they be completely independent?

Yes, that's one of the requirements I've recorded in #155. But we won't get that for testing.

[rachel-fenichel]

"Delete N Blocks": I still find this really confusing, especially with a Zelos/MakeCode-style renderer. Semantically I view myself to be deleting one block, and it happens to have children which naturally get culled too. Can we just call it "Delete Block"? Is this something someone else feels strongly about? In MakeCode currently it is actually "Delete Blocks" without the number, we weren't sure if that was intentional or an i18n oopsie. It makes more sense in geras, but I still view it similarly.

Controlled by displayText in the context menu definition for delete, and can definitely be updated.

[cpcallen]

7. "Insert above" - I don't understand why the standard behaviour would be "above" and not "below", in the case where "here" is not appropriate.

The behaviour is always "insert here", regardless of the wording or cursor location, but in one of our recent Blockly / micro:bit coordination meetings some concerns were raised about (plain) "Insert" when the cursor was on a block rather than between blocks, so I added "above" to make clear where the new block goes with respect to the block the cursor is on.

The actual implementation is (as noted previously) equivalent to when dragging from the toolbox: if the cursor is on a block, then that block is disconnected and the new block is put in its place, and then the original block is reattached to the new block if possible (and, in the case of value blocks, provided the new block has only a single value input). In the case of stack blocks, that has the effect of inserting the new block between the block the cursor is on and the block above it. In the case of value blocks in the Geras renderer this inserts 'to the left', while for value blocks in Zelos this inserts 'around this block' (but in neither case do we provide any special description beyond "here").

I'd expect children to build programs from top to bottom, so generally inserting below the last block.

Likewise, and I expect that they will do so by putting the cursor on the bottom-most next connection (which is always a valid cursor location) and pressing enter.

[kmcnaught]

Thanks for the clarification 👍

[rachel-fenichel]

#234 (comment) says this is now fixed for user testing.

[rachel-fenichel]

I went through Kirsty's question/comment list and filed the remaining work as separate issues that are tracked in the accessibility project. None of the remaining ones need to be finished for testing.

Q: Will the context menu content be different depending if it's triggered from a keyboard or mouse? If so, do we need the same/comparable ordering, or can they be completely independent?

As mentioned above, this is tracked.

Q: Which blocks are intended to have "Collapse Block" ? Currently in MakeCode I've only seen it in top-level blocks, but in blockly currently it's always present.

Filed as #266

"Comment": probably needs a shortcut key, once comments are keyboard-navigable. I imagine many people don't comment, but once you start commenting, you probably do it quite a lot.

Filed as #267

"Delete N Blocks": I still find this really confusing, especially with a Zelos/MakeCode-style renderer. Semantically I view myself to be deleting one block, and it happens to have children which naturally get culled too. Can we just call it "Delete Block"? Is this something someone else feels strongly about? In MakeCode currently it is actually "Delete Blocks" without the number, we weren't sure if that was intentional or an i18n oopsie. It makes more sense in geras, but I still view it similarly.

Filed as #265 because I think we should at least discuss making this change broadly for Zelos users.

In MakeCode we have "Help". I presume we need to keep it, not sure if it comes from Blockly or MakeCode?

Blockly supports help as either a URL or a function. The context menu option is hidden if help is not defined, which is the case for the drawing blocks that I created.

Since "Duplicate" is pre-existing, I'd probably by default put it where you have, but also have no strong view.

No work needed.

"Insert above" - I don't understand why the standard behaviour would be "above" and not "below", in the case where "here" is not appropriate. I'd expect children to build programs from top to bottom, so generally inserting below the last block. I can see that if you skip stack connections then you need "insert above" to get anything to go above the top-most block in a stack, but for me that's another argument against skipping stack connections 😆 In the case where you don't skip stack connections, I'm not even sure we need an "insert" at all, for a block with prev/next connections.

We're already discussing insert in #132 so I don't see it as a blocker for closing this issue.