Better organization for block transforms

[mtias]

Block transforms are one of the most important and powerful features of the block editor. They allow switching content types effortlessly and open many paths for users and block developers. They are so useful that it's natural people use them for basic operations (paragraph > heading), layout transforms (paragraph > group, paragraph > row), block replacements (site logo > site title), variations transforms, and everything in between.

Given this reality, the transforms menu has grown a lot, often obscuring basic transforms in favor of niche ones. I think we can improve this situation by making a couple tweaks:

• Define a list of basic transform operations for text: paragraph, heading, list, and quote should always be prioritized and grouped together.
• Define a list of layout related transforms: group, row, columns, stack, cover, etc, and group them together, separated from other content-driven transforms in the list of transforms.

The separation can be just a line separator for content-formatting ones and maybe another flyout menu for layouts. It'd also be fine to do a first pass that just adds a line divider and gathers them together in priority sets.

[jameskoster]

I imagine it would be implemented separately, but it might be good to keep in mind that pattern transforms could be accessible from this menu as well.

[jameskoster]

Here's an example of how the transform menu would look with some grouping:

Obviously it depends on the block, and whether styles are present, but this is already a little unwieldy.

We can simplify things quite a bit by utilising flyouts or similar mechanism:

The 'View patterns' link could open the pattern explorer with the appropriate filter, or engage exploded mode (#39281 (comment)).

[ntsekouras]

We can simplify things quite a bit by utilising flyouts or similar mechanism:

We need to take into account the case of multiple selected blocks. In many of these cases the only available options would be Group and Columns, so it might not make much sense to have a flyout.

This issue also highlights that we need some kind of handling for some block variations(stack, row, etc..).

We also need to find a good way of identifying the group, a block transform should belong to. What is layout transform for example? Could a way to separate them be to check the isMultiBlock: true from a transform? Would we need an explicit new API in transforms? This point is also related to the exposure of block variations in the transforms menu.

[mtias]

I'd like to start with splitting and prioritizing the basic transforms for text blocks. Can we explore some alternates there to see what might work? I can see a minimal implementation that just groups them at the top with a divider, for example.

[jameskoster]

Perhaps mis-interpreting, this list seems very long to me. Unsure of the value vs noise of the sub-divider.

Another option is to use flyouts for methods we don't want to prioritise:

Edit: I suppose this is another option, somewhere between the two above :)

[mtias]

I mean prioritizing paragraph, heading, quote, list, etc for text based blocks. Only the first task, don't do anything to layout transforms.

[jameskoster]

Okay, ignoring styles and layouts for now, here are some options that make use of existing patterns:

[pablohoneyhoney]

Fantastic iterations and variations @jameskoster

Maybe this was done already, but do we need to list out the taxonomies and associations or the more prominent block types to we understand how many max might be listed and it could drive the decision on how best to represent it in the UI? An example, the Inserter style option, are there cases where they are four breaking this solution?

I like the simplicity of the flyout solution, which was considered a while back when we refreshed the toolbar and perhaps the most scalable without getting too long.

As a small note, worth using a separator without gaps, right?

[jameskoster]

To my knowledge no full list has been compiled, although I suppose it must exist somewhere in the code. I think there's a discussion to be had around what determines the number of prioritised transformations – the design, or the code. For example it could be a design decision that only 3 transforms will be prioritised regardless of block type or total number of transforms. This might be preferable because otherwise prioritised transforms would need to be explicitly flagged in the code, which requires additional work and could potentially be abused to the detriment of the UX.

As a small note, worth using a separator without gaps, right?

It's preferable, but the organisation can feel strange when we consider other sections within this menu. Example:

Due to the presence of the Style section it's not clear whether the Pullquote button is part of of the Transform section, or something else entirely.

This is one of the reasons why I prefer the flyout option, it's more holistically scalable:

[mtias]

Let's try the separated list as a first pass.

[pablohoneyhoney]

@jameskoster I guess that's a situation not to worry about yet based on the above conversation and priority, but if needed in the future (with more layout, style transforms), we could add an additional label too: "other transforms" if visible with separator, or "more" in the case of the flyout.

[annezazu]

Noting that this came up as a request, particular for template parts, in the usability testing for the FSE Outreach Program. Rather than selecting "replace", a participant expected to see patterns as options from clicking on the Header icon itself:

[jameskoster]

@annezazu I think @Mamaduka is going to look into this as a part of #42221.

[annezazu]

As part of the sixteenth call for testing for the FSE Outreach Program, the following feedback was shared that seems to capture a shared sentiment of those who participated:

Text transforms in generally worked fine, but feels a bit like a labyrinth. As there are different transforms based on what the current block is. It feels a bit random.

Similar to the efforts to have consistent dimension controls, this feels like another high impact area to make more predictable in time.

[mtias]

@jameskoster can we add a mockup that just does the splitting, please? Without styles or anything extra.

[ntsekouras]

I can work on this one. @jameskoster I'll see to create a simple PR to get things started.

[jameskoster]

Here we go:

[mtias]

Thanks! We can expand from there for layout, media, etc, in the future. One thing to consider, for example, is that layout tools are a lot more useful for multi-block selection, and we already expose them more prominently in the toolbar in those cases. We should probably include Cover in those transforms.

[richtabor]

Organizing further with flyouts is blocked until we have a nested dropdown component, as discussed here. cc. @ciampo

[scruffian]

I think block transforms are pretty tricky to find for such a powerful feature. I'd like to see them exposed elsewhere - maybe in Block Options or Block Settings?

[jarekmorawski]

The new dropdown component with submenus is almost here. Does this mean we can revisit this issue? I'm asking because I ran into a similar use case while working on a new Woo block. It'd benefit from displaying transformation options, patterns, and variations (we call them "types").

I took the liberty of adjusting the block menu to the design of the updated dropdown. Here's how it could look for the Paragraph block:

And how we'd adopt it for the new Woo block. Note the Change type section, which would be owned and managed by WooCommerce blocks. This suggests that the transformation menu should have extensibility points.

I wonder if we can also take this opportunity to rethink the affordances. I assume many new users may not realize that the block icon is interactive and houses settings and features they might've looked for elsewhere. Could making the block icon its own button (and using the separators as button signifiers) or merging the transform menu with the kebab dropdown help make the features inside more discoverable?

I think block transforms are pretty tricky to find for such a powerful feature. I'd like to see them exposed elsewhere - maybe in Block Options or Block Settings?

I think contextual options could work well in conjunction with a dedicated Layout tab in the Inspector. As Matias pointed out, the toolbar is useful for customizing multiple blocks at once, which applies to transformation and layout updates.