Newly-created blocks should not overlap existing blocks

[cpcallen]

Adding a new top-level block to the workspace (e.g. by navigating to the toolbox, cursoring to a desired block, and pressing enter) places it on the workspace adjacent to its position in the flyout, but this often overlaps existing blocks on the workspace.

[microbit-matt-hillsdon]

We're considering using an interim fix for this for user testing similar to this demo. Some scenarios are pretty awkward at the moment, e.g. having two "on button" blocks (one for A, one for B) placed perfectly on top of one another.

We've based it on the Blockly clean-up code but adapted to a top-to-bottom left-to-right placement, as otherwise a lot of space goes to waste on the right hand side (screens are often 16:9). It's based on avoiding existing blocks rather than placing items into a grid. It's surely not the final answer but it's clear that the existing placement isn't what we'd propose shipping so something that's a step in the right direction will let us learn more from user testing.

We do expect that some edits will still require 'cleanup' but if we rely completely on that we don't learn anything about what default placements are natural / expected / surprising.

Please tell us if you have strong opinions about this kind of approach and/or had different ideas you were planning to implement later, and we can tweak it to be more aligned.

One thing that would need further discussion is alignment with "Clean up Blocks" which is currently just a vertical stack. Interestingly, MakeCode has "Format Code" that does use an element of left to right layout (we need to analyse this further).

[rachel-fenichel]

No concerns on applying that interim fix. The correct cleanup algorithm is highly context dependent so if that works for you folks it looks good for testing.

In particular, MakeCode disables orphan blocks and otherwise I believe everything is event based so this doesn't run into weird issues with reordering the code.

[cpcallen]

@microbit-matt-hillsdon:

• I concur with Rachel's points.
• I think a fancier cleanup would be a useful addition to core in due course, supplementing (but perhaps not entirely superseding) the existing behaviour.
• As Rachel hinted at: as a core feature, it would need to maintain the invariant that the existing cleanup does, such that reorganising the blocks does not result in a change to the order of the array returned by Workspace.prototype.getTopBlocks(/*sorted=*/true)—this is to ensure that cleanup does not result in a change of behaviour of the generated code.
• That said, I suspect cleanup functionality will be less important once we finish implementing unconstrained cursor movement (sixth and seventh to-do items in Change line cursor behaviour to be more intuitive #129) and a move action for top level blocks (Make it possible to move blocks on the workspace #106).

[kmcnaught]

This looks good to me as an opening gambit for user testing. Just to clarify, this addition does not affect the existing layout at all, just the position chosen for the new block. So although the best heuristics may be context dependent, the basic premise of "initially put it somewhere that's not problematic" will be required everywhere, whether event-driven or executed-according-to-layout-order. We don't want to require unconstrained cursor movement for every top-level block insertion.

[maribethb]

Closed by #378