Suggest Patterns in block placeholder states

[jameskoster]

When inserting something like an Image block, it may be useful to present the user with patterns that consume image blocks and inspire them to create something more elaborate.

One challenge here is a placeholder Russian doll situation... if I select a pattern from the Image placeholder which contains multiple image blocks – do those subsequent image block placeholders also suggest patterns? (Probably not, but requires exploration).

Not to be confused with (although could perhaps be inspired by) variations, or styles.

[ntsekouras]

One challenge here is a placeholder Russian doll situation... if I select a pattern from the Image placeholder which contains multiple image blocks – do those subsequent image block placeholders also suggest patterns? (Probably not, but requires exploration).

I think block patterns have blocks with some demo content always, so we will be probably fine in most cases. The suggestions should be made in an insert new block context and we have the control when to show a Placeholder or not.

[jameskoster]

Here is an initial take on this. The finer visual details may need some refinement, but the general flows feel pretty good to me, and will translate well in to the other use cases for patterns.

Let's start with the Query block as it is a complex example and stress test. Upon insertion I see a "default" pattern right on the canvas, subtly faded out to indicate it is not yet fully inserted. The Toolbar provides a temporary affordance to navigate through the available patterns, or one can simply skip ahead.

The pattern name serves as a trigger to open a popover that displays multiple patterns at once. This will be useful in situations where there are many patterns, and in the future could include a search input to pull in patterns from the pattern directory. A pattern can be selected by clicking the checkmark icon in the Toolbar, or just by clicking directly into the pattern itself on the canvas.

Here's how inserting the Query block, and selecting a pattern might look:

https://user-images.githubusercontent.com/846565/107763294-4f352580-6d26-11eb-8845-2e92a11d312d.mp4

The key thing about this approach is that it gives the user immediate feedback with regards to how the pattern will look in the context of its surroundings. It also paves the way for us to do interesting things like suggesting header or footer layouts when template parts are selected in the site editor.

Skipping out of the pattern selection flow would send you to the existing placeholder state:

https://user-images.githubusercontent.com/846565/107763548-b5ba4380-6d26-11eb-8ec3-6de5647fef3f.mp4

---

Let's take a look at a simpler block. Here's how the above flow could work for inserting an Image:

https://user-images.githubusercontent.com/846565/107764772-ac31db00-6d28-11eb-9bdb-6727ed9e6114.mp4

Notice that despite originally selecting the Image block, the Cover block is the one that is eventually inserted. This illustrates the power of presenting these patterns in a highly visual and contextual manner. It focusses the user more on how the thing they are inserting looks, rather than what it is called, or how it might be configured after-the-fact.

---

As another example lets look at the Columns block, as this is possibly one of the best examples of the interplay between patterns and the current placeholder state. Here I am able to browse through opinionated column patterns for inspiration, but if I do not see anything I like, I can still quickly and easily insert pre-configured empty column layouts:

https://user-images.githubusercontent.com/846565/107765228-5873c180-6d29-11eb-8b23-72b96aec5093.mp4

[pablohoneyhoney]

Nice iterations on this! Lovely to see them in action and context. It's a complex problem to solve!

The way we leverage the toolbar above is a bit labyrinthine, and it doesn't provide the validation of the block inserted as we avoid the block icon, for example. I think we could explore other options and stress how much we can push the paradigm of inserting itself for pattern-first flows.

At a granular level, we are using above the toolbar in too many affordances, carrying a weight of interactions that could be potentially distributed in the whole block area instead.

One path could be for example we could zoom out the pattern content and paginate within the block canvas regardless of their footprint variations. Perhaps a simple toggle in the toolbar can switch between patterns and blank, or blank could be an option within the browsing of patterns.

Worth avoiding variations as an additional term to the already complex jargon.

[jasmussen]

I think there's a place for the carousel, and I like how showing the pattern directly can solve the "placeholder squint and it looks the same" challenge. My first instinct was also that the block toolbar could be an appropriate place for this, but to Pablo's point, it might be good to explore them in context of the pattern itself, especially if in context of zooming we can find the space for it.

That's the other aspect I'm still struggling with: if the pattern looks identical to the end result, how do you know that you've inserted it? By leveraging zooming and showing the pagination controls in context, perhaps doing so can help make clear: you haven't made a choice yet, and here's where you click to do so.

[jameskoster]

@pablohoneyhoney if I am interpreting you correctly, you're describing something similar to an earlier mockup I had:

https://user-images.githubusercontent.com/846565/107797674-18c1cf80-6d53-11eb-98b8-462aceb71282.mp4

I think the zooming can work, but I worry about how it will scale down to smaller areas. I also have some reservations about displaying the pagination on the canvas... could that mislead the user in to believing they've inserted an actual carousel?

[pablohoneyhoney]

There's something here!

I also think the system carousel can have various ways to be more explicit, for instance, connecting it more specifically to the CTA. Perhaps there's a clearer distinction between the pattern itself and the wrapping carousel.

Patters vs. Blank aren't necessarily well connected through a Skip. Hence my comment about leveraging a switcher in the toolbar, or including blank as an option within the carousel.

[jameskoster]

https://user-images.githubusercontent.com/846565/107805143-d56c5e80-6d5c-11eb-82f3-6abb79bba097.mp4

Here I've connected the pagination to the CTA and moved it all to the top of the block so that the arrows remain under the cursor even when the block height changes, for easy pagination. It works quite well, but I am getting subtle double-toolbar anxiety.

Hence my comment about leveraging a switcher in the toolbar, or including blank as an option within the carousel.

I think starting blank should be more accessible. I shouldn't have to navigate the toolbar, or scroll through pages of a carousel to just insert an empty 2 column layout. (Please ignore the instance of "Variation" in the blank placeholder for now. I agree we should remove it, but that can be done separately).

[kellychoffman]

This is feeling better. (I was typing up a whole thing but then you updated the design and I don't have much to say now haha) Only that the centering of the buttons feels a bit awkward.

subtle double-toolbar anxiety

I think when you are actually using it, the double toolbar won't be a big issue. We could also consider altering the appearance of it so there's a bit more visual and hierarchical difference between it and the toolbar above it.

[DaisyOlsen]

I really love this. I have questions about how patterns will be associated with blocks to be transformed, but I like the flow that you've shown here a lot! :-)

[jameskoster]

Only that the centering of the buttons feels a bit awkward.

Agreed. And I think we may still need a way to display the pattern name, and a way to view multiple patterns at once.

so there's a bit more visual and hierarchical difference between it and the toolbar above it.

I tried a dark background, but that felt too heavy handed. Perhaps adjusting the layout of the contents will help here.

I have questions about how patterns will be associated with blocks to be transformed.

Me too 😅 To begin with, maybe block-to-pattern transformations are hard-coded, kind of like block to block transformations are currently?

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.

It gets more complex with multi-block transforms. Matias shared some thoughts around that here, and I'll be exploring designs in #28736

[kellychoffman]

Grouping the back/next feels pretty good:

[jameskoster]

Small update here:

• Pagination on the left
• Actions on the right
• Added pattern label + name
• Name serves as popover trigger to view all patterns

https://user-images.githubusercontent.com/846565/107976943-3f317600-6fb2-11eb-8538-5111c9e87203.mp4

I'd love to hear thoughts on whether the popover being the same width as the container is useful. I am on the fence.

---

Here's another use case to test this pattern against: I have set up some columns from scratch with custom content, what should happen when I engage pattern selection view... should the current content appear as a "Custom" pattern? Or just be omitted altogether? Here's how it could work if we omitted the current contents from the pattern selection view:

https://user-images.githubusercontent.com/846565/107976776-02657f00-6fb2-11eb-9399-2eff79667aec.mp4

The cancel button allows a quick pathway back to the current state if the user decides against selecting a pattern. I imagine we'll look more closely at this in #28736, but please share any thoughts that bubble up.

[jasmussen]

I appreciate that the theme color "bleeds through" in the frame, it will benefit patterns shown in themes with light text and dark backgrounds. The animation of "scaling into place" helps imply what's about to happen.

I'd love to hear thoughts on whether the popover being the same width as the container is useful. I am on the fence.

How would it look if the black border that separates the white bar and the "popover" of patterns wasn't there?

---

This is nice work Jay, I think you're on to something. Enough that it might be worth thinking now about how this scales to narrower contexts. Imagine if the main column you inserted this placeholder in was at most 360px wide — how would that look? Keeping in mind we have a kind of element query functionality already in place for placeholders, so we can output CSS that's unique to 3 sizes, small, medium and large.

[jameskoster]

How would it look if the black border that separates the white bar and the "popover" of patterns wasn't there?

It definitely looks better. But now the patterns grid feels like a part of the "toolbar", so the other actions are a bit awkward. The pagination for example looks like it should paginate through the popover.

We could hide these tools when the popover is open. But I am starting to think it might be easier to just use a normal popover and potentially explore this in more detail later.

Imagine if the main column you inserted this placeholder in was at most 360px wide

Unsurprisingly it is a little cramped, but with some layout and padding tweaks I think it can work:

[kellychoffman]

Nice iteration.

The dropdown / grid view interaction feels confusing in this context. It might be worth a toggle of sorts to better communicate the action: view patterns as a carousel you flip through or see them all in a grid layout.

This is likely a personal preference but: patterns feel so visual that the name doesn't feel worth showing at all, especially in this view or at this level of prominence.

[jameskoster]

Grid / list toggle buttons could work:

https://user-images.githubusercontent.com/846565/108229288-93b22e00-7137-11eb-88fb-ad7cfcf93b17.mp4

Scales down nicely to mobile as well:

The trade-off is the increased double-toolbar-syndrome...

[ntsekouras]

Some blocks (like Query) have some attributes setup besides the usage of block patterns.

A first iteration was recently merged: https://github.com/WordPress/gutenberg/pull/28891, having the above issue in mind for the future. So how can we show this information, as there might be the need for other blocks to set some attributes too..

Maybe in a two-step guide ? 🤔

[jameskoster]

We're talking about the "Inherit query..." option here:

I feel as though this is a fairly confusing concept to burden the user with at this stage. Especially as the patterns (and their previews) do not change in any way when you interact with it.

Worth noting that these options also exist in the Inspector:

So might we omit this from pattern selection, and just inherit the query from the URL as a "smart default"?

[mtias]

So might we omit this from pattern selection, and just inherit the query from the URL as a "smart default"?

If you add a Query block to a page, what would it inherit?

[jameskoster]

I revise my original question 😂

So might we omit this from pattern selection, and just ~inherit the query from the URL as~ set a "smart default"?

If you add a Query to content (post or page), it could display Posts by default. Seems like this would be the expected result in the majority of cases anyway? Likewise if you add a Query block to a template, it should probably inherit from the url.

In either case you can refine the details of the query once you've decided on a display format you're happy with, rather than trying to grok the two things at once.

[ntsekouras]

If you add a Query block to a page, what would it inherit?

It won't inherit something and will not work as expected with a list of posts. It would just show the current page and that is because it has to cover the case when using a page as home page and is used in index template.

In a page, the setting should be inherit:false and probably should be handled with a smart context detection, which is not currently.

The question here is more of whether we will need some kind of attributes setup in another block in the future (let's say we remove this from Query now).

[jameskoster]

The question here is more of whether we will need some kind of attributes setup in another block in the future (let's say we remove this from Query now).

I feel as though this is a separate thing to choosing a pattern, and should be handled intelligently on the users behalf wherever possible. Quite possibly by the pattern itself? Or the context as above.

Did you have any examples in mind besides the Query block?

[ntsekouras]

Did you have any examples in mind besides the Query block?

No I don't and couldn't think of something, but asked if someone could :)

If that's the case this design:https://github.com/WordPress/gutenberg/issues/28735#issuecomment-780651352 could probably use a PR to test some iterations.

[Addison-Stavlo]

Did you have any examples in mind besides the Query block?

Template Part block is another example. The user would need to select between 'header', 'footer', etc. before we would know whether to suggest either header or footer patterns, etc. This isnt specifically a block attribute though.

[ntsekouras]

The user would need to select between 'header', 'footer', etc. before we would know whether to suggest either header or footer patterns, etc

This might be handled with block variations.