Global Styles: enable the ability to edit gradient & duotone palettes

[annezazu]

What problem does this address?

Currently, it's not possible to edit gradients and duotone palettes within Global Styles but this feels like a missed opportunity and something that users will want to do in the future.

What is your proposed solution?

For now, would be great to show duotone palettes even if they can't be edited. Long term, would be great to have these both as options for users to engage with.

[noisysocks]

Is this really a WP 5.9 blocker? Could we not add it in WP 6.0? Or is there a forward compatibility concern I'm not aware of?

[annezazu]

I think it could be added for 6.0 personally :) @priethor do you have more context?

[apeatling]

+1 for 6.0

[priethor]

@priethor do you have more context?

The most important part here is managing the duotone palettes globally; unless I'm missing something, as important as it is, it would be a nice-to-have rather than a blocker for 5.9.

[richtabor]

A couple ideas I'd like to float, cc @WordPress/gutenberg-design

1. Should we add a "Filters" top-level item to the Styles sidebar?

2. Perhaps there's a way to simplify the duotone edit/creation modal. I have a prototype to try it, basically pulling the color palette control and duotone control closer together.

CleanShot.2023-03-17.at.13.31.54.mp4

• The preview image is particular to a global styles instance, when you probably won't see the duotone filter applied when editing.
• When you select to edit one of the duotone colors, the color palette control renders below. This is in contrast to how duotone is applied today, where selecting a color opens a custom color palette. And there's extra UI for applying a preset to the highlight/shadow.
• The color palette control would work exactly like it does elsewhere—click on the color preview to open the custom color popover.
• If something like this gets in, we should do the same for the duotone toolbar control on blocks.

[jasmussen]

Should we add a "Filters" top-level item to the Styles sidebar?

Maybe, yes!

My current mental model for Global Styles items is that each drilldown should match a panel name in the inspector. There isn't one for filters, but #39452 actually suggests adding such a panel:

With a counterpart in global styles, this would then show the Filters → Duotone detail page:

Whether that happens in a flyout, or in the inspector, no strong opinion.

[MaggieCabrera]

A couple ideas I'd like to float, cc @WordPress/gutenberg-design

1. Should we add a "Filters" top-level item to the Styles sidebar?

This aligns with what I discussed with @ajlende and the direction the duotone filters are taking

2. Perhaps there's a way to simplify the duotone edit/creation modal. I have a prototype to try it, basically pulling the color palette control and duotone control closer together.

* The preview image is particular to a global styles instance, when you probably won't see the duotone filter applied when editing.

Should we use the preview component that we use on other parts of GS?

* If something like this gets in, we should do the same for the duotone toolbar control on blocks.

There is some discussion about this here

[richtabor]

My current mental model for Global Styles items is that each drilldown should match a panel name in the inspector.

Do you think we'd have a top-level "Filters" menu item, which navigates right to "Duotone" or would there be an intermediate step for selecting "Duotone"? Or would Filters > Duotone be fine for now, and when/if we add more filter types, we add the intermediate step?

Should we use the preview component that we use on other parts of GS?

Yes, the BlockPreview would be fine. It needs tidying up for images though.

Whether that happens in a flyout, or in the inspector, no strong opinion.

I like the presentation of the Duotone preview in the Inspector. My concern though, is that the preview/edit controls are above the presets, as you need to select a preset first—then go back above to edit the preview.

Feels a bit backwards.

My prototype enforces the notion of clicking on a preset to edit it, just like how colors and gradients function—though the Duotone + Color palette may be a bit funky together.

CleanShot.2023-03-20.at.10.55.43.mp4

[jasmussen]

Or would Filters > Duotone be fine for now, and when/if we add more filter types, we add the intermediate step?

Seems fine to add intermediate steps when they become available and not before.

I like the presentation of the Duotone preview in the Inspector. My concern though, is that the preview/edit controls are above the presets, as you need to select a preset first—then go back above to edit the preview.

Solid point. Edit: which ever gets implemented, let's just remember to also close the other issue! 🙏

[richtabor]

My prototype enforces the notion of clicking on a preset to edit it, just like how colors and gradients function—though the Duotone + Color palette may be a bit funky together.

@jameskoster any thoughts on how this could be improved? Do you think it's a bit funky?

[MaggieCabrera]

I'm working on adding the ability to edit and create presets for duotone filters, and I'm using the colors panel as a reference.

The code is shared between the panel that defines the colors globally and the panel that defines it for a specific block or element. This makes really weird interactions since you are allowed to edit the colors of the theme palette within a block, but things never get really saved:

I'm guessing this is not a desired interaction. Should the palette panel only show when we are editing on the global level instead of at the block? And mimic the same for duotone filters and only allow for preset creation/editing on the global level?

/cc @richtabor @jasmussen

[jasmussen]

This makes really weird interactions since you are allowed to edit the colors of the theme palette within a block, but things never get really saved:

Yeah, I've noticed this a couple of times too. The palette should not be available inside the individual blocks, that detail page should be entirely scoped to be just about the block and nothing else IMO. @annezazu do you know if there's an issue for this? Happy to open otherwise.

[jameskoster]

My prototype enforces the notion of clicking on a preset to edit it, just like how colors and gradients function—though the Duotone + Color palette may be a bit funky together.

@richtabor the UX works well imo, but I wonder if the initial view might be better if we preselected the first color. IE show folks this straight away:

Rather than this:

Speaking of which, those little white-outline circles could use an active state.

Side note, it might be good to look at this in the block toolbar as well because this is funky:

[MaggieCabrera]

Side note, it might be good to look at this in the block toolbar as well because this is funky:

@jameskoster Would it make sense to remove duotone from the toolbar altogether since we are also going to have the controls in the sidebar inspector? I've started working on that in #48405

[jasmussen]

I would not remove duotone from the toolbar without a fairly good reason. The main purpose of the block toolbar is to provide convenient quick access to the most important tools. Duotone fits that bill, IMO.

[jameskoster]

Yeah I would leave it there, but I don't know if it should remain possible to edit the values, that's when things gets overwhelming. Worth further exploration in a separate issue, but I'd expect options in the toolbar to:

1. Select a preset, or
2. Create a custom filter

The edit interface would only be visible when the latter is selected.

[jasmussen]

Agreed, we could vastly simplify what opens from the toolbar, if that helps. Even access to only presets seems fine, worst case we could have an "edit" link at the bottom.

[jordesign]

I would not remove duotone from the toolbar without a fairly good reason.

+1 to this. This would be a pretty major 'moved the cheese' situation for all the users who have had plenty of time to get used to accessing it within the toolbar.

[annezazu]

👋🏼 Hey folks, my past self included. I am doing a sweep of high priority issues and have removed this label. This issue has both stalled and isn't mapped out for the next WordPress release. If that changes, let's add the label back but, for now, this clearly isn't a high priority issue when looking across the project.