Site Editing: Increase prominence of contextual patterns when template editing

[jameskoster]

It may be helpful to somehow expose patterns related to the template being edited. Example: post loop patterns when editing the category template, or 404 patterns when editing the 404 template.

This could be achieved by having the Inserter default to exposing patterns when the user is at the root level of the block tree.

[jameskoster]

Similarly, when the cursor is inside a container like a template part, patterns in the inserter should emphasise those that are contextually relevant to the container.

[jameskoster]

Here's an initial take on this:

Adding a new template

When adding a template from scratch, if layout patterns associated with that template exist, we might present them to the user as "quick start" options, rather than relying on a duplication of the contents of the templates closest relative. The closest relative should still appear here as an option though. Granted this may require expansion to any pattern API we implement, so that patterns can be marked not only as relevant to a template, but as a template layout as well.

Of course there should still be an option to skip this interstitial and commence template creation with a truly blank canvas.

choose.a.pattern.mp4

Starting from scratch

When a user elects to skip starting with a pattern, and the template exists in a truly empty state, I think it would be worthwhile increasing the prominence of patterns in the Inserter. This will allow folks to get started more quickly in comparison to inserting blocks one by one.

In this case the holistic layout patterns from above could potentially be omitted. I am on the fence a bit there, seeing as the user specifically skipped choosing one. Then again, after attempting to create a template from scratch, they may decide to choose a preset pattern after all. There is also a scenario in which the user may have deleted all the blocks in an existing template to start fresh, in which case they wouldn't have seen the pattern suggestions at all. Food for thought.

Small template-specific-patterns should also be highlighted here. In the example video below I find a "Title + Excerpt" pattern in the Inserter because I am editing the Post template. This is just an example, and no doubt the actual patterns exposed here will be more elaborate.

Insert.title.+.excerpt.pattern.mp4

Template part patterns

Finally, when a user seeks out patterns while inside a template part, they should find patterns that are relevant to:

• The template part
• The selected innerblock (if one is selected)
• The parent template

Patterns that match all three of these conditions may exist. For example while editing the Header of my Post template, I may find patterns that include the Post Title inside the Header template part.

As a very basic example, the video below demonstrates how a user might be presented with Header layouts that consume the Site Title block, when it is selected:

suggest.patterns.based.on.container.mp4

Challenges to consider here:

• Do we present patterns that match all conditions, or some conditions? IE do we use an AND or an OR method to match patterns.
• How do we order the patterns?
• Upon insertion, should the pattern replace the selected block like in the video, or be appended to it?

[Addison-Stavlo]

👋 @jameskoster - Re: Template part patterns in the sidebar inserter / your last video above.

@creativecoder and I hacked up a rough exploration of this. Specifically testing out patterns representing full template parts (copies of tt1-blocks header/footer). It seems to raise quite a bit of questions as outlined - #29595 (comment)

Upon insertion, should the pattern replace the selected block like in the video, or be appended to it?

While it does seem that replacing may sometimes seem more fitting in this context, I think it is important that the behavior of the inserter stays consistent. If in some places it appends and in others it replaces this could result in quite a confusing user experience.

Do we present patterns that match all conditions, or some conditions? IE do we use an AND or an OR method to match patterns.

If we go with the 'OR' option, that means a full template part pattern would be shown when we have an interior block selected (like a site tagline inside a column). Here, neither appending nor replacing would add the full template part pattern well. For it to be added well, it would need to be added to the top level of the template part (or replace everything in the template part). This would create more inconsistent behavior between types of patterns.

Given that inserting these contextual patterns might have to behave a bit differently than standard patterns from the inserter sidebar, I am starting to wonder if the inserter sidebar is not the right place for some of them to live. 🤔 Perhaps contextual patterns that represent sub-sections of template parts make sense here, while full template part patterns only belong in the placeholder state or something?

[jameskoster]

Once #37258 lands, empty template states will only exist if a user manually deletes all the blocks on the canvas. So I think this might be the part to concentrate on initially:

This could be achieved by having the Inserter default to exposing patterns when the user is at the root level of the block tree.

I shared a concept in #28737 (comment) that we can reuse for this purpose. Here's a demo:

404.mp4

The quick inserter defaults to the Patterns tab and surfaces contextually relevant options. The 'Browse all' button opens the pattern explorer modal where you can view general patterns if required.

Whether this behaviour only occurs at the root level may warrant further exploration. I suspect that would be most useful as a 'v1', and eliminate any potential frustrations when working with containers inside a template.

Figma link.

[jasmussen]

Nice. #36697 and the explorations there feel very complementary to this one.

[jameskoster]

The most important use case here is surfacing patterns during initial template creation. Recent developments handle this by presenting the closest template in the hierarchy as a fallback, plus any contextual patterns as options. There's room to polish the design in those flows, but I think we can close this issue and tackle any smaller details piece by piece.