Revise sibling inserter to be more consistent, appear in a more logical position, and not overlap the content of the selected block

[ZebulanStanphill]

The issues with the current sibling inserter

First of all, the sibling inserter does not appear in an intuitive location. It appears above blocks, rather than below blocks. This means it does not appear below the last block in a post or nested context. When you are trying to insert a block, you usually want to insert after the current block, not before. Additionally, many users have been confused by the lack of sibling inserter after the last block in a post or nested context.

Second, as pointed out in #8881 and #8883, as well as the cause of #8206, the sibling inserter always overlaps a portion of the content of the selected block. Nothing should ever permanently overlap the content of the selected block. The sibling inserter should be moved outside of the borders of the block content in order to not overlap any of the content and ensure the block UI works with very small and thin blocks. Note also that blocks with thin margins/padding (see also: #8350) are especially affected by this issue.

Previous considerations

I previously thought that combining the sibling inserter into a toolbar below the block along with the up/down movers and ellipsis was the best idea. Here are some mockups of that idea from #6224.

However, this added a considerable amount of weight to the UI, and the mockups in #9074 and #9075 to move the ellipsis to the toolbar and make the toolbar more responsive would actually resolve a lot of the issues with the current UI, making it less necessary (if needed at all) to move the up/down movers from their current position on the side of the block.

That left the sibling inserter as the only thing that definitely belongs below blocks, leading me to my new proposal.

My proposed solution

I propose redesigning the sibling inserter and making it look and act a lot like the up/down movers on the side of the block (but with a few important differences).

Note that in the following mockups, I have moved the ellipsis menu to the block toolbar as proposed in #9074. This is unrelated to this change, but I thought I would show what they look like together.

Hovering over the selected block would look pretty much just like it does now:

However, If you hover within the bottom of a block, the sibling inserter would appear:

Note that the sibling inserter would not appear if you hovered near the bottom of the block. It would only appear if you hovered within in the bottom of the block. This is to prevent the sibling inserter from overlapping the block below unless your cursor first moves into the block above.

Note that this is very similar to what I am proposing for the up/down movers in #8880, and that proposal is based in the same desire to remove all instances of UI from another block overlapping the one you are editing unless you first move your cursor into that other block.

Hovering over non-selected blocks would work the same:

Now, there is one situation that requires a bit more thought: hovering within the bottom of the block above the selected one. However, I can think of 3 possible solutions which are all fairly simple.

The first solution I see here is simply to not show the sibling inserter for the block directly preceding the selected one. This is very similar to the current behavior in master.

The second solution would be to make the hovered block overlap the selected block:

The third solution would be to make just the sibling inserter overlap the selected block. The obvious danger with this idea is overlapping the selected block, but if the sibling inserter only appeared when you first hovered within the bottom of the block above, I do not think this would be an issue:

Final thoughts

I think this idea is the best way to fix a lot of the various issues with the sibling inserter, while keeping the UI as light as possible.

I also think the sibling inserter should open the insertion menu directly, rather than inserting an empty Paragraph, but that suggestion is discussed separately in #6569, #7006, #7271, #8363, and #8589.

Related issues and PRs

Closely related

• Display block tools underneath the block, instead of to the sides #6224
• Confusing + button behavior #7271
• Sibling inserter doesn't appear above selected block with no toolbar #7884
• Spacer placed before Columns can't be resized inline #8206
• Add Block (+) is inconsistently used, possibly confusing #8363
• Default Appender that is not Paragraph Based #8589
• Do not show block movement controls unless cursor first moves into corresponding block. #8880
• Inserter: sibling insertion point at top of selected block covers up part of block content #8881
• Sibling inserters should never constantly overlap the content of the selected block #8883

Other issues related to the block UI

• allowedBlocks does not prevent any block from being inserted via the “Enter” key or sibling inserter #6569
• Add a delay to the blue outline + block type label on hover #8836
• Try moving block margins to each block #8350
• Try: "Focus Mode". #8920
• Move the blocks "More" button (ellipsis) to the toolbar #9074
• Allow toolbar segments to collapse (responsive toolbar) #9075
• Add a delay to the block type label on hover #9197

[chrisvanpatten]

I've gone on record as being a fan of revising the sibling inserter before, but I'm not convinced this is all necessary.

Looking at your report in #8881, that looks like a bug which could be easily solved by adjusting the positioning of that insertion div. And the issue I reported in #8206 seems to me like an issue with margin collapsing, not a problem inherent to the inserter.

I think those two issues should be addressed, but I think they can be addressed without a full scale redesign of the sibling inserter.

[designsimply]

Closing as a duplicate of issues already open and referenced above and noting that your feedback has been heard.

One of my goals in my role is to help consolidate issues. In the future, when you are linking to related issues for a case like this one, would you be able to limit linking to just one or two of the most relevant issues? Being concise in that way goes a long way to help make it easier to process feedback. Thank you so much for your understanding.

[ZebulanStanphill]

@chrisvanpatten As noted in #8883 (which I do not think should have been closed as I consider #8881 a separate issue and fixing one would likely not fix the other), the sibling inserter itself still overlaps the content of the selected block no matter what. If you have a block with text that hits the edge of the block borders, the inserter will overlap it. There is no way to avoid that unless the sibling inserter is moved.

I decided that having the sibling inserter keep its round shape (and/or having no background) looked weird when it was shifted downwards, hence the change to use the same style as the up/down movers.

Of course, doing this only works if the sibling inserter is changed to appear after blocks rather than before, so I made that part of the proposal too, considering that this seems to be the expected behavior anyway.

@designsimply

Closing as a duplicate of issues already open and referenced above and noting that your feedback has been heard.

I feel like the best issue to post this mockup in would be #8883, but that was closed as a duplicate of #8881, which I consider to be a separate issue. #8883 points out that the sibling inserter itself (not just the area surrounding it) overlaps the content of the block permanently in all situations, and this should not be the case. Could #8883 be reopened?

One of my goals in my role is to help consolidate issues. In the future, when you are linking to related issues for a case like this one, would you be able to limit linking to just one or two of the most relevant issues? Being concise in that way goes a long way to help make it easier to process feedback. Thank you so much for your understanding.

Alright.

[designsimply]

I understand your concerns about extra spacing for inserters and would like to note that there is a delicate balance with regard to usability, discoverability, and accessibility for these things which are being considered by experienced designers who take into account not only feedback like what you have posted here but also past iterations and user testing over time as well as several years experience working on WordPress and other large projects. Ideally we can all work together to come up with better solutions and iterations as we go, as I feel you are trying to do, and what I would like to do is to keep those issues clear, concise, and consolidated, especially in a case such as the inserters which may have diverse opinions which need time to sort out before opening newer and very similar issues.

Your feedback about sibling inserters overlapping content was posted into two separate issues and #8881 was kept open because it was very similar, it had a better example, and there are other open issues where the design of inserters are being discussed and iterated on already. It's a tough balance sometimes! I appreciate your enthusiasm and also would like to do my best to streamline open issues for the project so that they are as clear and concise as possible.