Gutenberg: Overhaul sibling inserter to only appear after a selected block

[ZebulanStanphill]

Issues with the current sibling inserter

The current sibling inserter is alright compared to some previous iterations, but there are still a lot of issues with it. Here are some of the main ones:

• It is attached before blocks, rather than after, which is confusing from an accessibility perspective. When I tab to a block, I most likely would want to insert a block after it, not before.
• It covers up part of both the block above it and below it. This means that margins have to be added to all blocks to ensure the sibling inserter does not get in the way. These margins are there even when blocks are unselected. This runs counter to one of the big goals of Gutenberg: WYSIWYG editing, and is a pain to deal with in CSS.
• It's still not as discoverable as it should be. Despite many revisions, the sibling inserter is still hard for some users to find since it only appears when hovering in a thin area. See also: #11798.

My proposal to revise the sibling inserter

I propose that the sibling inserter be overhauled to work something like this:

• When no blocks are selected, the sibling inserter does not appear.
  
  
  
  • This keeps the UI clean by reducing the constant flash of appearing/disappearing controls as your mouse moves around the editor.
  
  
• When a block is selected, the sibling inserter appears below the block's bottom edge.
  
  
  
  • This fits in with Gutenberg's philosophy of showing contextual controls when something is selected.
  
  
  • It ensures that the inserter is only covering up a small portion of the block below (no more need for the wide div used to detect hovering within a certain area).
  
  
  • It ensures that the inserter is _never_ covering any part of the block you are editing.
  
  
  • It fixes #12264 since the hover area div would no longer exist.
  
  
  • It solves the tab order issue, since the inserter now appears below the selected block, which is the most likely spot where you will want to insert a block. (Note: #18941 would also fix this issue.)
  
  
  • It greatly improves discoverability, since it is constantly visible below the selected block.
  
  
  • It prevents the sibling inserter from ever being overlapped by the block toolbar and vice-versa.
  
  
• Optionally, the block appender that automatically appears at the end of posts and InnerBlocks areas could be removed, as the sibling inserter could act as an appender since it would appear after the last block in an area.
  
  
  
  • This improves the WYSIWYG-ness of the editor, since the current appender takes up space even when no block is selected, making the default view inside places like Columns less accurate to the front-end. With this sibling inserter revision, Columns would look more like the front-end by default.
  
  
  • This combines 2 similar pieces of UI into one, improving simplicity and reducing confusion.
  
  

Mockups

Here is a mockup of what this sibling inserter could look like:

If desired, shortcuts to insert a Paragraph or Image (as proposed in #10519) could be added to this design as well:

Related issues and PRs

• #10519
• #11798
• #12264

[afercia]

When I tab to a block, I would expect that the next inserter I encounter would come _after_ the block I just focused, not before.

I'd +1million this. Thanks @ZebulanStanphill

[ZebulanStanphill]

Updated the mockups to reflect the changes made to the Gutenberg UI since I made this issue.

[enriquesanchez]

Hey @ZebulanStanphill!

I believe this issue can be closed now given all the recent improvements and updates to the sibling inserter (#18941, #19456, #19596 and #11969).

[afercia]

I saw #10471 and #11345 were closed as well and that makes sense as the recent changes to the sibling inserter solve those issues.

However, this specific issue first point asks to move the inserter _after_ a block. Instead, the new implementation keeps the inserter before the block thus this issue main point is not addressed yet.

[chrisvanpatten]

We've found it's confusing to our editors why they don't see the in-between/sibling inserter button below the current block if the last block is a paragraph.

I think using enter to insert the next block is intuitive _if you intend to insert another paragraph_ — it's a lot less obvious that you'd need to hit enter for a new paragraph if you actually intend to insert some other type of block which is not text based (e.g. an image, or columns, or some other type of block).

This has long bugged me and I'm hoping now with some of the improvements around lightening the block DOM and moving some of these controls to be popovers that this might be easier to implement.

[ZebulanStanphill]

@chrisvanpatten It's also worth noting that in some blocks, e.g. the Preformatted block, Enter can't be used to insert a new block, because it just inserts newlines in the current block. So the only consistent keyboard method to insert a new block is to reverse tab to the sibling inserter. (Which, as stated before, inserts above the current block, which is almost certainly not what most people want to do.)

[ZebulanStanphill]

Something that I've noticed recently with the most recent UI changes is that, due to the slower fade-in for the sibling inserter, some people think it has been removed in Gutenberg 7.7.0.

But before that, I recall several people complaining about the flashing UI that would happen as you moved your mouse around and the sibling inserted popped in and out.

In my proposal, the sibling inserter is shown _constantly_ below the block, and _only_ under the selected block. This solves both of the above issues.

However, it comes with the downside of no longer being able to hover over an area to reveal the sibling inserter and immediately insert a block; instead, you have to first select the block before the spot where you want to insert. Then again, it's worth noting that the hover-revealed sibling inserter is only useful to mouse users; touchscreen and keyboard users can't take advantage of it. Meanwhile, a constantly visible sibling inserter below the block would be better for both keyboard and touchscreen users.

[paaljoachim]

An associated issue.
Here is an issue in regards parent/child in using the Buttons Block.
https://github.com/WordPress/gutenberg/issues/21509#issuecomment-638195901

[richtabor]

This is related to the suggestion I made on #22867, although I'm thinking only displaying while hovering, or keyboard focused on blocks. Kinda keeps the "editing a block" vs. "adding a block" action more separate/clearer.

[richtabor]

Let's see if we can get an experimental PR together to try this. Any takers?

[kirilzh]

Hi, I would like to work on this :)

[ZebulanStanphill]

@kirilzh Feel free to create a PR! That's the best way to find out if this will work and how it compares to other approaches. :smile:

[richtabor]

This is really similar to #22867, but different. #22867 is about revealing the before and after inserter on block hover/focus - whereas this issue is about revealing the after inserter on focus only.

I think it'd be a good to have a PR for both to experiment with as its a pretty critical improvement.

[mapk]

Looks like we're moving to a PR with this for testing. I've changed some labels around for that purpose.