Improve Inserter experience when blocks cannot be inserted

[jameskoster]

The problem

When opened, the Inserter checks where to place blocks and patterns. When the logic is unable to find an appropriate position then the UI turns up empty.

A common example is page editing in the site editor with the template preview turned on; if you select the Title or Featured Image block, then open the Inserter, you see this:

It's quite unexpected to be presented with an empty Inserter, and the lack of explanation further confuses things.

Solution – always show blocks / patterns in the Inserter

• When the block/pattern cannot be inserted in the target location (based on existing logic), place it in the 'closest' possible location instead.
• When there are legitimately no insertable locations in the current document, show a modal when a block/pattern is clicked/dragged to inform the user.
• Give additional prominence allowedBlocks. E.g. when a List block (or a descendant thereof) is selected, opening the Inserter could show:

The label can be polished in a PR. "Based on your selection" could be an alternative to "Suggested".

Original idea

Ideally the Inserter should never appear empty, so as to eliminate that initial point of confusion.

One option could be to update the logic so that it falls back to the closest insertable location based on the current parameters. In the scenario above, 95% of the time that would result in blocks being added to the Content block which seems reasonable and expected.

When there are genuinely no insertable locations in the current document, a dialog could appear when a block / pattern is clicked or dragged that explains the situation.

cc @WordPress/gutenberg-design for other ideas.

[jasmussen]

There's a bit more to it than that, not only does nothing show up, but if you search for blocks, you won't find anything, presumably because you can't insert in that container:

Both aspects of the same problem. One path forward is, as you say, finding the nearest insertable location, and then applying both to the inserter and search results, as well as where the block will be inserted.

The other path would be to at least add smarts to the inserter to explain that it isn't that no results are found, plainly, it's because you cannot insert blocks in this particular location for this or that reason.

[jameskoster]

The other path would be to at least add smarts to the inserter to explain that it isn't that no results are found

I'm less a fan of this approach, mostly because; if the user opens the Inserter it's clear they want to insert a block. The message would help explain things, but ultimately doesn't help them with their goal.

There's a bit more to it than that

It may be worth considering the allowedblocks experience in the inserter more generally. For instance if you're writing a list, then want to use the Inserter to add an Image after it, this is a bit frustrating:

You have to close the Inserter, click elsewhere in the document, then re-open. I wonder if it would be better to display all blocks, (with prominence given to allowedblocks), and if you select something outside of the allowed scope it just gets added to the closest possible location, e.g:

[jasmussen]

I'm less a fan of this approach, mostly because; if the user opens the Inserter it's clear they want to insert a block. The message would help explain things, but ultimately doesn't help them with their goal.

Agreed, I shared it almost rethorically to support the point that it really shouldn't be empty.

Good thoughts, though, I wonder what would be the smallest thing to do. Is it to have the suggested followed by all sections and ensure blocks in the all section insert in the nearest allowed context that follows after the selected block?

[jameskoster]

Is it to have the suggested followed by all sections and ensure blocks in the all section insert in the nearest allowed context that follows after the selected block?

Perhaps this would be more work, but the upside is it would capture all of these flows.

I don't have strong opinions either way, but I find myself tripping over the example in the OP quite often, and would lean towards prioritising a fix for that if we want to try something laser-focussed.

[richtabor]

You have to close the Inserter, click elsewhere in the document, then re-open. I wonder if it would be better to display all blocks, (with prominence given to allowedblocks), and if you select something outside of the allowed scope it just gets added to the closest possible location, e.g:

I agree with this sentiment. It's a bit of a needle to thread, but for blocks with restricted inner blocks—like the List block—it's unexpected to not see any other blocks. I wonder if another course of action would be to categorize/prioritize the blocks that can be inserted within the given block, (List Item block for example) and have all other blocks below it.

Edit: Ha, same as @joen mentioned:

Is it to have the suggested followed by all sections and ensure blocks in the all section insert in the nearest allowed context that follows after the selected block?

[richtabor]

The other path would be to at least add smarts to the inserter to explain that it isn't that no results are found

I'm less a fan of this approach, mostly because; if the user opens the Inserter it's clear they want to insert a block. The message would help explain things, but ultimately doesn't help them with their goal.

Agreed. What would it read? Select a different block to add different blocks? 😅

[jameskoster]

I wonder if another course of action would be to categorize/prioritize the blocks that can be inserted within the given block, (List Item block for example) and have all other blocks below it.

I guess my 2 second inspector mockup wasn't very clear 🙈, but this is exactly what I was getting at 👍

Overall the path forward seems to be:

• Always show all blocks in the Inserter.
• Give additional prominence allowedblocks.
• When a block cannot be inserted (based on the existing logic), insert it in the closest location that can be found. Hopefully this isn't computationally expensive 🤞
• When there are legitimately no insertable locations, show a dialog when a block/pattern is clicked/dragged.

Happy to mock this up in more detail, and update the OP if there's consensus.

[richtabor]

This issue is closely related: #55151

[richtabor]

Happy to mock this up in more detail, and update the OP if there's consensus.

Seems solid to me.

[richtabor]

I'm noticing this also when a template part is selected; generally much more often lately.

I think we need to iron this out before 6.6.

[SaxonF]

Agree this should be prioritised

[draganescu]

Partially synced patterns also cause this:

List items	Partially synced

[draganescu]

@jameskoster there is a broken picture in the description if you can remember what it was, after the text:

E.g. when a List block (or a descendant thereof) is selected, opening the Inserter could show:

[jameskoster]

Oh, it's the same image as the one in this comment. Apparently github prefers me to upload the same image twice.

I updated the OP.

[annezazu]

Adding this to the 6.6 board as I agree this is increasingly becoming more visible with some of the new features like overrides.

[jasmussen]

Here are a few takes on solutions. The main challenges to solve, as I perceive it:

1. If I select a list block, and only see a list item, it begs the question: where are all the other blocks? You can drag and drop them anywhere, after all, even if they can't be inserted in the "List" block because only "List Item" is allowed.
2. If I select a Title block in a locked template, no blocks are allowed inserted. The same question arises: where are all the blocks? Why can't I insert blocks?

The least we can do, it feels like, is to improve the messaging in the inserter.

In this mockup, Title and List block cases. The Title block shows: "The container block is locked from new blocks." — This is not the best copy, and I'd appreciate advice, we can be as verbose as we need to here, but the message is, the inserter is contextual to the block you've selected, and if it's in a locked context, no blocks can be inserted.

This mockup does not address the probable confusion: "where are all my blocks", but it could hopefully be a first step to improve things.

A larger undertaking would involve showing all available blocks in a secondary list. Those blocks would not be possible to insert into locked contexts, so we'd need both visual separation, and a heuristic: where do they go then? The simplest I could think of is:

• When the Title block is selected but in locked context, the inserter will show the usual list of blocks, but those will be inserted at the root level of the document. After the current block, if possible.
• When the List block is selected, it'll show a dedicated area at the top of the inserter, with child blocks that are allowed, in this case, "List item".
• Similarly, other blocks are shown below a separator, and those will be inserted at the root level.

Let me know your thoughts.

Figma.

Note, I've edited this comment as a few things came to light after posting.

[annezazu]

Quick thoughts: I dig this. I think all of this combined with enhancements to drag & drop, like showing a X when you can't drop something in a certain area, will help step us forward here.

[jasmussen]

Coming back to this one, it's arguably a bug, and has been since the initial implementation. It's just become more visible with recent changes to the inserter.