Proposal: Keep the Inserter open

[richtabor]

I wanted to explore if the Inserter behaved like other sidebars, where it remains open unless explicitly closed. This way the Inserter does not disappear when you're engaging with blocks after inserting them.

As part of this exploration, it became clear the expectation is that there's a close button, like on every other sidebar (List View, Inspector, Styles, etc). To align with those other panels, that means placing the close button at the end of the tabs that depict the contents below.

In doing so, the search field would need to be moved below the tabs, where each tab (Blocks, Patterns, and Media) would now scope search results—rather than returning all types of results. For example, when the Blocks tab is active, you are searching for blocks, and blocks render as search results.

I would also expect a search term would persist, if an alternate tab is selected. For example, if I search for "gallery" I would see the "Gallery" block while the "Block" tab is active, and any gallery patterns while the "Gallery" tab is active.

Visual

inserter-searching.mp4

Before	After

• You'll note a few other UI adjustments to generally clean up the inserter as well. If we proceed down this route, those are separate concerns we can make individual PRs for.
• I am not proposing changing any default states of either the Blocks, Patterns, or Media inserter views—only search results.

Prototype

I have a Figma prototype to demonstrate this.

[fabiankaegy]

I'm in favor of the idea of keeping the inserted open. I think that would be great especially for working with patterns.

The only think about your proposed change I'm not sure about is moving the search bar below the tabs.

Currently it is a global search that surfaces both patterns and blocks. This behavior is very useful because it saves clicks when you want to search for a pattern. It would be sad to loose that with this. But given how the UI looks in your proposal the search is nested within the tabs

[annezazu]

I'd be curious to see a PR in place rather than just the prototype as it's hard to find edge cases, see how it interacts with other sidebars, etc. I do think this would work well with the work around zoomed out view though and when trying to build quickly as it is annoying if you're trying to add a bunch of patterns with the inserter repeatedly closing. I wonder if this could start as a user preference or if there's a reason for this not to be a user preference.

[richtabor]

Currently it is a global search that surfaces both patterns and blocks. This behavior is very useful because it saves clicks when you want to search for a pattern.

Yes, this would be a cost.

We can't have the search above the tabs + close button. For one, the close button should be in the same place in each sidebar panel. And secondary, in trunk those tabs do not render when searching, as the search results encompass both blocks and patterns. We'd end up with a conditionally displayed close button.

I'm of the opinion it's probably worth the cost. The rendered search results are more intentional; you see either blocks, patterns, and now media results (not possible in trunk).

[richtabor]

I'd be curious to see a PR in place rather than just the prototype as it's hard to find edge cases, see how it interacts with other sidebars, etc.

Agreed. I just wanted to see if it's worth exploring further via the prototype.

I just saw that #61048 does explore this path. It has a few rough edges but it lets you feel it out. I do think that #60991 becomes much more prominent if the Inserter remains open. I'd consider that a must-have.

[richtabor]

I wonder if this could start as a user preference or if there's a reason for this not to be a user preference.

I know we have the "Always open list view" preference, but I'm not sure if this should be a preference. The list view preference ensures the list view is opened when you first edit.

I think the expectation is that the inserter stays open, like other sidebars.

[fabiankaegy]

I'm of the opinion it's probably worth the cost. The rendered search results are more intentional; you see either blocks, patterns, and now media results (not possible in trunk).

I disagree that it is worth the cost here. There is a lot of user muscle memory built up for the search surfacing patterns. And it also does so in the inline inserter. So it would be a real disruption to take that away from the main inserter. We want to make it easier for someone that is new to WordPress and that has no idea what a Pattern even is to find them.

[richtabor]

Do you have any ideas on how to have the close button placed above search then?

Do we need a close button on this panel, if it does not auto-close (as seen on the Inspector, List view, and Styles sidebars)?

I'm open to ideas, though I'm not sure what we have today is working as well as we think.

For example, if I search for about, I get these results pictured below, which aren't exactly helpful; and the "Blocks", "Patterns" and "Media" tabs disappear. If I don't find what I'm looking for, the only thing I can do to add more context is to clear my search result, then scan the tabs' contents individually.

Having the tabs remain in place, at the top, keeps them within view and gives folks an opportunity to learn what blocks, patterns, and media are.

[richtabor]

Hiding UI usually makes it more confusing to use.

For ex, I thought about how trunk hides the tabs while searching (as search encompasses all results; not scoped to tab). If we did the same with this paradigm, we'd have to do something like this below — which makes it feel like the X closes the search state and returns you back to the inserter (not to mention double close buttons 😓).

[richtabor]

I think we could try leaving tabs and leaving search results in full.

It's worth trying out. How does that sound @jeryj? Keep the search filtering like it is today, where you get all contents. Perhaps active tab just sorts them (render's patterns first when the pattern tab is active).

[joedolson]

The accessibility team discussed this in bug scrub today, and we definitely like the proposal to keep the inserter open. It will increase predictability and consistency across interfaces, and - as observed above - is a significant improvement when inserting multiple blocks/patterns.

I think that the idea that the tabs act as a display mechanic to filter the search results makes the most sense, rather than sorting. Essentially, when no search is performed, they filter the results by type; when a search is active, they filter the results by type & the search query. I think it would be confusing, even in the context of a search, to see blocks showing up when the active tab is 'Patterns'.

That said, there would also need to be a way to clear the filtering, which means needing an 'All' tab or something to that effect.

[jeryj]

@joedolson - We were thinking of using the Blocks tab to search for everything as it does now, with Patterns being underneath of the Blocks results. This way people's muscle memory and expectation of the auto-focused input on the search would remain the same. When on the Patterns tab, it would only search Patterns.

[richtabor]

I agree that filtering may result in a better experience, potentially with an All tab, but @jeryj mentioned, perhaps advancing with caution by sorting, rather than filtering, may be the best foot forward.

Less change, but we still get the benefits of having the inserter opened.

[andreawetzel]

I'm excited at the possibility of leaving the inserter open until it is closed.

When we're training users who are new to the block editor I think it will be easier to teach to look for the x at the top right to close a panel rather than identifying which tab is open and toggling the active button state.

Keeping the search input above the blocks / patterns / media tabs is OK with me if it is needed to keep immediate search. Even though the inserter close button won't be in the same exact spot as the list view, it will still have the same context.

Currently, even with the Search above the blocks/ patterns / media tabs, it's a surprise that patterns are returned when I think I'm only searching blocks so I like the idea about adding headings above these search results to help with this context if this search field continues to search all the things.

The double close button is OK with me -- Having a clear button on a search field is expected and I wouldn't expect the search field x button to close this tab.

[jeryj]

When we're training users who are new to the block editor I think it will be easier to teach to look for the x at the top right to close a panel rather than identifying which tab is open and toggling the active button state.

I agree. Having a clear X in each panel will make it easier to identify how to close the panels consistently.

[joedolson]

Do we need a close button on this panel, if it does not auto-close (as seen on the Inspector, List view, and Styles sidebars)?

Yes, we do need a close button the panel. Since the panel constrains tabbing, it's not possible to navigate to the existing panel close button 'Toggle block inserter' using the keyboard. You can close using the esc key, but for predictability, there should be a close button in the panel that can be reached using the keyboard.

[jeryj]

Since the panel constrains tabbing, it's not possible to navigate to the existing panel close button 'Toggle block inserter' using the keyboard. You can close using the esc key, but for predictability, there should be a close button in the panel that can be reached using the keyboard.

@joedolson - The eventual idea would be remove constrained tabbing to allow focus to be outside the inserter and the inserter stays open. It would operate like the other sidebars.

[joedolson]

Would the inserter toggle move to be in immediate proximity to the sidebar? Otherwise, we're just dealing with yet another sidebar that's remote from it's trigger.

[jeryj]

Would the inserter toggle move to be in immediate proximity to the sidebar? Otherwise, we're just dealing with yet another sidebar that's remote from it's trigger.

No, it would stay in the DOM away from the trigger, but focus would be moved into the panel when it's activated.

I think this would be the implementation:

• Click inserter toggle
• Focus moves to inserter sidebar
• Close button visible and accessible in the inserter sidebar
• Activating the close button returns focus to the inserter toggle
• Maybe Escape keypress within the inserter to return focus to the toggle? Is this helpful or unexpected if it's not constrained tabbing?
• Inserter remains open until manually closed

[ndiego]

How would this interact with the List View? Would both panels be open at the same time?

[jeryj]

No, I'd imagine opening the List View would close the Inserter.

[joedolson]

As long as there is a close button in the inserter sidebar, I think I'm not too worried about the position.

I think that Escape should close the panel and send focus to the inserter toggle. These are essentially modal dialogs in behavior, except that they don't cover content. But if they have a button activation, move focus, constrain tabbing, and have a close that returns them to the trigger that launched the sidebar...then that's basically a modal. Might just want to make it completely a dialog.

But we may want to consider making all of the sidebar toggles work the same way: moving focus and having independent close buttons. That would improve predictability.

[jeryj]

But we may want to consider making all of the sidebar toggles work the same way: moving focus and having independent close buttons. That would improve predictability.

Absolutely. I'd like for all the sidebars to use the same base components and behavior.

But if they have a button activation, move focus, constrain tabbing, and have a close that returns them to the trigger that launched the sidebar...then that's basically a modal. Might just want to make it completely a dialog.

To make sure we're on the same page, the block inserter would not have constrained tabbing. It would include the predictable focus management between them upon opening and closing though.

[joedolson]

Without constrained tabbing, it's not a modal. However, I think that we're fine if we're consistent on all similar interfaces.

[scruffian]

This was closed by #61004