Create a UI that suggests patterns that are contextual to the currently selected block

[jameskoster]

When one or more blocks are selected, there should be a UI which presents options to "convert" that block(s) into a pattern which consumes it/them, and preview the selected block in context of the suggested pattern(s).

A rough starting point:

The tricky thing here will be working out which patterns to present... Quoting Matias:

1. We could restrict multi-block transformations to patterns that match exactly the block types of the source. So a paragraph, an image, and a heading would be matched with patterns that have those blocks and nothing else.
2. Transformations could be more loose and expose more patterns, even if it needs to discard some from the original selection. In this case, the transformation would happen on the fly on a best-guess case, assigning blocks to corresponding blocks when it cans, dropping extra ones, and using the pattern to fill in extra blocks.
3. There could be a priority queue for some mappings (i.e if a pattern is made out of two paragraph blocks and the source is a paragraph and a quote, the quote could be transformed into a paragraph since that is an allowed transformation on the Quote block). This can get a bit complicated to reason about and is unclear what tangible value it might bring in the end.

[jameskoster]

It is looking likely that the direction we're heading in for #28735 could inform the UX for this issue as well.

The video below illustrates how the UI there translates to multi-block transforms. I think it woul work just as well for single block transforms as well.

transforms.mp4

After selecting two images and opening the pattern selection interface I am able to view patterns that consume two image blocks, or even two cover blocks since they are closely related.

The UI will no doubt continue to evolve based on feedback in 28735, but I think it would be good to start thinking in more detail about how we determine which patterns to display here, and the order in which to display them.

I posited this elsewhere:

From the UX perspective, I imagine we'd want to present the most closely related patterns first. Perhaps counting the blocks in the pattern is a simple way to do that? So with the Image block, loop through patterns than contain a single Image and present them ordered fewest total blocks to most? I suppose some will always need to be hard-coded though, like presenting the Cover block when transforming an image.

Let's discuss here. cc @DaisyOlsen.

[DaisyOlsen]

Thanks for pulling me over here @jameskoster. I've been on a bit of a mission to teach people to register block patterns, so this is quite relevant to me. I do like the larger modal, as I think the sidebar preview doesn't do a lot of visually interesting blocks justice.

Related to how patterns surface in the transformation modal (or sidebar) I have open questions about how those registering block patterns could identify that the blocks could be transformed (or not) - If there is a way to do this in a smart way that doesn't add any extra requirements for those creating block patterns it would be ideal.

I also wonder how this might be affected by the addition of a block pattern library. Should it be possible to transform from a block to a pattern that is in the directory?

[jameskoster]

If there is a way to do this in a smart way that doesn't add any extra requirements for those creating block patterns it would be ideal

Totally agreed. As above, if we can pull in patterns that contain the selected block dynamically, that could work well. Mightn't that be quite an intense request though, if there are thousands of patterns to loop through?

Should it be possible to transform from a block to a pattern that is in the directory?

Yes, I think there should be a way to view only local patterns, only directory patterns, or a combination. That is probably something to explore separately though (at least on the design side).

[jameskoster]

Driving by to leave a note that the modal pattern suggested in #31033 can also be applied here.

Clicking the "Patterns" link in the menu item would trigger the modal carousel.

[hedgefield]

Either of these approaches seems like a great start, with the modal probably being easier to browse, while the inline approach gives it a bit more WYSIWYG flavor.

I find it hard to say something definitive on how to handle the matching, it sounds quite complex. At least it would not occur to me to select a bunch of blocks and then look for a pattern that could apply to those, I'd look in the pattern library for something matching what I had in mind, and otherwise try to build it myself.
But thinking of it in the same way as an autocomplete, selecting just one block should probably show the widest range of patterns, starting with the most relevant. The more blocks you select, the more specific the suggestions become, until perhaps your selection is so large that we can't really match any pattern against it.

[jameskoster]

Even if you build something yourself, it can still be fun to browse patterns that utilise the same blocks – you might be inspired by something different!

So yes, I agree – when there are multiple blocks, patterns that match the selected blocks 1:1 should be given more prominence. In truth, I find it quite difficult to come up with logic to suggest patterns for situations where no 1:1 matches are found. It all starts to feel quite costly in terms of the query we'd need to run.

[cgaits]

Here is an idea I put together at the design meeting. Any further direction would be appreciated.

[jameskoster]

Thanks for sharing @cgaits. The challenge in the UI here is twofold:

• Display preview thumbnails that are large enough to be useful
• Make it easy to navigate and select a pattern when there are many options

This concept is quite easy to navigate – although I'm not sure how it scales when there are more patterns – but the size of the thumbnails seems quite small to me, and I'm wondering how the interaction works on mobile.

I keep coming back to the idea of displaying patterns in a modal (#31033). It creates a space for large previews, scrolling, searching, and even view modes like grid, list, and carousel. Best of all it is portable across different flows and interactions, for example creating a template part from scratch (#31746).

[youknowriad]

The first iteration of this landed and I'm removing this from the 5.8 board as we're passed the feature freeze date. Bug fixes can continue to land though and important iterations (case by case) can be considered.

[mtias]

Let's close this and follow up with more focused imporvements.