Add a way to transform between block variations

[draganescu]

The navigation block has two variations: horizontal and vertical. These have to be variations because styles are CSS only and we need to alter one of the block's attributes to change how the movers behave depending on orientation.

However this is not very intuitive and it's not easy to understand the difference and the "why", and for many instances its has been suggested to "merge the two variations" (e.g. #23226). As there is no way to "merge" the variations, the proxy would be something which behaves like styles and appears to users as a "setting" of the block.

Therefore it could be so that when a block has multiple variations registered it displays the list of variations in one of the two places occupied currently by styles:

The new API should be able to partially apply new block attributes, preserving content.

In the case of the navigation example, starting from:

<!-- wp:navigation {"orientation":"vertical"} -->
<!-- wp:navigation-link {"label":"Ut atque aut nobis","type":"custom","id":1976} -->
<!-- wp:navigation-link {"label":"Sample Page","type":"custom","id":1979} /-->
<!-- /wp:navigation -->

... after applying the operation the result is:

<!-- wp:navigation {"orientation":"horizontal"} -->
<!-- wp:navigation-link {"label":"Ut atque aut nobis","type":"custom","id":1976} -->
<!-- wp:navigation-link {"label":"Sample Page","type":"custom","id":1979} /-->
<!-- /wp:navigation -->

This new feature is also useful for block based themes as it allows themes to apply their own attribute customizations to existing data saved in template parts.

[shaunandrews]

I've explored this briefly, as its something that comes up again and again. The first option that came to mind was to list variations just like styles in the block menu:

This can get rather large, and there's potential for confusion between styles and variations. My second idea was to move styles and variations into a submenu to better differentiate and organize:

I like this, but we obviously don't have this capability yet with the current menu system. Which led me towards exploring how we could use the existing Transform menu:

This is fine, and would get the job done, but it lacks the visual emphasis and doesn't really explain the differences between variations.

Moving away from the toolbar, perhaps switching variations isn't a "primary" function and could make more sense in the sidebar:

This would work ok, but I wonder if it could be confused with (or should actually be) the default setting for the block across the site.

In any event, I think more exploration needs to go into the above options — with the sub-menu concept being my favorite as the pattern could be useful in many other places in the editor.

[ntsekouras]

Moving away from the toolbar, perhaps switching variations isn't a "primary" function and could make more sense in the sidebar:

I think so too. In general we have to consider that a block could have many variations and the perfect example is the embed block with over 20 variations :)

Another thing to consider is that while many variations change attributes only and could be easily understood from their name, others rely on visuals/icons like the Columns variations (#20584).

[mapk]

Aren't all the Embeds just variations of the Embed block? If we call these variations as well, does that mean each of these would appear in the Transform Tool?

For this reason, I've chosen to call the sort of changes in this particular issue "Patterns" since they aren't changing the settings of how the block works, but rather just changing the blocks being used. I've been thinking this through in #25750 (comment).

A block variation, to me, affects the settings of the block. A pattern affects the layout of blocks being used within it, not necessarily the settings. Ugh. If we can find a clear differentiator here, I think that can really help provide a clear separation of functionality.

[ntsekouras]

A block variation, to me, affects the settings of the block.

That's true, but there might be display settings as well, that will lead in layout changes (check Columns variations). You shouldn't map them mentally to change only attributes that affect the functionality of a block.

A pattern with our current API is more like a template maybe. It's a list of blocks to be inserted. It can contain many different blocks and is not limited to a single block. A pattern could just insert a heading and a paragraph and their purpose is to add content, in the form of a number of blocks, at once.

Block variations have the option to be shown in the inserter or not. For example embed shows them and columns are not. What is missing here with block variations is the ability to transform a block to a variation of itself, after creation, because now we show only transformation to a different block.

Hope that helps clarify a bit more the difference @mapk.

[mapk]

Thanks, @ntsekouras! I think between the terminology and having some variations show in the Inserter while others show in the Transform Tool of the block is what's confusing. Can this be defined further? Like maybe if the block variation is a different block, that should be surfaced in the Inserter (ie. Embeds). But if the block variation is a different version/layout of itself then it is shown in the Transform Tool of the block.

But this puts the Query block in an interesting position. A block variation might be the Latest Posts block which would show in the Inserter as a different block. But another block variation of the Query block might be shown in the Transform Tool because it's really just changing the layout like grid or list views. Do we call these both variations?

[draganescu]

What we're trying to achieve here is to have the mechanism to apply attributes updates to the same content, thus effectively enabling transforming between variations. We should keep this in focus.

I think this discussion is making this issue split into a high level dilemma about when is a block made of blocks a pattern and when is a pattern a block.

If the layout of the query block is decided by setting one of its attributes (say named layout) to some value (say one of top_images, no_images, list, columns) then this is also a transform between variations just like a transform between vertical and horizontal navigation is.

I don't necessarily agree that having the variations showing up in the inverter and in the transform tool is confusing since we're already doing this with block transforms. I do agree that some blocks would have so many variations that the UX would be impossible. What we could do is disable transform variations for some blocks?

[mapk]

I don't necessarily agree that having the variations showing up in the inverter and in the transform tool is confusing since we're already doing this with block transforms.

I would agree. The problem, for me, is around why some variations would show in the Inserter and others in the Transform tool in block's toolbar. Having a clear definition around that would be super helpful.

[ntsekouras]

The problem, for me, is around why some variations would show in the Inserter and others in the Transform tool in block's toolbar. Having a clear definition around that would be super helpful.

That is a matter of the block's specific needs and flows. There is no hard rule here and that's why this behavior is controlled with a property (scope), when registering a block variation.

For example embed block chooses to expose most(if all?) variations in the inserter and that makes sense, because a title like youtube is concise, self-explanatory and maybe rather common(?). Columns use a 'pattern' of a placeholder and its variations live inside that placeholder. For this reason the names are like 30/70 and if they were exposed, they should be something like Navigation which has the full name and the differentiator (ex Navigation (horizontal), Columns (30/70)).

The problem that needs solving here is having a way to 'update' a block to another block variation, after its creation. This has nothing to do with where the variations were available in the first place (inserter/placeholder pattern etc..).

Although with variations is not a transformation to another block but rather an update of attributes, I can see the mental connection that can be made. Having said that I am more keen on the third option (from @shaunandrews), or something similar.

Moving away from the toolbar, perhaps switching variations isn't a "primary" function and could make more sense in the sidebar:

[mtias]

Good explanation @ntsekouras :)

[gziolo]

I wanted just second what @ntsekouras said that we can expand the types of supported scope values. To give an example, if we would have another type called transforms, it would be way much easier to adjust them to fit in the UI where they are presented and how they behave.

In addition to that, we need to ensure users never lost their content, so we can't override inner blocks the way we do it for Columns (and soon Query) block when picking a pattern means injecting a predefined template. Instead, we would have to define a set of attribute updates applied to the block and its children.

[mapk]

Looks like we need a decision on a path forward here? I'd really like to use this interaction on the Query block too.

The initial design from @shaunandrews is the one I like best, but it doesn't scale well. It's the same solution I arrived at for the Query block. However I foresee many different layouts (ie. 10+) and if that's the case, should we go with Shaun's second option above?

[ntsekouras]

Looks like we need a decision on a path forward here?

I second that!

Moving away from the toolbar, perhaps switching variations isn't a "primary" function and could make more sense in the sidebar

I favor the third option for the reason @shaunandrews states. Although I don't think the Block Card would be the perfect place to live. I think it could live in a Panel of its own, having a title/description and probably a fixed width(with scrolling) for cases with many variation transformations.

Lastly a thing to have in mind for the design process is that, as we have discussed the implementation with @gziolo, transforming between block variations will be an opt-in behavior for variations, as it doesn't make sense to show all block variations in every block and additionally there will be cases that the transformation will need a custom transform function(especially with InnerBlocks).

[paaljoachim]

The importance of Variations and having these visible. Here are some mockups.

1. Select initial structural layout (variation).
2. See the variations as a panel in the sidebar settings.
   One can see the variation directly in the Block "Select a variation to start with" screen, and one can at the same time also see it in the sidebar. It means they can skip a variation in the initial screen and instead later on make a selection in the Variations panel.

The selected variation is seen in the layout and there is also a border around the selected variation in the sidebar panel. Making it obvious which variation is selected. Making it easy for the user to click through the variations and see the change in the layout.

Here is a short prototype:
https://www.figma.com/proto/E1hfTDvAQR6G0bPaP7s4cm/Query-Block-explorations?node-id=1%3A2&scaling=min-zoom

The above shows the obvious connection between the structure of the layout and the sidebar variations panel. Clicking styles will open up the possibility to add some presets one can also create by using the options that exist for the current block. But because of the purpose of this block a style would also likely almost cross into the variation territory.

Variations and styles are so close to each other in their purpose that for some blocks these two will crisscross and a user will just click through the available options to look at what is possible to do with presets not caring what they are called. It is important to have options that affects the layout (variations, styles and other options) in an obvious easy to locate place like the sidebar.

[ntsekouras]

Hey @paaljoachim - thanks for exploring this!

It is important to have options that affects the layout (variations, styles and other options) in an obvious easy to locate place like the sidebar.

I agree with that.

It means they can skip a variation in the initial screen and instead later on make a selection in the Variations panel.

I don't believe this issue has to be coupled with another component like __experimentalBlockVariationPicker that is used in Query, Columns etc.. For example the skip option doesn't make sense to be in every block that uses a Placeholder.

I believe this issue has just to provide a way to transform a block with one of its block variations, only if a block variation has opted in for this behavior and can also support the wanted transformation.

The selected variation is seen in the layout and there is also a border around the selected variation in the sidebar panel. Making it obvious which variation is selected. Making it easy for the user to click through the variations and see the change in the layout.

This will not be possible as there is no way and doesn't make sense to implement to know the variation that a block had been created from (I thought so as well before and I had made a prototype recently #26105, but closed it).

A simple example would be the Query block. We can start with title+date and then add image. So the initial variation used is invalid.

[kellychoffman]

https://user-images.githubusercontent.com/191598/92940791-8a50c700-f41d-11ea-8f24-4b56c8e72735.png

This direction feels most promising. I think it needs to be more explicit as to what it is.

[paaljoachim]

We are now looking at two options.
A drop down or a panel (See my comment above #25231 (comment) regarding settings panels).

Query block - drop down with text only.

Query block - drop down with thumbnails and text.

---

Backing up for a moment.

The initial experience users will have with the Columns block looks like this:

Columns - drop down with text only.

Columns - drop down with thumbnails and text

It is important to keep thumbnails as a visual representation of what a variation will look like. To keep consistency with the initial startup screen. The thumbnails also becomes the first visual representation of what the block structure will look like.
Certain blocks will need the visual representation while other blocks could use only text.

[ntsekouras]

Columns - drop down with text only.

We could show the description of these variations and not just the titles.

I understand that some variations would be better understood with icons and we could make 2 designs conditionally by using a prop or something, but would this be consistent?

Also since this list will contain variations that have opted-in for this behavior, we could also apply some 'rules' that will make it easily understood. For example description field is optional now, but we could encourage to use that field for these kind of variations (it would still be a fallback of course).