Next Steps on the Inserter

[mtias]

There's currently several aspects of the inserter under consideration: categories (#19279, #11406), patterns (#20951), searches (#20196), tips (#17091), etc. In order to understand what updates we need to make to the inserter we should consider all of these together. The one that has a more drastic effect on it are patterns.

This is not an exhaustive list, but it highlights some of the current issues.

• The current inserter strikes a good balance on information density and not overpowering the page. Any updates should seek to retain this quality.
• Find an alignment on default categories and “open by default” for panels. The current state of categories is not scalable.
• Also account for collections (should likely be presented differently to categories) in the design updates.
• Reusable blocks are lost now that block categories overpower the presentation. Find a better way of presenting them.
• The current design proposals in Move the Block Patterns UI to the inserter #20951 pretty much obscure half the page. This is particularly problematic for the sibling inserter (we cannot open a huge module in the middle of the page). Do we need something simpler, an Alfred-like UI that lets you drill down as you need to?
• Take into account the quick inserter: should patterns be shown there? How would they be presented?
• The patterns shown in Move the Block Patterns UI to the inserter #20951 are also a bit too limiting and probably too small — how would it deal with taller patterns? At the moment, patterns won’t have an extra preview, so the default one should probably be large enough. As it stands, the preview of blocks themselves is larger.

[pablohoneyhoney]

With the intent to keep such a critical interface moving along, here is an attempt to address the above directives.

What to keep

• Retain the good balance on information density and not overpowering the page.
• The left vertical format as an expected paradigm.
• The previews for the blocks to connect intuitively with the actual content and canvas.
• Multiple insert inputs: slash inserter (preconceived input), quick inserter (contextual search), main inserter (considered browse).

What’s evolving

General alignment of the inserter with the latest UI.

Search becoming the primary interface, gaining major hierarchy and presence, while keeping all affordances intact.

Here with focus.

Categories opened by default, while allowing labels to show on focus. This system would afford any organizing principle, while I’ve leveraged here: Text, Media, Design, Tools per this try to summarize several discussions (#19279, #11406).

Hiding by default the labels can clear the browsing experience from additional cognitive load that might be relevant or accurate for some but not for other use cases.

The inserter panel grows more responsibly with the space, going down to 350 width and avoiding dead areas.

Current

New

Introducing collections with its own position and space. Currently, categories and collections are merged and presented equally.

At the bottom of the inserter

Tapping would slide up the top to browse that collection

Patterns integrated into the block inserter UI.

With one column (maybe initially).

As the library grows

Also affording filtering and pattern categories.

Introducing a new spotlight search for the sibling inserter, optimizing for a contextual search behavior: I don’t know what I want yet, or need to find it versus a slash inserter as a shortcut for I know what I want.

The different inserters side by side

What's next

1. Further explorations of search, results, and potentially gateways to other relevant actions –if you search for “page” and no blocks are returned, you can get access to adding a new page, or to see current pages.
2. Stress the behavior of spotlight search, and how to access the full inserter from it.
3. Collections, exploring how the panel opens sticking to the top to browse, as well how colors can play a role in these blocks.
4. Reusable blocks and how they live within the inserter.
5. Incorporating tips more consistently and contextually.
6. Motion tests and prototypes.
7. Refinement overall.

[shaunandrews]

Nice work, as usual.

--

I'm not sure about the move from the a popover to a panel. The popover had the benefit of not reducing the canvas' width, and disappeared once a block was inserted.

My assumption is that the panel would reduce the width of the canvas. If you have both the inserter and inspector panels open, the canvas would get very narrow. Also, I'd expect the panel to remain open once a block is inserted; Is that how you envision it working?

Hiding by default the labels can clear the browsing experience from additional cognitive load that might be relevant or accurate for some but not for other use cases.

I'm not sold on this idea. Without the labels I'm just looking at a bunch of similar icons that seem to be randomly grouped. You mention hiding the labels "by default," which makes me assume there would be a way to show the labels?

I think maybe the suggestion you provided for filtering patterns by category could also work for block categories.

Introducing collections with its own position and space. Currently, categories and collections are merged and presented equally.

Having a pinned area at the bottom of the panel might be problematic when considering shorter viewports. Also, the way the list of plugin collections slides up to the top tab bar means we'd essentially have two tab bars right next to each other. Perhaps the plugin collections slide up even further, overtaking the "Blocks" and "Patterns tabs?

Motion tests and prototypes.

I love me a good animation prototype. I've got a few ideas to try and will post anything worth while.

[pablohoneyhoney]

The popover had the benefit of not reducing the canvas' width, and disappeared once a block was inserted.

Currently the width of the inserter is 400 if I'm not mistaking, plus the empty space on the left that a popover leaves (about 80). Total 480 of area. The proposed panel is 350, still feeling open and clear.

[shaunandrews]

Currently the width of the inserter is 400 if I'm not mistaking, plus the empty space on the left that a popover leaves (about 80). Total 480 of area. The proposed panel is 350, still feeling open and clear.

Sure, the panel is more narrow, but as a panel, it doesn't overlay the canvas. Instead, it requires the canvas to reduce it's width. A popover doesn't disturb the width of the canvas.

[mtias]

Love this evolution! I quite like the "3 inserters" are getting a bit more focused refinement around what they are best at. The in-page inserter is something I see users reaching out for a lot more than the top-header inserter, so in many ways we should see it as the primary way for adding block to a document.

In that sense, it'd be good to show how search results (for blocks and patterns) would show up on it. I'd imagine we'd also need a way to expand results ("see more patterns", for example) which could actually open the main left panel and connect the experiences a bit more. If done well, it might map to:

• Quick Inserting: click on the pluses seen on the page, highly contextual, prioritizes search.
• Browsing / Explore: the main top-level inserting would function as the source library where you can explore more at length what's available.
• Power users: the / command allows users accustomed to the editing experience to go through operations quicker and without leaving the keyboard.

[enriquesanchez]

it'd be good to show how search results (for blocks and patterns) would show up on it

Here are a couple of explorations around search.

On the main inserter:

On the quick inserter:

I think that 2 columns for the patterns feels like a nice ratio between density and clarity. That being said, I used 3 columns on the quick inserter given that it's wider but shorter.

[shaunandrews]

Here's a few animations exploring both a sidebar and a popover:

[mtias]

For quick inserter we have to be careful with how things expand when searching since it can take over the entire page. I can see listing a row of patterns there and an "browse all" link that just opens the sidebar panel for a better experience.

[MichaelArestad]

I've been thinking about overlays (goes over content) versus sidebars (pushes content out of the way).

• Persistent sidebars are pretty handy when composing content.
• Persistent sidebars take up screen real estate.
• Temporary sidebars can cause all sorts of repaints (performance) from the browser having to redraw the whole screen every time the sidebar appears and disappears.
• Overlays cover content.
• Overlays don't move the content.
• Overlays are usually temporary (outside of FABs etc)

I'm wondering if we can't do both. I would love a persistent sidebar when I'm on a device with a large screen that lets me insert content when I wish (without even having to click the + each time. I also think it would be great if the Navigator was a persistent sidebar when there was space (like a layers palette in Figma/Sketch/Adobe products. I also see the need for an overlay that is temporary for smaller screen widths similar to how the top inserter currently functions.

[jasmussen]

I would love a persistent sidebar when I'm on a device with a large screen that lets me insert content when I wish

I think that's good.

[diegoliv]

I've been following the progress on Gutenberg and this ticket got me really exited to see what's coming! Personally I love the idea of the sidebar.

I'm a hardcore user of Beaver Builder, and they have both options: you can have all the settings on a overlay / modal box that floats above the content, or you can just grab the box and drag to turn into a bar (can be placed either left or right of the screen). Which is something that was mentioned on the comments above - having the ability to have both options. Personally, I work on a big screen so having the sidebar is what I like. Elementor is another example of a sidebar approach - not sure if they have the ability to turn into a floating box like the current inserter or not.

Now, forgive my ignorance, but any reason to not merge all sidebars into one? Right now we have the right sidebar that is a container for block settings and general post settings. Why not reuse the same sidebar to display blocks / templates whenever the block inserter button is clicked? If it's clicked - then displays what the mockups above are showing. If you focus on a block, change the context to the block settings, and etc. This way the problem of removing real state screen with two sidebars is solved. Sorry again if I'm missing something, since I'm not following all the conversations around the UI / UX updates.

[noisysocks]

4. Reusable blocks and how they live within the inserter.

If you squint, a Reusable Block is a user-created Block Pattern. Could the two concepts and interfaces be fused?

[jasmussen]

If you squint, a Reusable Block is a user-created Block Pattern. Could the two concepts and interfaces be fused?

I would avoid mixing those metaphors. Similarly, reusable blocks are not template parts, which was discussed in the core slack here: https://wordpress.slack.com/archives/C02QB2JS7/p1583520351475000 (link requires registration).

I'll quote the entirety of Matías outline for eloquence rather than distill it myself:

There are some considerable differences between the two, even if their internal architecture is mostly the same:

• Reusable blocks are meant to coexist with regular blocks as a way for the user to make snippets of content that are globally synchronised. (A testimonial, a “this post is part of a series” block, the “all birthdays” Matt has at the bottom of his birthday posts 🙂 , etc). They are primarily user content and could be conceptualised as custom user blocks.
• Template Parts, on the other hand, are the equivalent — in blocks — of theme template parts. They are generally defined by a theme first. They carry some semantic meaning (could be swapped between themes such as header -> header or footer -> footer) and can only be inserted in the site editor context (that is, within “templates”). They are primarily site structure and are never to be mixed with the post content editor.
• User roles might be configured entirely different for both of these entities, even if behind the scenes they are just groups of blocks saved somewhere in the database. Access to template parts should require theme editing capabilities while reusable blocks can be just “author” content.
• A template or template part can include a reusable block. A reusable block should not contain a template part.
• Block patterns are an entirely different thing in behaviour and presentation to the two of them since they are saved locally upon insertion and don’t exist globally. They are just blocks you insert with starter content that is meant to be changed by the user every time.
• Block variations, inner blocks, block templates, and so on, are developer APIs not to be exposed to users. A template in the context of the block API is just an array of blocks that can be passed to any inner block or editor instance as the way to initialize a block tree.

If I were to try and distill that, I'd extract these bits as the primary reason why we should keep block patterns and reusable blocks separate:

• Block patterns are just starter content meant to be edited. They're not locked or synchronized between pages.
• Reusable blocks are the most powerful when they are created and re-used as-is, and globally edited in one place.

[mtias]

If you mean the different variants, it would be based on conditions such as:

• The inner block content only allows certain blocks.
• • No patterns.
• • No "suggested blocks".
• Don't render search if total number of blocks is < 6.
• Don't render patterns if there are no registered patterns.

Then there would be cases where we want to force one or the other:

• Possibly only patterns for some FSE contexts.

[afercia]

Noting that I created two new issues regatding accessibility regressions introduced with the new Block Inserter. See
#22858
#22859

I'd kindly ask to fix them before release to avoid to... well release regressions. Thanks.

[diegohaz]

I've been thinking on a keyboard interaction model for this widget. And this seems to me very similar to the emoji picker that pops up when you press Command + Control + Space on MacOS:

You have a search field and a grid with items organized into groups.

The MacOS emoji picker works pretty well using the keyboard:

• Focus is trapped within the popup.
• Tab and Shift+Tab move focus between the first items on each category.
• Arrow keys move focus between the all the items, ignoring categories.

But it's pretty much unusable with VoiceOver. I've had a very hard time trying to do the most basic actions, like selecting an emoji. I think it's mostly due to the fact that it's composed by nested grids (they put an entire grid inside the parent grid's cell).

---

The Windows version doesn't have row groups, but there are tabs (both above the grid, like ours, and below). Also, there's no dedicated search box. You use the same text box you're writing on to filter emojis, which is in part a similar behavior when we start typing / on the editor to insert a new block.

Interactions:

• Focus is trapped within the popup.
• Tab and Shift+Tab move focus between the 3 widgets inside the popup (top tab list, emoji grid, bottom tab list).
• Arrow keys move focus between the items within the widgets.
• Focusing on a tab doesn't select it. You have to press Enter or Space.

It worked really well with JAWS and NVDA.

---

Another example is the branch switcher popup on GitHub. But I'll just leave this here as an example of what NOT to do. The interaction is really terrible!

---

For the block inserter I would explore something similar to the MacOS emoji picker (but, of course, working with VoiceOver) combined with the Windows navigation for the tabs or any other widget we need to include there.

• Focus should be trapped within the inserter popup/sidebar, which would address Regression: the new Block Inserter doesn't constrain tabbing #22858.

• Arrow keys navigate through the blocks in the grid.

• Pressing arrow down on the second last row in a category, when the last row has fewer items, moves focus to the last item in the last row.

  

• Pressing arrow down in the last row of a category moves focus to the item in the same column in the first row of the next category, if any.

  

• Pressing Tab and Shift+Tab would navigate through the search box, the tab list and the first items on each category.

  

• Typing any alphanumeric key while navigating through the blocks moves focus and type on the search box. And the interaction here should follow the combobox pattern, where you have a primary focus on the input, and a secondary focus on the results. This also removes categories.

  

  I'm not sure how to interact with the tabs in this context. On Windows, though, you can still press reach the tabs using Tab or Shift+Tab and you don't lose the primary focus on the text box.

[simison]

A couple small ideas that could nudge things towards good direction incrementally for patterns — curious for your thoughts!

Add link to all patterns in the inserter?

Could be "All patterns", "Browse patterns" or something else but the gist is that there's a quick access to patterns sidebar.

Add full screen pattern browsing experience

The patterns sidebar is great if you just want to keep it open while you modify your page, but it's harder for browsing because of limited space, especially when you've registered a lot of patterns.

Category dropdown doesn't feel like it can scale beyond few categories.

The above special patterns button could instead of sidebar open full screen pattern browser experience, not too different from what Squarespace has:

Link full screen pattern browser from the patterns sidebar

The patterns sidebar could have "Browse all patterns" button that opens the full-screen experience instead.

There's a trade-off between seeing your site while looking at patterns, vs having a great pattern browser. Both have their places.

Visually differentiate root level and inner-blocks level + button?

If folks click + button from inner blocks, they might expect to primarily insert blocks?
If they click + at the document root level, they might primarily expect to insert patterns?

Does it make sense to visually differentiate when you're adding something at root level, and perhaps show more patterns focused inserter in those cases?

Perhaps agencies would prefer to choose the primary interface action for their customers and have the root level inserter open directly block browser vs patterns browser?

Or perhaps leaning more to patterns makes sense in site editor, vs page editor?

[paaljoachim]

I made a new issue in relation to adding an expand icon to the patterns area. Mockups and a prototype can be seen here: #26905

[mtias]

Going to close this issue as most of the work is done. Improvements to patterns specifically (category listing, larger view) should carry on separately.