Inserter: Reveal surrounding block inserters on block hover/selected states

[richtabor]

Is your feature request related to a problem? Please describe.
Its difficult to discover the inline block inserter (as referenced in #22801), unless one hovers over a precise area between blocks.

How about instead of speeding up an animation, or making the hover interaction area larger, we consider revealing the inserters before, and after, the currently hovered (and possibly selected) block?

Adding blocks via the inline inserter should be considered the primary way to interact and build a page - as a user has to naturally first identify where that block should be inserted anyhow.

In actuality, the top left "+" icon/trigger could probably be removed altogether, if it were easier to add blocks directly within the interface. This way, there's one common method of engaging with the content - and you know exactly where the inserted block will be placed, as you have clearly indicated where (without having to search for the hotspot).

Describe the solution you'd like
Hovering over a block should reveal block inserters before, and after itself. This way I can more easily add a block exactly where I'd like, without having to search for the inserter - or try to clear a space, engage the block library sidebar, add a block, then close the block library sidebar.

Here's a gif

Prototype
And here's a Figma prototype to try out.

Describe alternatives you've considered
Clicking/hovering around till the inserter reveals itself 😞

[MichaelArestad]

This is really nice for a few reasons:

1. It provides a mouse target ahead of time. No surprises.
2. It doesn't have any delay (which makes it feel unresponsive/slow/unpredictable).
3. It doesn't have a very thin hover target.

I would like to try it.

CC @ItsJonQ since it's not far off from the work you're doing around grids and seems like it might play nicely.

[shaunandrews]

I think this might be better than what we have, but I wonder how it would work with nested blocks like Columns within a Group.

[ZebulanStanphill]

Noting that I proposed an alternative solution in #13571. (Mockups are out-of-date, but the ideas generally still apply.)

Remember, also, that back when the sibling inserters appeared immediately on hover, people complained about flashing UI all over the place and covering up part of the selected block content, e.g. #11798. (The last complaint technically still applies to some degree right now in master.)

[shaunandrews]

people complained about flashing UI all over the place and covering up part of the selected block content

I think we've swung the pendulum too far in both directions. There's a balance here that I think we can find in code.

What I like about the proposal in they issue is that it reduces the interaction down to a more understandable logic; Hover a block and see any available neighboring inserters.

I do think a delay and some sort of larger proximity detection would be needed to avoid becoming annoying, though.

[richtabor]

I think this might be better than what we have, but I wonder how it would work with nested blocks like Columns within a Group.

I'd say a good step in the right direction would be to apply this to all top-level blocks only (for now at least). Perhaps innerBlocks could display the + without the line indicator, or even only after the currently selected block.

[richtabor]

Related #22873.

[ZebulanStanphill]

I think this might be better than what we have, but I wonder how it would work with nested blocks like Columns within a Group.

I'd say a good step in the right direction would be to apply this to all top-level blocks only (for now at least). Perhaps innerBlocks could display the + without the line indicator, or even only after the currently selected block.

That sounds like something that would cause a lot of confusion. I think whatever we do should be applied consistently at all nesting levels.

[mariohamann]

That sounds like something that would cause a lot of confusion. I think whatever we do should be applied consistently at all nesting levels.

+1.

Inner blocks could be become funny. :)

Hovering over a block should reveal block inserters before, and after itself. This way I can more easily add a block exactly where I'd like, without having to search for the inserter - or try to clear a space, engage the block library sidebar, add a block, then close the block library sidebar.

Furthermore I would like to add the idea of named inserters to make it even more clear what to add. (But maybe that's another issue.)

But that could become even more heavy in inner blocks...

And: Should it work with :hover AND :focus, too? I think it should (keyboard users!)

[draganescu]

@mariohamann the named inserters already work, if the innerBlocks block allows only one kind of child, that block's name will be used in the inseter. See the navigation block and it's "Add Link" inserter.

[mariohamann]

@mariohamann the named inserters already work, if the innerBlocks block allows only one kind of child, that block's name will be used in the inseter. See the navigation block and it's "Add Link" inserter.

Yeah, you're totally right. The question is whether this might be too much text then?

[StaggerLeee]

You have to think a bit further in the future. Soon you will need one more icon for replacing block pattern(s).
There is no full-blooded theme editor without it.

[noahtallen]

Related to all of these issues, I really think we need to spend time thinking about inner block inserters as well. For example, this screenshot shows Document > Group > Template Part. It has three pre-inserted paragraph blocks, each of which take up vertical space sometimes.

This has multiple issues:

1. The inner block area into which you are inserting a block is not obvious. For example, look at the template part /group block boundary. If I didn't have the template part block selected, it would be impossible to tell which "inner block area" I would be inserting the block into.
2. The block inserter takes up vertical space.

The vertical space thing, IMO, is a big issue because it causes the content to jump around as you are selecting into and out of blocks and working in the editor. This is a poor experience visually, but I think it subconsciously gives the idea that the editor is unstable. Elements are moving in an unexpected way, which gives the impression that the editor isn't under a user's control.

I think an inner block area inserter design that addresses these two points would be a huge (and maybe even underrated) improvement in core editor experience just because the editor will feel much more solid and stable!

[ZebulanStanphill]

I think one thing that could help is if the inserter buttons actually told you what they were inserting into, e.g. "Add block to [BLOCK NAME]".

Additionally, I think that (except for "placeholder" inserters like those seen in empty columns/groups), no appender/inserter should take up any actual space on the document. Instead of an appender, we should just use the sibling inserter at the end.

And speaking of which, I've been suggesting for a while now that the sibling inserter should be reworked to only appear after the currently-selected block. See #13571 and #24926 (particularly the updated mockups I posted there). This would dramatically reduce the number of inserter buttons on-screen, and make it much clearer where the inserter will be inserting, since you could predict it would be after the selected block.

[StaggerLeee]

What about to place Inserter icon in block toolbar ?
Clicking on icon shows all possible options (icons) in this case. One click more but you struggle with it anyway.

And nested icon with some opacity.

[ZebulanStanphill]

@StaggerLeee Usually, you're most likely going to want to insert a block after the current one, not before. But right now, the block toolbar is shown before the block, so the positioning of an "Add block" button inside the block toolbar wouldn't feel right to me. If anything, it would feel like it's intend to insert into the current block. And actually, maybe that kind of feature is something we should explore separately.

(Maybe if we ever add a "show block toolbar below block" option (which is something the accessibility team has requested, if I recall correctly), then the inserter could be shown at the end of it when that mode is enabled. Or maybe it would just be shown below both the block and the toolbar in that situation.)

Semantically, though, the appender/inserter isn't really related to the selected block (or at least not nearly as much as the other things in the block toolbar), so I don't think it belongs in the block toolbar in the first place. And yes, I know we have "Insert Before" and "Insert After" options in the block toolbar's more menu... but when was the last time you used them or even remembered that they exist? They always felt like a bit of a band-aid workaround to me.

[noahtallen]

And yes, I know we have "Insert Before" and "Insert After" options in the block toolbar's more menu... but when was the last time you used them or even remembered that they exist? They always felt a bit of a band-aid workaround to me.

I did go looking for them the other day and found them where I expected them to be 😅 . I think it's similar to e.g. a spreadsheet app, where you'd select a row, and then right click, and then "insert one before/after"

[afercia]

What about keyboard users? 🙂

Exploring a better interaction on hover is certainly good but I'd like to remind everyone that any action must be operable also with a keyboard. The various appenders/inserters (aside: these names are very confusing) are already difficult to use with a keyboard and in some cases they can't be used at all. I'd greatly appreciate this exploration to keep keyboard interaction into consideration.

[noahtallen]

I tried out something very basic (i.e. not for production) to see how addressing the inserter height problem might feel:

It's really nice how it the content is not constantly jumping around. Such a great improvement. But it's still pretty rough as it relates to other nearby inserters. It looks a bit out of place, and other insterters can even cover it.

[a4jp-com]

The line should be clickable as well. The tiny plus mark is smaller than standard 44px buttons.