Expose initial templates as variations

[mtias]

When inserting a Query block we should explore offering a few starting variations:

• Title and Date
• Title and Excerpt
• Title, Date, and Excerpt
• Title and Content
• Title, Featured Image, something else?

We might also want to expose some part of the query config as a second step.

[mapk]

This sounds very much like a Placeholder screen for blocks, especially when considering the Columns block. I went with that idea to iterate on some designs for this.

Option 1 - SVGs

Using SVGs, we can graphically convey the layout using lines similar to a wireframe.

Option 2 - Single layout pattern

I tried out the preview dimensions from some of the other blocks (ie. 120px X 84px). The space provides just enough room to show a preview of some mock-content or actual post content displayed as a single representational pattern.

Option 3 - Multi item pattern

I expanded the area to show multiple feed items bringing more context to the preview.

Feedback

Before jumping into the next step, I wanted to get some design feedback on these to see if this is the desired direction.

• Which option feels stronger and scalable?
• Because we can have several layout options, I've opted to show those in a horizontal scroll ability with the block's placeholder screen. How does that feel?
• Are there other layout options we should provide in Core? Maybe more grid layouts?
• What are the settings you imagine being included in a "Step 2" placeholder?
• If we include two steps in the Placeholder, should we include some sort of pagination for the steps and indicator that tells the user where they are at in the setup process?

[mariohamann]

Really like those explorations!

• The third one feels a bit "too much".
• The styles of the first one have to be explicitly "designed" – and I'm fearing visual clutter. :P

Therefore, I think it's good to consider the second one as it seems to be automatically created from theme styles etc. and feels better extendable e. g. for third-party devs.

[ntsekouras]

Hey @mapk - thanks for exploring this.

My first thoughts for now are that it should be consistent with the other core blocks like Columns. So first option feels right to me.

I'd like to have some thoughts about whether in a placeholder like this, we should include the option to have a fully controlled by the user Query block or it should inherit the global context, if available. That means two extra options on insertion. (@mtias )

I haven't made code explorations yet, but it feels like we will need that, so as not to exclude the option for a user to have for example in an archive template a Query blog that inherits context and another one that could show something else.

[mtias]

@ntsekouras I think we should have a separate issue to explore things there. From the top of my mind I can think of:

• First query block that is added defaults to inherit. After that it's a standalone query.
• Describe more clearly what controlled vs not controlled is. "Hey, since you added this query to a template, WordPress uses the context of the ..."
• We need to model the initial query config state in the placeholder (as a secondary step) and it could be part of that.

@mapk in text we should probably refer to these as "post layouts" or "template", variations is more of its technical term.

[mtias]

@mapk one thing to get out of the way first is to determine if it's better to do these as placeholder variations or patterns, or some sort of mix of both. The placeholder state could also show patterns instead of variations by default (something being discussed a lot for template parts). Alternatively, "patterns" could be a prominent extra button in the placeholder state to toggle between variations and proper patterns.

To be clear, I lean a bit more on placeholder variations for the block itself (what you mocked up above) and patterns as a slightly separate flow (on the inserter) for post layouts, but it's worth considering as part of the exploring.

[mapk]

All really good feedback! Thanks!

Decision needed
We need a decision around which layout style to use in the placeholder. Should we go with SVGs or with actual preview content as outlined in my comment above?

Separation of actions (but all are block variations)
In either case, both would work in the context of how I'm envisioning this particular separation of actions. In one case, the user wants to select a block for a purpose. This is represented as different Query block variations (ie. Latest Posts, Featured Posts, Most Commented, etc). Afterwards, the user then wants to select a layout of that block's inner blocks which are still considered other Query block variations but presented differently b/c the user is no longer thinking about the query, but rather about the layout of feed items.

• Query variations are listed as blocks in the Inserter.
• Layout variations are listed in the block placeholder.

This allows the user to select any of the layout variations to apply to a specific query variation. I'm struggling with terminology here, so please forgive me.

Applying different layouts
Yep, the same layout variations found in the placeholder would be available in the Transform Tool as well in the block's toolbar. I just don't know what to call these; "layouts", "variations", "patterns"?

[ntsekouras]

Hey @mapk!

Should we go with SVGs or with actual preview content as outlined in my comment above?

I think for our first iteration going with SVGs and following the Columns placeholder design would be just fine. Actual preview would not be possible as we don't know which entity would make it there (depends on the query to be set later). If you're talking about demo content preview like hello world, that's another issue.

One thing I have to point out is that for now we will not have Query block variations that include styling or grid like stuff (your example with image on the left and content on the right).
This will be handled either with patterns including Columns blocks or whatever is needed, or later when the handling of grid will be implemented.

This issue can focus just on insertion of these:

Title and Date
Title and Excerpt
Title, Date, and Excerpt
Title and Content
Title, Featured Image, something else?

Although Latest Posts and Title and Excerpt represent different block variations (that's just technical), I'm planning on making a simple expansion in block variations API that will have a differentiator property (like a category or type..) that will help us expose different block variations in different places. That is for another issue but in combination with this: #25231, it's going to work just fine.

So to sum up Latest Posts kind of variations (when implemented) will be exposed in the inserter and will not have the placeholder, but with the above issue resolved, the user will be able to change the layout with a Title, Date, and Excerpt variation, after creation.

We might also want to expose some part of the query config as a second step.

As Matías commented here, this can be a second step and after the first iteration, I'll create another issue for this.

[gziolo]

I see that #26378 is in really good shape and it mirrors mostly how the Columns block work as of today. I think it's a good direction that allows us to iterate on the Query block.

Applying different layouts
Yep, the same layout variations found in the placeholder would be available in the Transform Tool as well in the block's toolbar. I just don't know what to call these; "layouts", "variations", "patterns"?

I would prefer we leave it for later. It's tracked in #25231 and we can discuss all the details there. I also opened #20584 a while ago which covers mostly the same concept that I'm going to close now.