Block Patterns: Add ability for predefined block layouts to be added to a document

[mapk]

Block Patterns are becoming a requested feature. With the advent of Gutenberg, the blank canvas has become a bit more frightening. Rather than just worrying about content, now people also worry about page layout. While it's easy to wrangle with Gutenberg, the blank canvas leaves more questions than answers.

Adding a feature to include Block Patterns would be ideal!

Themes would be able to register block patterns. With this in mind, this feature could potentially eliminate all support questions of "How do I make it look like the demo?" 😱

Questions:

1. Should Gutenberg include some default block patterns?
2. Which UX flow for this system works best? (a couple examples below)

---

UX Example – Overlay

Prototype

---

UX Example – Sidebar

Prototype

cc: @epiqueras @youknowriad I'm not sure if this relates to some of the content areas and CPT work you've been doing.

---

Todo:

• [x] Design a list of default patterns to embed in Gutenberg.
• [x] Build an MVP UI that allows inserting these patterns (potentially just a sidebar plugin).
• [x] Update the block inserter to show both blocks and patterns according to the last designs.

Potentially outside the scope of this issue but still part of the same project

• [ ] Build a way to create, save and edit patterns.
• [ ] Build a block patterns repository on wp.org.
• [ ] Allow installing patterns from the repository.

[jasmussen]

Thanks for working on this Enrique!

I have on purpose constrained myself to work within the space provided by the current block inserter. I've done this for two reasons:

• It'll make it easier for us to translate this UI to small screens.
• For the average screen size, I feel that the current inserter already takes up enough screen real estate. So I believe that a bigger, centered modal won't provide much benefit.

I disagree with this. We have good ways to translate a modal to phones (fullscreen), and we can show one column of patterns instead of two and three.

I say this having explored designs not too dissimilar to your own, so I am also disagreeing with my past self.

What I realized was that if we are to show vast luscious block patterns we need all the space we can get. This was a matter of connecting the dots outlined by Mark and Rich, resulting in these mockups (Figma file).

[jasmussen]

I took a stab at a block library that takes up all available vertical space, removes the help text, and detaches the preview window in #19836. It can serve as a prototype for the overall idea.

[jasmussen]

Enrique I'd love to work with you on bringing some of your finesse to the tall vertical mockups shown earlier on. Here's the Figma file: https://www.figma.com/file/fnyj380i05vGzuuH60frLQ/G2-Design?node-id=85%3A6975 — notably it works well on the desktop breakpoint, but the mobile breakpoints aren't fleshed out yet. I'm always up for a chat also, if that's at all helpful.

[enriquesanchez]

hey @jasmussen! 👋

Here's a quick mockup combining your tall vertical mockups with some block pattern previews:

I like it. The big previews feel good at this size. One issue I'm having is that I'm not sure that accordion categories work well for navigation and discoverability when the previews are this big.

I spent some time exploring the idea of having the categories on the side instead:

I think this makes it easier to scan the available categories, but it pushes the categories for Block Patterns way down, and I'm not sure I feel this is right.

Let me know what you think.

[jasmussen]

Here's a quick mockup combining your tall vertical mockups with some block pattern previews:

This is stellar! Notably seeing patterns in the vertical interface is very enlightening, and works slightly better than I had assumed.

The categories on the side aren't bad either, though I wonder if they are better served as a dropdown when in the top left popover version, but they might work well in the dialog version opened by the sibling inserter?

Thank you for this! I'll let others chime in as well.

[enriquesanchez]

Here are a couple more explorations iterating on the recent mockups:

1. Tabs for Blocks and Blocks Patterns + list for categories

2. Tabs for Blocks and Blocks Patterns + dropdown for categories

I think 1 feels right. I like how the list of categories is fully visible (better for discoverability), and I think this should scale well.

While 2 feels tidier, I'm concerned that the list of categories is hidden behind a click, and thus affecting discoverability.

@jasmussen @mapk @shaunandrews what do you think?

[richtabor]

I think 1 feels right. I like how the list of categories is fully visible (better for discoverability), and I think this should scale well.

While 2 feels tidier, I'm concerned that the list of categories is hidden behind a click, and thus affecting discoverability.

Looking good @enriquesanchez! Number 1 feels right to be as well.

A few thoughts:

a. We'll need to figure out a mechanism for what happens if there happen to be a loooooong list of categories.

b. How should categories be ordered? Is there a priority via the theme, then plugin? Alphabetical? Or a combination?

c. If the theme registers patterns for different categories, do the patterns appear in the "From theme" category, as well as each pattern's specified category?

[jasmussen]

An echo for Rich's comments and questions, wonderful summary. Nice work!

One thing to consider is that per the current thesis, the library shows as a big dialog when opened from the sibling inserter, and conversely is smaller when opened from the top left. We could default to the categories on the side and collapse them into a dropdown when responsive challenges dictate it.

b. How should categories be ordered? Is there a priority via the theme, then plugin? Alphabetical? Or a combination?

Probably will end up being a combination of a few "blessed" ones at the top, and then alphabetical. Until a point where plugins name their categories __Sweet Blocks or 1. Sweet Blocks. It seems like one of those things we can risk overthinking now, and since it's easy to adjust down the road, we might as well go with the simplest solution and tweak when necessary.

[enriquesanchez]

@richtabor @jasmussen thank you for the excellent feedback.

a. We'll need to figure out a mechanism for what happens if there happen to be a loooooong list of categories.

Agreed. I'm not familiar if something similar has been needed for the block library and if we could learn from it.

b. How should categories be ordered? Is there a priority via the theme, then plugin? Alphabetical? Or a combination?

I echo Joen's suggestion. Some initial order needs to be established and look at iterating when/if the system gets broken.

c. If the theme registers patterns for different categories, do the patterns appear in the "From theme" category, as well as each pattern's specified category?

My initial reaction is yes. I expect some patterns will appear under different categories. I think that's OK. The idea of having a "From theme" category is by no means final, but I thought it would be an easy way to help folks have their site "look like the demo".

I'm going to continue iterating on this. I'll work on some prototypes to get a better sense of how the library will look and feel.

[timhibberd]

I found the mobirise approach practical in the field. They have two block-panel selection columns...one grouping block-panels thumbnails under the common page categories (Header, Menus, Content, Footer, etc) with an adjacent category index so you can see all the categories and jump directly to a category of interest.

Not pushing this as "THE" solution. I just thought you might find it useful as an example and then translate what you do / don't like about it over to the design you want.

Just a suggestion :-)

[mapk]

Thanks for giving it another go, @enriquesanchez!

I'm in favor of number 1 too. Having the list displayed prevents the user from having to jump through a series of clicks to get to their desired result. Having it collapse as Joen suggested for responsive screens sounds very interesting.

I don't know of any mechanism currently in Gutenberg that handles long lists, so that is something that needs to be thought through. Separating the Blocks from the Patterns through the use of tabs helps already. Kudos on that one!

"From theme" feels a bit odd. Maybe "Theme patterns" or just "Theme" or even "Theme: [theme name]". Maybe these should be prioritized at the top? I'm okay with keeping them together under the "theme" category AND exposing them under the relevant categories as well. Maybe this becomes something like a "collection"? https://github.com/WordPress/gutenberg/issues/19873

I noticed in the mockup that even though the "Patterns" tab is highlighted, the search field says you can search blocks and patterns. Is this right? Or should I be limited to block patterns while under the Pattern tab?

[paaljoachim]

Here is a mix of the wireframe Obenland shared: https://github.com/WordPress/gutenberg/issues/17335#issuecomment-536109796

and Enrique's number 1 wireframe suggestion: https://github.com/WordPress/gutenberg/issues/17335#issuecomment-582673937

Here is the existing Blocks area plus additional options:

When selecting the Block Variations tab it can change to something like this:

Edit: Using the existing interface but extending it for additional options would keep a consistency in how we select blocks today. One would still go to the same inserter area to select blocks. But this time one can also choose from Blocks (single blocks) -> Block Variations (multiple blocks) -> Page Layouts (templates) -> Site sections (header, footer etc).

[shaunandrews]

One thing to consider is the placement of the search box, and what that implies. With your latest designs @enriquesanchez the search box would be repeated for each of the top tabs (blocks and patterns), which makes me think that I can only search one group at a time. My initial hopes here was that we could have a single input to allow searching across both blocks and patterns.

Maybe that's a misguided hope, or maybe I'm not understanding how the search input works.

[enriquesanchez]

I noticed in the mockup that even though the "Patterns" tab is highlighted, the search field says you can search blocks and patterns. Is this right? Or should I be limited to block patterns while under the Pattern tab?

With your latest designs @enriquesanchez the search box would be repeated for each of the top tabs (blocks and patterns), which makes me think that I can only search one group at a time.

@mapk @shaunandrews Thanks for the feedback! Not sure why but somewhere along the way I moved the search box because I initially had it on top of the tabs (see https://github.com/WordPress/gutenberg/issues/17335#issuecomment-575835877).

I agree with @shaunandrews , I think the search input should be the first element in the inserter (as it currently is). It's the first thing that is focused after I open the inserter, it's efficient and global.

[mapk]

I think the search input should be the first element in the inserter (as it currently is). It's the first thing that is focused after I open the inserter, it's efficient and global.

Can you also explore what this might look like? When a search query returns results in both block and patterns, how does that look?

[enriquesanchez]

I spent some time looking at how blocks will be displayed if we present a bigger modal for the block library, as it has been explored on this issue.

I keep leaning towards having a left-side list for the categories, like the first example on this previous comment.

So what if we followed the same pattern but for blocks? This means we would move away from using accordions like we currently do. This also means that for most categories, there would be A LOT of unused space:

Obviously, this is not ideal.

Another iteration led me to the idea of having a continuous list of all block categories, and have the links on the left-side list to scroll you to the corresponding place. Something like this:

I imagine that if I went ahead and started scrolling (instead of clicking on one of the links), the active state on the left-side list will update accordingly to communicate position.

This solution makes much better use of space, and we keep a few things that I like:

1. The list of all categories is always visible, meaning that discoverability and exploration benefit.
2. We no longer need to click to open a category accordion, and because the list of all blocks is now scrollable, navigation becomes easier.

What do y'all think?

[jwold]

@enriquesanchez I love this exploration.

1. Would we get rid of the previews in this kind of scenario? (I'm not necessarily opposed to that, just curious)
2. What would happen if a category was too long? (Example: https://d.pr/i/DSsHTW). Would it just wrap into a new line? In that case I would just make sure that categories have more space between them so there's no confusion.
3. I love the continuous scrolling as opposed to accordions.

[richtabor]

Looking good. Question though. Do we need to clarify "Block" in "Block Patterns"?

[enriquesanchez]

Thanks for the feedback @jwold and @richtabor 👍

Would we get rid of the previews in this kind of scenario?

I'm leaning towards that, but only for blocks. The preview seems to be very useful for patterns. I also like that visual distinction between both: blocks = small icons, patterns = bigger thumbnails

What would happen if a category was too long?

I agree, they would wrap, something like this:

I love the continuous scrolling as opposed to accordions.

🙌

Question though. Do we need to clarify "Block" in "Block Patterns"?

@richtabor That's a good question. So you suggest we use "Blocks" and "Patterns" ?

[paaljoachim]

Btw I think Patterns have been renamed to Variations.

[mtias]

Btw I think Patterns have been renamed to Variations.

Variations is unrelated to patterns — it is a technical part of building blocks and is not exposed in the UI as a term.

[enriquesanchez]

I explored different variations of the block library when invoked from a sibling inserter (somewhere in the middle of the document).

1. Popover

This is very similar to what we currently have, just a bit bigger:

2. Big modal

Should make it easier to navigate patterns. I'm not sure I like the fact that it covers the content behind it.

3. Slide-in panel

Suggested by @mapk. Very similar to https://github.com/WordPress/gutenberg/issues/17335#issuecomment-585425675 in terms of size and placement. Makes me wonder if the slide-in could be the default pattern for both the top-toolbar and sibling inserters 🤔

[enriquesanchez]

Here's a simple click-through Figma prototype that brings it all together.

Try opening the block library from the top toolbar, switching between the block and block patterns tabs, and searching. Finally try opening the block library from the sibling or middle of document inserter.

❗️ Note: inserting blocks and patterns is not yet available in the prototype.

[paaljoachim]

Hey Enrique @enriquesanchez

Having a simple Figma prototype really makes a huge difference. As it really gives a feel for how a finished version would feel like.

The Blocks screen really gives a better overview of what exists today. One can easily see available blocks without having to open accordions to see which blocks they contain. There is also more space available.

A Saturday morning eye and mind exercise...:) The mind/eyes move around noticing the Most used and Common blocks area that contain symmetry and balance.

When the eyes wander over to the left it sees a list going downward starting with Most used and ending with Embeds.

Most used is in blue. Above it is another blue color a line below the Blocks bold text (mind does not know why the blue line is there as it is so far from the Blocks word it seems separate. Logical I know why.). To the right Block Patterns not in bold with no line below it. Below is a Most used text in bold. Further above my mind sees the border outline of a box and the Search text inside it and is able to once again relax.

That means looking at each little element and how they relate to what is close by and the overall area it is in.

[carolinan]

Hi.

There has to be room for a text based presentation of the block pattern. Not all users will be helped by a preview image.

[enriquesanchez]

Thanks for the feedback @paaljoachim and @carolinan! 🙏

There has to be room for a text based presentation of the block pattern.

I agree with you. I'll be adding more fidelity to the prototype, including block/pattern descriptions on hover, we need to make sure these descriptions are communicated to AT.

[richtabor]

2. Big modal

Should make it easier to navigate patterns. I'm not sure I like the fact that it covers the content behind it.

For the sibling inserter, this feels the most natural, though a hi-fi mockup may help us decide better. Perhaps doing the core modal dark background will help bring focus to the modal (pictured below).

Provides enough viewing space for the user to properly make out the individual patterns - giving them a clearer idea of what will be added to the page. We could even keep the patterns to two columns wide - ensuring they are properly viewable.

3. Slide-in panel

Suggested by @mapk. Very similar to #17335 (comment) in terms of size and placement. Makes me wonder if the slide-in could be the default pattern for both the top-toolbar and sibling inserters 🤔

This is interesting, though I feel it'll be too disconnected from the sibling inserter. And if we're blocking the view of the content/site behind it anyhow, I'd say going for a full modal makes better use of the space. Our attention should be dedicated to the patterns/inserter at this point.

[richtabor]

Also, these won't be screenshots - but "examples", much like how style variations support examples - correct?

Example of an example:

[richtabor]

@richtabor That's a good question. So you suggest we use "Blocks" and "Patterns" ?

I'd say so.

[youknowriad]

I started decomposing this to small iterations and added a todo list to the issue description. This is not an exhaustive list and we'll most likely discover things as we move forward with implementation. Some of these items might not be implemented as part of this issue.

[skorasaurus]

For what it's worth, it would be really helpful to edit the original comment to succinctly define what exactly a block pattern is and how they are different from block templates.

This would be helpful to expedite the process of onboarding potential contributors; and remind core members who are looking to brush up and getting up to speed on this area; and to make sure that all of the contributors are on the same page (pun intended).

There has been some confusion among existing core members (also read the comments that immediately follow the linked comment) about the conflicting usage of terminology with templates.

From reading the first couple comments, I was unsure how "block patterns" are different than inner templates (that can be reused across multiple post types, are not required to be tied to a specific part of a page).

From what I gathered; block patterns series of blocks that are layout ; but the content inside the blocks has not yet been defined by the user and that the content is the same and are they intended to replace template.php files? (it's complicated that a template in WordPress can represent nearly all of the page or it can be abstracted to consistent of 3-4 additional template files (inner templates)

Would a block pattern be solving a use case of "I need a callout block that would consist of multiple blocks: a heading (whose heading level I'd be able to customize based on semantics) a paragraph block, and a link to register for an event") ?

[mapk]

Pattern Previews

I saw this the other day. It's an example of how the preview follows the vertical position of the cursor. If we go the way of a detached preview, this might be worth exploring.

[shaunandrews]

an example of how the preview follows the vertical position of the cursor. If we go the way of a detached preview, this might be worth exploring.

I actually think that having the preview in a fixed position might make it easier to scrub items in the list — you can keep your eye in the same space.

[mrleemon]

Just a question. Will block patterns allow to define locked areas, so users cannot change the basic structure in a block pattern? For example, will we be able to lock the number of feature areas in the attached block pattern, so none can be added or deleted? Are you considering this use case?

[enriquesanchez]

hi @mrleemon!

We have not considered that scenario. As of right now, block patterns are intended to be sections users can add and edit as necessary. This also means adapting the content to their needs.

Would you mind elaborating a bit more about the use case you shared? When or why would it be useful to have it?

[mrleemon]

@enriquesanchez

I'm thinking of a one-page design with a series of group blocks in a specific order allowing users (with the editor role, for example) to modify the content of those blocks, but not delete them or change their order, so the menu anchors at the top of the page continue matching the page structure.

[creativecoder]

Would you mind elaborating a bit more about the use case you shared? When or why would it be useful to have it?

From past client work, I've also heard this request, usually from larger organizations with specific editorial workflows. Usually they want to provide an approved layout for a specific type of content, and then have authors who can edit the content (images, videos, text, etc) within the layout, but not change the layout itself. The reasoning behind this is usually to maintain consistent design and branding for content across the site(s), even when many different people are generating and editing content.

[mrleemon]

have authors who can edit the content (images, videos, text, etc) within the layout, but not change the layout itself

Yes, basically having the ability to lock layout-type blocks (groups, columns, etc.) would be great.

[jasmussen]

I know for a fact this has come up before, and I could swear there was some locking aspect to templates that would let you accomplish this, but it escapes me. In any case, the use case seems legitimate, and interesting to solve.

[mtias]

This is definitely available when creating templates. Since it's lower level API, it's not accessible from the pattern creation level yet.

[paaljoachim]

Here is a suggestion based on the newest mockup from Rich's @richtabor Big modal 2. https://github.com/WordPress/gutenberg/issues/17335#issuecomment-587951100

Big modul vs small modul. There could perhaps be an icon somewhere to make the inserter screen smaller. One clicks the smaller icon and Block inserter becomes small so that one can focus on the one pattern one is thinking about using in relation to the content of the layout.

I have continued Rich's mockup and added Use and Edit and a lock icon. This means the user can edit a pattern or reusable block. Edit is not available where the admin has locked the pattern. User can click Use, Title of pattern or the pattern itself to directly use/insert into the layout. I have also moved the blue underline closer to the selected area.

Alternative. Use a Settings gir to create a drop down that shows Edit (if object can be edited) then Import and Export etc.

Clicking Edit. Focused area for only editing a pattern/reusable block.

[youknowriad]

The initial version of this is done. There are still some follow-up tasks here (searching, categories...) I'm going to close this issue though as we have this one #21080 with a good list of follow-ups.