Improving innerBlocks inserters

[richtabor]

What problem does this address?

The current implementation of child block inserters (i.e. inserting a Button block within a Buttons block, or a Social Icon block within a Social Icons block) can be improved, to not require you to search for the + at the opposite side of the origin insert point.

For example, in today's experience, if I add a Buttons block, I have a child Button block also inserted. After editing that button, if I decide I want to add another button, I have to select the parent block, then navigate to the far right — click the add button — then go back to the left to edit the new button.

Another downside to this, is that in some cases the + opens the block inserter (like the Social Icons block) but in others, it fires a block insertion (like the Buttons block). And outside of the child block, it always opens the inserter.

There's room for improvement; here are some ideas:

Ideas

Use the child block as a placeholder for adding another

Instead of using the same + for opening the inserter, perhaps we could use the child block itself as a placeholder for adding another block. For example, in the Buttons block, we could have a fainter button that when clicked becomes a live block to edit.

I lean towards this approach, or at least making it an option to use a block as the insertion mechanism. I think this would work well especially for the Buttons block, but potentially for others as well.

Using a more prominent UI, instead of +

This idea just aims to remove the dependency on the right-aligned +, instead making it much more clear what the insertion action is.

[annezazu]

cc @jasmussen who I know has done so much here around the experience of the navigation block!

[jasmussen]

Thanks for the ticket, it's great to discuss this. There was a very specific and clear challenge with the in-canvas button inserter as it existed before, notably that the button being in-canvas would cause layout shifts simply by being selected. As shown in #36037, here's an example:

This layout shift was caused due to the appender appearing in the DOM just like a button would, therefore taking up space. When unselected it would be gone. Now imagine a right aligned Navigation block inside narrow header in the site editor, and the shifts would be jarring and confusing.

Knowing that the in-canvas appender felt more intuitive, it was nevertheless decided in #36605 that the trade-off was worth it, especially since you also had numerous other ways to insert blocks:

• Top left inserter
• Hover between blocks to insert
• Select a block and press Enter
• Slash command in empty blocks

There are definitely improvements we can make. But I would think it pretty crucial we don't regress back to the layout-shifting, so that needs to be considered for explorations. My best bet, as outlined in this comment, is to expand and improve upon the sibling inserter. It already lets us do this:

But it doesn't allow us to insert after the last block in a container, whether horizontally or vertically:

Nor does it allow you to insert after the last block in the list:

The benefit of embracing the sibling inserter and adding those before/after behaviors is that not only is it an existing inserter (so we don't make yet another), but it is fixed position already, so it doesn't cause layout shifts. If need be, its behavior can even be amended so that the last one in a container is partially visible when the container is selected, mimicking the previous behavior.

Finally, I wouldn't discount something like what was discussed here, a "builder view" where blocks are zoomed out and separated, surfacing inserters between all blocks:

[jasmussen]

Coming back to this one after a while, the benefit that was had from removing the layout jumps feels substantial, to the point where I would love to remove even the little floating plus that's currently fixed-positioned. Beyond doing that (probably best explored separately), should we update this ticket with a focus on the sibling inserter as discussed above?