Confusion around the [ + ] button

[shaunandrews]

This add button appears in many places while interacting with blocks in the editor.

• The default Paragraph block includes an add button at the right edge of the block which allows you to insert a new block, replacing the default Paragraph block.
• Container-type blocks (like Group, Buttons, Columns, Navigation, and others) display a trailing add button which allow you to insert a new block within the container.
• Hovering between two blocks displays an add button that allows you to insert a new block in that space.

The intention of these buttons is to allow the user to quickly add a block in a specific location. However, these buttons can also cause problems...

The Problem with Add Buttons

The floating add buttons have often been brought up as a source of confusion and frustration. These little [ + ] buttons can seem to appear at random times, in random places, which can make it difficult to add a block in a specific place. In general, adding new blocks is often seen as a “pain point” for both new and experienced WordPress users.

Here's the problems with add buttons that I've seen in my own use, and when watching others...

Multiple Add Buttons

Add buttons are often unaware of each other's presence, which leads to multiple [ + ] buttons scattered around your document. Its easy to get 3 add buttons, all aligned differently, and all that add blocks in different places.

In the GIF above I have a Columns block with 3 columns, each containing a Paragraph and a Buttons block. Below the Columns block I have a few Paragraph blocks. When I select the Buttons block I suddenly see three different [ + ] buttons.

1. The Buttons block itself displays its own add button. Since the Buttons block displays its content horizontally, the add button appears to the right of the last Button.
2. The Column block (which contains the Buttons block) also displays its own add button, shown at the right edge of the column.
3. As I move my pointer between the Columns block and the Paragraph below a floating add button appears, horizontally centered in the width of the document. This button hides-and-shows depending on the placement of my pointer.

With all the various alignments and display logic, it quickly becomes overwhelming and leads to confusion around where each of these buttons would add a block.

Layout Interference

Often times you'll notice your blocks will shuffle around the screen as you interact with container-type blocks. This shuffling is caused by the addition of the add buttons when working within a container-type block. The add buttons behave like a normal div, using display: block, and by definition affect the layout of the document. As the add buttons are displayed and hidden, they cause blocks to move around as the layout of the document is updated.

In the GIF above I have a Columns block, with the right Column containing a Heading, Paragraph, and Navigation block. As I select one of these inner blocks, the Column block displays its add button. The addition of this button affects the layout, causing the normally vertically-centered blocks to move around. This is incredibly weird, as the block you just selected no longer appears under your pointer — it’s a cruel game of Keep Away.

Interaction and Interface Interference

The floating in-between add button can often interfere with other UI elements and content in the editor. One common example of this is the drag handle for resizing the Spacer block:

Similar, editor UI can sometimes interfere with the add buttons. For example, a block's toolbar can display on top of the in-between add button hiding it entirely from view.

The Mystery of the Randomly Appearing Paragraph

The strangest experience when dealing with add buttons is the mysteriously added default Paragraph block that often appears.

In the GIF above I have two Columns, with a Paragraph on the left and an Image on the right. When I select the Image, the Column block displays its add button below the Image. In this scenario I was trying to select the Column block, so I clicked on the empty whitespace below the Image.

However, this doesn’t select the Column block — it actually added an empty default Paragraph block. This is because I unknowingly clicked on the Column's add button. This is confusing, because it’s not obvious that this add button is actually much bigger than its visual appearance. If we look at the code behind the scenes, we can see the actual size of this deceptive add button:

Once you click on the add button, you’ve actually placed a default Paragraph block. If you’re like me, you don’t expect this behavior. I often will try to undo my mistake by clicking somewhere else — but them I’m stuck with the “Start writing or type / to choose a block” placeholder text which affects my layout.

--

Summary of User Problems

• Using the floating add buttons is hard due to their inconsistent logic for placement and appearance.
• The In-between add button often gets in the way of other intended interactions, like resizing a Spacer block.
• The editor’s visual representation of your website is untrustworthy since the add buttons often affect the documents layout, causing your design to shift and move as you interact with blocks.
• When multiple add buttons appear it makes it difficult to understand where each button will place a block.

[shaunandrews]

I have a few explorations. Here's the first one in GIF format:

In the above GIF I have a Columns block, with one column containing an Image and the other column containing two Paragraphs. Add buttons are only displayed based on the currently selected block. As I select the Columns block, the default canvas add button disappears. When I hover over the left column's add button the Column is outlined and a linear guide is shown to indicator where a block would be added. These add buttons are positioned to a fixed point on the container (bottom-right), and don't affect the layout of the document.

[jasmussen]

Awesome ticket, Shaun. This is something I know has frustrated both @mtias and @ellatrix for a long time — specifically the layout interruption. Whatever we can do to make the appender not take up visual space in, for example, a vertically centered Cover block, would be great.

As for your first exploration, my instinct also goes towards some absolute positioning as the primary/only solution, and showing on hover also makes sense. The primary problem there is, what if I want to click at the bottom right of a paragraph to start typing there? I wonder if there's a refinement that puts the button on the edge of the block boundary, and even makes it smaller. Notably in cases like Social Links, or Navigation, putting the plus as an overlay is tricky as there's barely any space to begin with — we might even want to limit this from showing up in such small contexts.

[shaunandrews]

Another exploration focuses on drag-and-drop as a useful method of adding blocks into specific locations. Here's a quick GIF to show dragging a block from the library, and how hovering can help guide you into the placement of the block:

In the GIF I drag a Paragraph block over the bottom area of a Column block. As I hold the hover for a split second, a blue line appears to help signify where this new Paragraph block would be place. As I continue to move my pointer towards the center of the document a new guide appears letting me know that I'm about to place a Paragraph block between the Columns and existing Paragraph block.

I think this drag-and-drop interaction would make the in-between and container add buttons unnecessary.

[mapk]

Another exploration focuses on drag-and-drop as a useful method of adding blocks into specific locations.

I'd love to see this drag and drop interaction become a reality. This was highly requested in the Widget Screen as well.

[shaunandrews]

Notably in cases like Social Links, or Navigation, putting the plus as an overlay is tricky as there's barely any space to begin with — we might even want to limit this from showing up in such small contexts.

Thinking about this a little, I wonder if for container-type blocks like Buttons, Navigation, Columns, and Column if it would make sense to surface the add button into the block's toolbar:

[mtias]

There's a very old issue for drag and drop from the inserter (#1511). Would you mind adding that gif as reference there?

[shaunandrews]

Looking at the (what I've nicknamed) Fixed Floaties option, where container-type blocks show a fixed-positioned add button. Only one add button is shown at a time, and since it's fixed to doesn't affect the layout of the document.

When hovered for a few seconds this button would highlight the container block:

Here's a look at how the hovered highlight could work for different types of containers:

[jasmussen]

While there's something about the visuals of the bottom right aligned button I don't totally love, your approach does seem to hold an opportunity to solve some of our current headaches.

There appears to be an inconsistency in how the button appears in Group/Cover compared to Buttons. In Buttons, it's inside the container, next to the only allowed child block. In Group/Cover the button is outside the container, always at the end. Is there a system that tackles both at the same time?

[mtias]

In the Cover context, how would you distinguish between adding within and adding outside?

[mariohamann]

Drag and drop.

• I would love to see Drag and Drop – but there are some a11y concerns especially for keyboard users as described by @talldan in Merge Inserter and Settings; Drag and Drop blocks from Inserter into Navigator #22319 (comment) so it has to be guarenteed that there are still other usable (!) options.
• Furthermore I would like to bring in, that in my opinion while dragging, the hovered block's outline and its name should be shown immediately without any delay (see my ugly draft in While moving a block: Show border and block name of hovered blocks #24750).

Insertering from toolbar

I like the idea of @shaunandrews #26404 (comment) to use insertes from the toolbar. To be honest: For me the only reliable source in Gutenberg to add blocks at the correct place are the options "Add block before" and "Add block after". I don't want to overcrowd the toolbar, but would like to add the following proposal, coming from @mapk's idea to show more options in select mode (being explored in #25275) and building on (in this context a bit tiny) icons I created in #25274:

In the Cover context, how would you distinguish between adding within and adding outside?

This could be handled with those options in the toolbar.

And: I would love to see an inserter instead of a new paragraph (for inner blocks with only one allowed block of course this single block should be inserted).

[mariohamann]

Had another idea: If using the toolbar for inserters, we could enhance usability by showing the inserter-line while hovering/focusing:

Test yourself:
https://www.figma.com/proto/MfookqWbLNNaJjviZjHti9/Add-Blocks-%E2%80%93-Experiments?node-id=8%3A259&viewport=-188%2C-1115%2C0.6690232157707214&scaling=min-zoom

[shaunandrews]

In the Cover context, how would you distinguish between adding within and adding outside?

Part of the idea is that the + button only appear on the canvas when you select a container block, like Group, Column, or Cover.

I've created a small prototype to get a sense for how this container add button could work: https://shaunandrews.github.io/static-prototypes/canvas-add-buttons/

Otherwise, the only + button is the one in the top toolbar. With the existing method of using the block toolbar's More Menu (...) to add blocks before/after, and the proposals for incorporating drag-and-drop, we can remove the default + buttons in empty Paragraphs and at the bottom of the document.

--

@mariohamann — I have similar explorations, but abandoned the idea of adding more icons to the toolbar as it doesn't feel like a primary action related to the block. Having these options in the More Menu (...) seems like the better solution. I could see adding another option to the More Menu to "Add inside," if the block supports it.

[jameskoster]

I've mentioned this to you before, just adding it here just to note on record :D

Having the + on the bottom right of the container makes it quite uncomfortable to target with my cursor when using a Trackpad. I don't know if its just working against my muscle memory of interacting with the toolbar, or some kind of awkward contrast in that most blocks tend to be top-left heavy. This one is especially troublesome:

TLDR: I +1 the idea of exploring this action being closer – but not necessarily inside the Toolbar. Perhaps something like:

---

Quite possibly too radical, but sharing if for no other reason than to rule it out (or inspire something better)...

If we made the button a bit bigger (matching the toolbar) we might be able to communicate where the block will be added on the button itself, and perhaps even utilise a pattern like the parent-block-selector to enable folks to choose the position their block will be added...

[paaljoachim]

Associated issues:

Up/Down arrows - move blocks independent of relation to placement inside/outside a container
#24328

and

Impossible to select Group Block (5.4 Beta 3)
#20453

[ZebulanStanphill]

Some of these mockups remind me a lot of what I'm proposing in #13571.

[annezazu]

To make sure it doesn't get lost, I wanted to recap some of the feedback from this recent WP Tavern post:

Getting the “Add Block” icon to appear when hovering in between elements in the default content area was rough. I had to position my mouse in a perfect position for it to appear. It was an exercise in frustration where even the slightest movement caused the icon to once again disappear.

In my testing the last few weeks, this experience has grown worse particularly when using Full Site Editing. Here's just a quick video where you can see the block outlines and add buttons causing a lot of visual activity to do simple tasks:

add.button.mov

[overclokk]

Also having some kind of border to make clear where are the blocks that would be a good thing, because it's hard to find a block at first click, something like that:

[mariohamann]

@overclokk There are several issues which try to improve outlines e. g. #25133 #23892 #22383

You are very, very welcome to add your feedback over there. 👍🏻

[jameskoster]

I noticed today that the component variants UI in Figma employs a very similar pattern to the floating-bottom-right idea proposed in the comments above:

[jasmussen]

In #30833 I made a small attempt at showing mostly just one appender at a time.

[jasmussen]

It seems increasingly clear that we should search for a solution that removes the in-canvas appender entirely. Things like justifications suffer from a big cumulative layout shift when it has to account for a varying size appender among the child blocks:

CC: @jameskoster

[jameskoster]

It seems increasingly clear that we should search for a solution that removes the in-canvas appender entirely.

It does feel as though we have potentially over-indexed on block insertion... the appender is one of five ways add a block:

1. Top bar inserter
2. Appender inserter
3. Sibling inserter
4. "Insert before" and "Insert after" in the block toolbar
5. Return + slash command.

Am I missing any? :D

Since the appender is the most visually disruptive – I would be interested to see how removing it altogether actually impacts usability.

---

In the long run, I do think the solution to this issue may be closely tied to #31236. If we're able to make Select mode more about insertion and general layout, and edit mode more about... editing, then things might feel a bit better. In that respect I'll share the latest concept I've been working on in the hope that it might help stimulate the creative juices.

select-and-edit.mp4

[jasmussen]

I really appreciate that visual. I think it's currently the closest we have. I wonder if just as a starting point we could test removing the black in-canvas appender ENTIRELY, purely as a proof of concept, and then evaluate in that branch when and in which circumstances we find ourselves missing it. That might help surface if there are any smaller in-between steps we can take...

[ellatrix]

I’ve been thinking a bit about the in-between inserter. What if we display a little blue dot in the middle that expands when you get close to it with the mouse?

[jasmussen]

Created this experiment to remove the appender entirely. The before and after are wild, and show how great it would be if we could just remove the layout shift.

[shaunandrews]

The Design Team discussed this issue in our Nov 2021 Show & Tell call. Here's a list of things we discussed as next steps, some one which already have PRs:

• Remove the in-canvas [ + ] entirely from the site editor. (Try: Hide the in-canvas appender in the site editor. #36602)
• Explore a fixed-position [ + ] for container-type blocks. (Try: Make appender fixed position. #36037)
• Highlight container blocks when adding inner-blocks.
• Explore a block toolbar button for specific blocks, like Navigation or Buttons, where adding a block could be considered a primary function.
• Explore alternates solution for triggering in-between inserter; Sometimes its too hard to trigger, and sometimes its too easy to trigger.

By removing the in-canvas [ + ] button from the site editor, we can (hopefully) identify scenarios where adding a block becomes problematic. The initial thinking is that the [ + ] button was originally created at a time when the block editor was very young, and that its possible we've "over indexed" the ability to add blocks.

We can bring back the [ + ] (like in the second item above) where needed, and perhaps find better solutions (like a toolbar button) rather than relying on the [ + ] button as-is today.