Update block variation transforms UI #57676
Conversation
ntsekouras
added
[Type] Enhancement
|
Size Change: -5 B (0%) Total Size: 1.69 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 6ad72ac. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7461777081
|
The spec prohibits decorative icons on radio/checkbox menu items, so if the icons are a requirement we'll need to use a different component, perhaps CustomSelectControl? A select might work better for long lists too, due to the keyboard behavior – you can effectively type to search. I'd be tempted to handle the toolbar transform menu separately as we need to account for styles and patterns there. We may need a Submenu with Combobox pattern there, which I don't believe has been implemented yet. |
Echoing @jameskoster 's reply, the specs for the
That hasn't been implemented yet, as it's quite a niche combination of semantics (menu + combobox) and has a few tricky aspects to it. |
To clarify, I'm not advocating about using icons. This is only if designers deem necessary to have them.. |
|
The value of icons as a recognition tool goes down a bit (imo) when the list is very long. In such a scenario searching becomes a more ergonomic way to find what you're looking for. Since this pattern comes into play specifically when the list is longer, I'd lean towards excluding them. Especially (as mentioned in the OP) icons can be duplicated, ambiguous, or sometimes not provided at all. If we stick with the new menu component, it would be really nice to make it a Menu with Combobox (example) to enable searching. But I don't think this is implemented either :) Hopefully @ciampo can give an indication about when that might be explored? If it's a way out, then it would be fine to implement as a follow-up. |
Unfortunately, as of today, we won't really have much capacity to explore that, so I'd consider alternative solutions for the time being |
|
I don't think this works here; I'd rather only have the transforms within the block toolbar.
|
|
We plan to use a similar UI for changing the collection type in the new Product Collection block in Woo. Technically, they'll be block variations and available in the toolbar. 
Still, we'd also like to have a dropdown because the collection type impacts all settings in the sidebar and users may want to switch between a few different types before settling on the final one. That being said, I'm not sure if our use case matches the scope of this issue. We're dealing with block variations but in a different way.
Can we make it optional, please? In the PC block, the icons displayed in the dropdown are the same as those shown in the block's placeholder, which helps establish a connection between the block's different states. 
I agree with Jay that it'd be nice to search through the list. Not sure if there has to be an explicit search input. Perhaps the user could just press the keys to filter the list?
Personally, I don't think the transformation menu is discoverable enough in the toolbar. If the user doesn't learn that the block icon is clickable, they may never know it's there. On the other hand, the dropdown in the sidebar is awkward, too. It's placed below the block's name (e.g. Group), which suggests a certain hierarchy. However, when changed, it impacts the whole block, including what was presumably at the top level in the sidebar's visual structure. I wonder if there's another solution, or whether we should focus on increasing the visibility of the transformation menu instead. Could the block name be clickable? Or its icon in the sidebar? Should we add a chevron or another affordance to the transformation menu button in the toolbar to make it more visible? |
|
We added a few new collection types and layout options to the Product Collection block, which increased the length of the transformation menu. It can be overwhelming, not to mention impossible to read and use on lower-resolution screens. 
I ended up adding a submenu to shorten the list and make room for layout options. Do you think it'd make sense to truncate the list of transformations if there are more than five? We'd use the new nested menu component to display others without navigating away from the canvas. |
|
Here's an example of what a truncated (and updated) block transformation menu could look like in the toolbar and the Inspector. It uses the new nested menu component and has an input field that lets users search through the list (nested or not). 
|
|
The 'More' flyout came up in #40208, and still seems like a reasonable way to handle longer menus imo. I've often wondered whether the block name could serve as a transform control, similar to the component switching UI in Figma. 
All that said, in the interest of keeping the PR small and shippable, maybe the first step is to install the I'd be interested to hear more from @richtabor about transforms not working in the Inspector. |
|
Together with @andrewhayward earlier today we took a look at this conversation and had a few thoughts. In terms of semantics:
With that in mind, changing icon is about changing an aspect of the block, and for that reason it felt appropriate for it to be a select dropdown in the sidebar (as Rich pointed out here). On the other hand, a menu feels more appropriate when transforming a block to another block, since each menu item actually performs an action (swap a block). For that reason, it felt appropriate for the menu to be in the block toolbar, and not in the sidebar. Just some high level ideas, although I thought I'd share them here. |
I meant that the suggested UI would not work. We do already have a mechanism in place for when a block has more than four variations visible in the inspector, like this below (I added an additional variation to invoke the selector):
|
|
Closing this exploration since it doesn't seem to add much value for now and probably we need to focus on #40208 to handle transformations better in all places. |
What?
Fixes: #57253
Fixes: #46726
This PR updates the block variation transforms UI in the block inspector controls.
Currently on trunk we show a
ToggleGroupControlwhen available variations are less than 5 and also have unique icons. The use ofToggleGroupControlwas added recently and there was an issue at the logic too, as it would still showbuttonsif the variations were more than five.In this PR:
buttonsUI and always show a dropdown if we have more than five variations.transformscope toSocial Iconblock.Design
This will need design input as for start I implemented a design similar to the Page summary panel for the below reasons.
DropdownMenuRadioItemcomponent would need to accommodate this, possible resulting in a lot of white space at the start of each option.titleis duplicate and could be designed differently. In trunk when we are showing a dropdown, we only show aTransform to variationbutton.So, despite the first design let's find what works best with @WordPress/gutenberg-design .
Testing Instructions
Social Iconsand test the variation transformations.Screenshots or screencast
Screen.Recording.2024-01-09.at.3.13.26.PM.mov