Gutenberg: 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 #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 #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]

1. 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 :slightly_smiling_face: , 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.

[karmatosed]

In exploring this today I noticed the following:

I think having only one library open at a time makes a lot of sense. Along with this, perhaps not resizing in way that gif shows would be less alarming.

[dawidurbanski]

I don't want to create separate ticket for such small comment, but It would be amazing if we could insert patterns into group blocks, or any blocks using InnerBlocks.

[MichaelArestad]

The more I use this, the more I want to drag a block from the inserter onto the canvas.

[samjco]

Some Comments.

@MichaelArestad I too 2nd the thought of dragging and dropping of the block items onto the canvas or perhaps have it both ways.

My thoughts on the Block Patterns would be "why not separate it out from the blocks?" Because patterns are more visual focus then the blocks are so I feel that it would be better suited in a large popup in the center of the editor. This way you would be able to share a clean spacious experience with given attention to the size and personality of each pattern.

If you keep it in the sidebar, many would want to drag it over. But a popup would allow them to scroll and see more choices at once and then users can simply click to place the pattern.

[pablohoneyhoney]

With the evolution of the overall Inserter user experience, we shall account for the three levels of searching/browsing:

Main inserter (considered browse), discussed above.
Slash inserter (preconceived input).
Quick inserter (contextual search), which is explored below.

The quick inserter seems in high popularity and a learned behavior that we can optimize from.

Contextualizing them

The Quick inserter

The intent of the Quick inserter and this issue in particular is:

• Align the quick inserter to the evolving new design UI language.
• Connect this behavior with the other inserters, namely the main inserter.
• Afford contextual addition of new blocks or patterns, without disrupting or obscuring the editing experience.
• Surface relevant options.
• Search becoming the primary interface, gaining major hierarchy and presence, while keeping all affordances intact.
• Create a system that is adaptable to different needs and situations.

The initial explorations

The suggested path

The flow would work as follows:

1. User wants to add a block inline, through the _icon-add-block_
2. Search pops in with two suggested blocks. The idea is not to expand beyond two to avoid cognitive load and an extensive UI.
3. The panel opens up in response to the search input. This sliding animation would need to work very nicely and seamlessly. References like Apple's spotlight or Framer work well as they are centered, while ours would need to work in the context of the position of _icon-add-block_
4. Users can trigger the larger inserter from here if they want to expand their search.

3 could be opened by default but it'd be good to test this stepped approach to avoid the current disruption of the panel in the editing experience.

Breaking it apart

The initial state surfaces the search behavior and a couple of recommended blocks (which can be dynamic), while also reinforces the expectation with the search UI on the left.

The different states

Disregard the labels, as they are abstracted at the moment. There are two UI options for Browse All that will open the bigger inserter. The preferred is the dark one as it holds the interface a bit more and separates visually that instance from the options above.

The idea is for the Quick inserter to have fewer options, to avoid obscuring the canvas, but this system permits flexibility and diverse casuistry.

Only with blocks, or only patterns

All blocks with labels

Affording more inserter capabilities

Without search

In limited situations

In cases like Navigation or Social links type of blocks with reduced options, this system stays relevant.

[MichaelArestad]

@pablohoneyhoney I absolutely love these. It feels like just enough context to do what I want quickly without a huge modal or too many options. Almost like a GUI for the slash search.

Just to clarify, when a user clicks "Browse all", does it open the sidebar inserter?
What led you to add the "Browse all" button instead of letting the user scroll through them all right there?

[pablohoneyhoney]

Thanks!

Regarding your question: It was considering this comment. Mostly to avoid the redundancy of inserters, to avoid obscuring too much the content, and to be more contextual as a quick inserter versus the larger and deeper searching/browsing experience.

[annezazu]

I just wanted to flag this new enhancement request for having a section for "most used" blocks as it seems it might align with some of what you all are hashing out here: https://github.com/WordPress/gutenberg/issues/22402 As more blocks and patterns grow, having easy access to most used seems like a great way to smooth out the experience for faster creation.

[mtias]

There are some concrete tasks to extract:

• Update quick inserter component with new design and support prop variants:
• 
  
  • Only blocks
  
  
• 
  
  • Only patterns
  
  
• 
  
  • Mixed presentation (default)
  
  
• 
  
  • With / Without search heuristics (number of blocks)
  
  
• 
  
  • With / Without suggestions
  
  
• Prune "Most Used" to just 6 blocks
• Make "most used" optional in the main inserter (add to settings)

[youknowriad]

Update quick inserter component with new design and support prop variants:

Who would tweak the presentation, does it adapt automatically, how?

[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
https://github.com/WordPress/gutenberg/issues/22858
https://github.com/WordPress/gutenberg/issues/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!

alt="Screenshot o the branch switcher popup on the Gutenberg repository" width="300">

---

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 #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: https://github.com/WordPress/gutenberg/issues/26905