Moving a block between positions on the workspace

[rachel-fenichel]

When a user selects a block from the toolbox it is placed at an arbitrary location on the workspace. The user then has to move it to the desired location.

This can be done a few ways:

• Mark the block as the subject of the next action, then move the cursor to the target location, then use a shortcut to move the block to the cursor location
• Mark the block as active or dragging, and move it across the workspace using the arrow keys as xy controls
• Mark the block as active or dragging and move it between available positions on the block stacks using arrow keys as stack navigation controls

Open questions:

• Which "dragging" approach should we take?
• Which keys will trigger it?
• How will we show what is happening visually?
• How will we show what is happening audibly?

[cpcallen]

• Mark the block as active or dragging and move it between available positions on the block stacks using arrow keys as stack navigation controls

1. Would an available position be denoted just by the cursor, or by a shadow block, or by the block itself? I think "shadow" might be the most intuitive option, because it would be similar to how it works when dragging with the mouse, and might avoid the need to have a separate mode indicator (or at least make an even greater visual difference between normal navigation and this drag-navigation).

2. When we were discussing this I was thinking about having the cursor keys effectively move the new between spots that it would appear as a shadow block if being moved by the mouse, and wondering how to decide, given an current "shadow location", a set of other possible shadow locations, and a cursor cardinal (up / down / left / right) how we would choose which other shadow location to move.

   In particular, we would want the algorithm to guarantee that every possible location was reachable (and ideally in an intuitive way). To see that that's non-trivial, consider the (purely hypothetical and not very realistic) arrangement of possible locations:

   *         *
   
        *
   
   *         *
   

   If one started on a corner, the most obvious place to go for each of up/down/left/right takes you to another corner, leaving no way to reach the centre location.

3. Having read your quoted formulation above, however, I now realise that it would probably be more intuitive (and easier to avoid stupid problems like the one discussed in the previous point) to allow the block to be "navigated" in exactly the same way the cursor is. This does raise the question of what to do when navigating to/through locations that aren't valid for the block. Maybe we show the block (or a shadow block) when visiting valid locations, and just the cursor when visiting invalid locations.

[rachel-fenichel]

During this pseudo-dragging mode, moving the mouse should not move the block around (that is, don't swap between keyboard drag and mouse drag in the middle of a drag). Hitting escape should abort the drag and put the block back where it started.