Semantic Patterns

[jameskoster]

Create a UI offering patterns that are contextual to the selected container, or the selected blocks container

When a template part (e.g. Header / Footer / Sidebar), or something like the Navigation block is selected, it may be helpful to offer ways to select patterns that suit the semantic purpose of the selected container.

Whatever solution we come up with for #28736 could be used here, but there is an additional use case to consider – what happens when the container is empty? In that case, perhaps the placeholder solution we come up with for #28735 could be utilised?

---

Expanding on this a little (we may need to split this in to a separate issue) – when a block inside a semantic container is selected, it may be helpful to expose both the "Single block transforms" and "Containers" UI patterns described in #28735 and #28736.

Example: Selecting a Site Title block in a Header template part might enable the user to discover a pattern that changes that block to a Site Title + Site Tagline combo, or: a more complex header pattern that includes search, navigation, logo, etc, which would replace the entire contents of the container.

[jameskoster]

I think the UI explored in #28735 (and consequently #28736) could be used here. Below are some examples of how it all plays out in respect to this issue, based on the latest concepts.

Applying a pattern to selected container, when the container is empty

In the video below I delete the Site Title block to empty the Footer. Upon doing so I am presented with patterns that I can scroll through and select, or I can elect to start with a totally blank canvas. It is always possible to expose patterns via the block transform popover menu.

footer.mp4

I think the main part of this flow to discuss is whether patterns should immediately present themselves once the container is manually emptied by the user. It may be confusing that, after deleting the last block, the container seemingly becomes populated with more blocks.

The alternative is to go immediately to the blank state, but this de-emphasises patterns quite a lot:

footer2.mp4

View patterns relevant to the container, when an innerblock is selected

This one is a little more complex, and may indeed be unnecessary. But it I think it is worth exploring even if only to rule it out.

In the video below I select the Site Title block, which is a child of the Footer. In the block transform menu I can access patterns that are directly related to the Site Title block, but since the context of the Footer is present, I can also jump directly to patterns related to that context as well. Doing so switches focus to the Footer, where I can select a pattern, or cancel and return to the original state.

container.patterns.mp4

The main thing to discuss with this flow is whether we need it at all :)

[Addison-Stavlo]

I will say that flow for previewing patterns seems really slick. I like it!

The main thing to discuss with this flow is whether we need it at all :)

Good point. If we have:

1. The contextual patterns shown in the sidebar inserter
2. a selection of patterns in the creation flow from the placeholder (similar to the query block).

will there still be a need for this implementation as well? 🤔

[jameskoster]

Assuming you're referring to the last demo in my previous comment, I would say that is much lower priority when compared to the container reverting to its placeholder state when emptied.

[Addison-Stavlo]

Assuming you're referring to the last demo in my previous comment,

Yeah

I would say that is much lower priority when compared to the container reverting to its placeholder state when emptied.

That makes sense to me. Now how do we distinguish between 'empty' to revert to the placeholder and the state triggered from 'Start blank'? Would 'start blank' actually start with an open paragraph block or something? I think there will need to be some technical difference between the state that reverts to the placeholder and the state of starting blank.

[jameskoster]

That is a very good point :D

Although this sounds very simplistic, I think could work ok in practise: If you elect to "Start blank" you should just see the inserter button inside the empty container. But if you then add a block and immediately delete it (re-entering the empty state) I don't think it would feel too bad to see the placeholder again. It is very easy to click "start blank" afterall. This would also be consistent with how the placeholders for things like the Columns block works.

[maheshwaghmare]

This is really impressive feature.

[stokesman]

It may be confusing that, after deleting the last block, the container seemingly becomes populated with more blocks.

That seems very likely and even once learned/expected may potentially be a nuisance.

The alternative is to go immediately to the blank state, but this de-emphasises patterns quite a lot:

What if there were a button to trigger the pattern choosing experience alongside the inserter button?

[jameskoster]

What if there were a button to trigger the pattern choosing experience alongside the inserter button?

Yup, I think that is what we'll do, probably via the UI we implemented in #30469, but a dedicated button next to the inserter is an interesting idea if we want to make it more prominent.

[jameskoster]

Just leaving a comment to highlight the experience in template part focus mode when no blocks are present:

This could certainly use some love and seems like an opportunity to implement some of the ideas above.

[jameskoster]

Here's a quick riff on the ideas above that simplifies things a little, and makes use of more recent design concepts like surfacing patterns in the quick inserter, and the pattern explorer:

pattern.mp4

Starting with an empty template part, the quick inserter can default to displaying patterns. The "Browse all" button opens the pattern explorer modal.

When a template part is selected, the transform menu reveals a direct pathway to the pattern explorer modal.

---

We can apply the same flow in focus mode when the template part is empty. But since the toolbar isn't present in this mode we'll need to think about how to expose patterns when the template part already contains some blocks. Using the top bar seems like a satisfactory option:

focus-pattern.mp4

Figma link.

[youknowriad]

Hey folks, I took a look at this issue and it seems that we already support "semantic patterns". You can see it live in 2022 theme as it registers patterns with the following property 'blockTypes' => array( 'core/template-part/header' ), which makes them available in the starting UI of the "header", "footer" variations.

That said, the UI is a bit confusing at the moment and we could use some work to both bring consistency for how we use these patterns across blocks and also improve the "focused mode/template part empty mode" to better embrace these patterns.

I think for the template part block we need is a placeholder state that does:

1- Allows you to pick a “template part” from the theme “template parts” attached to the current template area area (dark, light for instance in 2022)
2- Allows you to pick from a pattern attached with the current "semantic" block ( 'blockTypes' => array( 'core/template-part/header' ), )
3- Allows you to start blank

And it would be great for that same placeholder to be visible on the “template part focus mode”.

Also, that same placeholder could be used for “query” block (and similar blocks that have patterns attached to them)

---

Another flow that would be great to improve is the "Replace" button in the toolbar, right now it shows only the theme "template parts" for the given area and you're forced to remove everything before being able to pick from patterns again.

[jameskoster]

Allows you to pick a “template part” from the theme “template parts” attached to the current template area area (dark, light for instance in 2022)

I'm unsure how much we should prioritise this one.

1. If the theme author desires a certain template part, they can obviously just specify that in the code
2. Specific template parts can probably be exposed directly in the inserter (Expose existing Template Parts in the Inserter #31748). This makes them easier to preview and add, versus inserting a blank template part and then entering a convoluted flow from there.
3. Omitting this flow from the placeholder state allows us to achieve a simpler UI. Asking the user to contemplate theme template parts and patterns all at the same time might be too much.

The presence of an empty "header" template part suggests the desire to create something from scratch, therefore patterns feel the most appropriate focus. Existing theme-supplied template parts can be surfaced in the swapping interface which I agree should be considered as a part of this work (old issue here: #31747).

I still think the concepts above work well, but the placeholder state itself could be more engaging. Perhaps something similar to the Featured Image could work? Dotted lines to suggest contents, with an add button on hover:

Since the template part toolbar is fairly minimal we can possibly add a shortcut to the pattern explorer modal in there, rather than 'hiding' it in the transform menu. In the resulting modal theme-supplied template parts and patterns can be exposed with similar weighting.

[youknowriad]

The presence of an empty "header" template part suggests the desire to create something from scratch, therefore patterns feel the most appropriate focus.

These template parts created by the theme and assigned to "semantic areas" have nothing different than a "pattern" assigned to that "semantic area". When adding a header (inserting a header, or footer from the inserter), these two should get equal treatment, and when replacing I think as well. For the user it's very hard to make any difference between these two, same for theme authors. The only difference is that "template-parts" here are only provided by the theme while patterns can be provided by both the theme and the pattern directory.

I still think the concepts above work well,

What exactly you mean by "concept above" here. There's a number of designs above and it's not clear to me what this refers to. Also some of the designs there are already implemented like the ones here #28737 (comment)

Omitting this flow from the placeholder state allows us to achieve a simpler UI. Asking the user to contemplate theme template parts and patterns all at the same time might be too much.

I understand that it's too much and maybe very confusing to the user to have both but we already have this concept of template parts and template parts areas in, we can't just remove it, it's the main purpose for this concept (being used in these empty template parts headers and footers)

[jameskoster]

What exactly you mean by "concept above" here

Apologies, I was referring to the most recent comment. I'll update with a link.

I think we agree in a roundabout way :) I will mock up the flows in a more detailed way to confirm.

[jameskoster]

Ok, here's a diagram illustrating how we might use a modal to satisfy all of the requirements you outlined for the placeholder state, as well as contextual "transforms" when a header has already been selected:

I've essentially combined your points 1 & 2 into a single flow, which hopefully makes it simpler to interpret.

Previously I augmented the quick inserter since that makes starting blank easier, but it's not necessary. We can skip straight to the modal like in the diagram.

Feedback is still very much welcome and encouraged on this. In particular I'm wondering:

• Does the modal need to differentiate between theme template-supplied entities versus the directory?
• Should it be possible to select generic patterns as well, or restrict only to semantic ones?

[youknowriad]

Does the modal need to differentiate between theme template-supplied entities versus the directory?

I think maybe differentiate between "patterns" and "template parts" because template parts will result in a different "template part entity" being used. That said, for the user it's very hard to understand, so we can explore and see.

Should it be possible to select generic patterns as well, or restrict only to semantic ones?

I think when you insert "header", "footer", it should be semantic ones, but maybe we can show more when you insert the generic "template part" block. Also, open to iterations there, we'll see how it goes.

Some questions

I guess the same modal here should be applied to "query" block as well, is the placeholder shape something that changes between blocks, between "areas"? Do we have a generic fallback for any other block?

[jameskoster]

I guess the same modal here should be applied to "query" block as well

Yes I think so, plus any other block that would make use of this feature (columns, galleries, comments loop/form, etc). On that subject, a nice thing about the modal is that we have an option to trigger it directly from the inserter if appropriate:

The placeholder shape should probably change, with a very generic fallback – could even just be a dashed outline.

[mtias]

@jameskoster do we have anything actionable left here that is not captures in other issues?

[jameskoster]

No I think we can close. – the "Replace" flow covers most of what we wanted to do here.