Make it possible to move blocks on the workspace

[cpcallen]

It should be possible to choose where to place newly-created blocks on the workspace, and to move existing blocks to new locations.

There should be a new mode that shall be in effect while a block is being moved (i.e., while it is 'picked up', as described below).

There should be two types of movement, which the user can easily and seamlessly (but not unintentionally) switch between:

1. Constrained movement: the block can be moved only between valid positions (for that block) within existing stacks.
2. Unconstrained movement: the block can be moved to any xy position on the workspace.

Specifically:

• Starting a move: There should be a shortcut with corresponding block context menu item (at least when the context menu is opened via keyboard shortcut) to move the currently selected block. When this option is selected, the block(s) will be 'picked up', and keyboard navigation will switch into 'move mode'.
  • When a block that is in a stack is 'picked up', it should be removed the stack, replaced by an insertion marker (or equivalent affordance, e.g. Rudolph), and moved slightly aside so as to not entirely occlude the insertion marker etc..
  • When a new block is created by use of the keyboard (e.g. by navigating to a block in the flyout and pressing enter), it should initially be created in 'picked up' state:
    • If the workspace cursor was at a valid connection point for the new block, it should be as if the new block had just been picked up from that location (e.g. an insertion marker should be shown) except that if the move is aborted the newly created block should either be deleted.
    • Otherwise it should positioned nearby to the location of the workspace cursor, as if it had been moved there via unconstrained move.
  • When a block is 'picked up', it should be drawn with a suitable affordance to indicate that it it is being moved—e.g. a drop shadow.
• Constrained movement: Absent any modifier keys, pressing the cursor keys should move the block to the next valid connection in the given direction:
  • If the moved block had not been denoted (by shadow etc.) as being connected to a valid connection point, then it should be moved to the next nearest valid connection point in the general direction of the cursor key if there is one, or to the nearest valid connection point in any direction, if there are any. (See below re: if there are no valid connection points.)
  • If the moved block had been denoted as connected, then it should be moved to the next valid connection point in navigation order, subject to the proviso that it be possible to reach every valid attachment point by some sequence of arrow key presses.
• Unconstrained movement: when a chosen modifier key is held down and an arrow key pressed, the block should be moved a short distance in the chosen direction.
  • The default modifier should be shift, but this should be configurable by the developer and/or user.
  • The distance moved should be (approximately) one grid point, and to the nearest grid point if snap-to-grid is enabled (and perhaps even if it is not).
  • As when dragging a block using the mouse, if the block being moved comes or remains near a valid attachment point, an insertion marker (or similar) should be shown.
• Finishing a move: When enter is pressed, the block should be 'put down':
  • As with dragging a block using the mouse, if an insertion marker (or similar affordance) had been shown then the block should be connected to the relevant connection point and any existing block at that connection either attached to the newly-arrived block or disconnected and bumped.
  • The cursor should be be moved to the placed block (i.e., that block should have focus).
  • Keyboard navigation will exit from 'move mode' and resume normal (cursor focus) navigation.
• Aborting a move: When escape is pressed, the block being moved should be returned to its original position or, if it was newly created, be deleted.

Points for further discussion:

• As proposed above, creating a new block that can be placed at the cursor's current location will result in it being placed there, if only the user presses enter.
  • This would seem to largely obsolete the marker workflow (as described in Make placing blocks using the marker more intuitive #102), though there are some differences (whether the new block is initially 'picked up' or not, and potentially whether the user is constrained in their choice of block type).
  • On the other hand, if the block they chose could not be placed at the cursor's location, it would be placed nearby but unconnected, as if it had been placed at that location by unconstrained move. This might be confusing for unsighted users, though (as it would still be 'picked up' a single (unmodifier-ed) arrow keystroke would attach it to the nearest valid attachment point.
• If there are no valid connection points for the block being moved (e.g., if it is newly created and the first block on the workspace, or if it is a value block and no block on the workspace has a value input), should pressing the arrow keys with no modifier result in an unconstrained move?
  • That would seem to be helpful, especially for placing the first block on an empty workspace, but might result in the user being surprised to find that the next block they place can only be moved (sans modifier) in a constrained fashion.
  • But otherwise the block will be immovable until the user presses the modifier key, which seems like it might be a worse experience.

[cpcallen]

I'm about to rewrite the description for this issue, based on plans decided in discussions last week between members of the Blockly team and @microbit-lucy, so for posterity here was the original description, with some updates:

It should be possible to move blocks upon or after placement on the workspace. In particular:

• It should be possible to pick up an existing block (perhaps by pressing enter on it).
• It should be possible to attach the block being moved to any valid input on the workspace.
• It should be possible to move the block to any free space on the workspace.
• New blocks created on the workspace (e.g. by selecting the block from the toolbox when the marker is not active) should start "picked up", ready to be moved.
• There should be an affordance to indicate when a block is in the process of being moved.
  • This could be in the form of a drop shadow, making the block appear to be floating above the others.

To Discuss

How does dragging work in general?

• Should dragging with the keyboard work like it does with the mouse, where the cursor keys just move the block around the workspace cartesian space in small increments, with insertion markers shown when the block is close enough to attach it?

The consensus was that this should not be the primary mode, but is needed at least for positioning top-level blocks on the workspace.

• Should the arrow keys navigate only between valid attachment points?
  • To allow placement of new top-level blocks we could provide fake 'attachment' points above, between and below each top-level stack, moving stacks as necessary to keep them cleaned up.

It was agreed that moving blocks between valid attachment points was the most useful behaviour by default.

Providing specific placement points on the workspace "between" stacks was discussed, because it seems especially helpful for unsighted users, but there wasn't an obvious way to do that when stacks can be arranged arbitrarily in two dimensions. Instead, it was felt that as long as it was possible to place a block somewhere on the workspace (e.g. by using the unconstrained x-y dragging discussed above), the existing cleanup shortcut was sufficient to take care of the need keep stacks arranged on the workspace.

• Or a mix of the above—e.g. snap–to–valid-location when among other blocks, but cartesian on empty sections of the workspace?

There was some discussion of whether it would be useful for dragging to switch from constrained to unconstrained automatically—e.g., if the user pressed an arrow key 'past the edge' of the set of valid locations (off top of top stack, buttom of bottom stack, or left or right past the end of the current 'line')—but it was observed that this makes ti too easy accidentally move out into the workspace without a guaranteed easy way to get back back to one's previous location, and this might be particularly problematic for unsighted users. Instead, it was felt that it would be better to make the user give an affirmative indication that they wanted to move unconstrained (e.g. by pressing a modifier key).

How should keyboard dragging interact with mouse dragging, if at all?

• What happens when the mouse is clicked while a block is being dragged using the keyboard?
• What happens when the cursor keys are used when a block is being dragged using the mouse?

This was not discussed directly, beyond that:

• unconstrained dragging should generally be analogous in ability and behaviour (e.g. affordances like insertion markers) to mouse dragging, and
• that we probably do not want to have mouse movement move the block when it is being 'dragged' by the keyboard, as this can result in 'sticky block syndrome', where the user finds a block 'stuck' to the mouse pointer unexpectedly despite the mouse button not being held down.

[cpcallen]

Note from Rachel (to me): BlockSvg.prototype.positionNearConnection might be useful for using existing dragging code to implement constrained moving.

[cpcallen]

On the topic of what modifer key might activate unconstrained movement mode: @kmcnaught points out that alt+arrow keys causes browser navigation on Windows, and I note that ctrl+arrow keys changes Spaces and/or activates Mission Control on macOS. If we reserve shift for future multiselect (which I think we should) this leaves us with no good universal choice of modifier key. We'll need to figure out what to do about that.