Consider aligning duplicate with insert and copy/paste

[microbit-matt-hillsdon]

"Duplicate" is internally implemented as copy then paste, but the effect of the keyboard navigation plugin overrides for copy/paste but not for duplicate is for these two behaviours to drift apart when this plugin is in use.

Copy+paste inserts relative to the current cursor position and on #479 I propose paste should also paste in move mode. Duplicate just drops the block on the workspace offset from the current position.

Not sure if this should be another action override or a different approach that enables core to reuse the plugin's copy/paste behaviours.

[RoboErikG]

We'll also want to consider the behavior with a mouse. It might be very confusing for someone if they click a block, try to copy & paste it, and end up in a keyboard move with the mouse being ignored.

I'm not sure what the right behavior would be in this case or if it makes sense to have both copy/paste and duplicate. 🤔

[microbit-matt-hillsdon]

Yeah, I'm imagining this is for keyboard uses of the context menu entry and potentially a future keybinding directly for duplicate itself.

[microbit-matt-hillsdon]

We discussed this some more based on user testing feedback.

Motivations for change based on user testing:

• Copy/paste or duplicate is often to use the block elsewhere (easier than finding in toolbox). Duplicate can't target the elsewhere. Paste can, but often the user will copy then paste without intending an insert location. Resources often suggest a duplicate then move approach
• Connecting on paste can pop another block out or confusingly nest blocks
• Concern that connecting on paste combined with on-by-default keyboard nav might be an unexpected change for Blockly users (this is something I hadn't previously considered but we should review carefully).

Approach A

What if:

• Paste, duplicate and connect all dropped a block into move mode

Exposes mixed mode users to move mode. Potentially could depend on a keyboard nav heuristic? But it's a big behaviour shift. Feedback from Blockly on PR that proposed this that in other apps paste is in a fixed position so should be in Blockly too.

Avoids pop-out due to connection. Will still show previews of pop-outs that might be a bit weird.

Approach B

What if:

• Paste didn't connect (dropped on workspace as before)
• Duplicate remained as is (doesn't connect)
• Each operation popped a first-time toast explaining move mode
  • Problem: toast would be visible to mixed-mode users (could use keyboard nav heuristic?)

Closer to mouse behaviours.

Harder to duplicate blocks for e.g. a MakeCode LED animation where Ctrl-C, repeated Ctrl-V is currently easy.

Approach C

Approach B but we require move mode to be explicitly enabled providing more consistency between insert and paste/duplicate. We've not user tested anything similar to this and it was generally felt that move-mode by default was successful in user testing.

Other notes

We also pondered whether paste should not connect but only if you Ctrl+C/Ctrl+V without moving the cursor in between. @kmcnaught noted: My instinct is this would more often match the expected user behaviour, but be hard to explain/justify the inconsistency.

Leaning towards approach B but I'd like to try it out.

[kmcnaught]

There's such a tension here between:

• existing behaviour and user expectations
• what would be a sensible/expected for keyboard users
• what would be a sensible/expected for mouse users
• a desire to keep keyboard and mouse behaviours as aligned as possible to make instructional resources consistent.

I'm sketching out a version of behaviour that feels like about the best compromise to my personal predilections, but I recognise I have less direct experience watching kids use the current implementation in mouse mode, their expectations of Duplicate, and how much scope we have to change this behaviour. This overlaps with Matt's suggestions above, but I'm finding it hard to reason about any suggestions without mapping out everything. I'll discuss offline with @microbit-matt-hillsdon to see if we're in the same place or not.

Alternative 1

Duplicate:

• There should be a keyboard shortcut for Duplicate that is separate to Copy, Paste.
• This always pastes on the workspace
• Behaviour is identical for mouse and keyboard users
• (??) Except maybe you could argue for putting it in move mode based on keyboard heuristic

Copy and Paste for mouse user: (based on keyboard nav heuristic)

• Paste puts the block where the current cursor is.

This means:

• If the user clicks on a statement block, copies and pastes, it will be inserted underneath it
  • This changes the current behaviour, which may not be acceptable
  • Based on keyboard nav heuristic, it won't be in move mode.
• If the user wants it disconnected, they need to click on the workspace before pasting
  • I think this is a reasonable / not surprising UX, even though it is a change from the status quo
• If the user wants it somewhere else (e.g in an animation Show icon / pause / show icon / ...) then they can click on the target block before Paste
  • This saves on a drag operation which benefits a lot of existing mouse users
• If they use arrow keys to move, the keyboard nav heuristic will kick in, and they will be in move mode and have to press Enter to confirm
  • This may feel inconsistent

Copy and Paste for keyboard user: (based on keyboard nav heuristic)

• Paste puts the block where the current cursor is, in move mode
  • I found it weird following the user testing tutorial when insert went to move mode but paste didn't.
  • Avoids unexpected popouts, but you might still get a preview of one.

Alternative 2

Duplicate:

• There should be a keyboard shortcut for Duplicate that is separate to Copy, Paste.
• This always pastes on the workspace
• Behaviour is identical for mouse and keyboard users
• (??) Except maybe you could argue for putting it in move mode based on keyboard heuristic

Paste:

• If the cursor has not moved since copying the block, paste on the workspace.
  • (??) If keyboard nav heuristic, put it in move mode, otherwise don't. (optional)
• If the cursor has moved, paste it in the designated place.
• This applies to all users, since a mouse user could click another block to set the cursor / desired paste position
• This would not change the behaviour for existing users who use Ctrl+C, Ctrl+V as an equivalent to Duplicate. But it would change the behaviour in cases where the user clicks another location first
  • I think this is useful behaviour.

[rachel-fenichel]

We discussed this a lot yesterday and could not come to a conclusion that we were all happy with about how to conditionally paste/duplicate into move mode.

Using Ctrl/Cmd+V does not guarantee that the user is aware of keyboard shortcuts. Pasting or duplicating into move mode is a very bad experience for a user who doesn't know that those modes exist. Pasting/duplicating onto the workspace near the mouse pointer or cursor and then pressing m to start moving is annoying for a full keyboard user, but annoyance is less bad than getting into a state the user doesn't understand and has to explicitly exit. I lean conservative on this, given the large user surface.

Desired behaviour for release:

• Both duplicate and paste put the block on the workspace near the selected block or context menu location (depending on trigger).
• The new block is not in move mode.
• The new block is selected after paste/duplicate.
• Keyboard users must press m to move the block after a paste/duplicate.
• No heuristic is used to guess who is a mouse user and who is a keyboard user.

To reduce the number of steps needed for keyboard-only users, we could add a single-key shortcut to paste into move mode. I would be more comfortable with that change, because it would be opt-in.

I do not have strong opinions about Duplicate one way or another. Since it already existed as a context menu option, the default is for it to stay in place. But I prefer to train users to use copy/paste as much as possible.

If we get a keyboard nav heuristic that we are happy with and that mitigates the potential for users to accidentally end up in move mode without knowing what is happening, then we can change the paste behaviour in a future release.

Impacts on related issues:

• pasting a variable on top of itself - pseudo-duplicate #484 : Don't connect on paste, which will resolve the pseudo-duplication.
• Unexpected paste position for conditional statements #419 Don't connect on paste. Put the block on the workspace.