Global Styles: Managing style variations

[critterverse]

Now that a first iteration of the style variation switcher has merged (🎉🎉), let's discuss how we might include functionality that would allow users to save their style customizations. There are several different ways we could approach this but overall, the goal is to help users avoid accidentally resetting their existing style customizations when trying out a variation.

One idea is to provide a way for users to save new variations. For example, maybe you can name and save your current settings from the ellipses menu in the Global Styles panel:

Some of the other possibilities that were discussed in #35619 are:

• Automatically saving a copy when customizations are made to a theme-provided variation (block template model)
• Providing two options when the user applies a style variation (merge with current user changes + apply or just apply)

Longer term, we'll also probably need a UI that allows users to manage their variations — either directly within the Global Styles → Style variations panel or possibly via a "post list" type of screen in the site editor.

[aurooba]

I would rather see the ability to set a name within the inspector than in a modal. Perhaps when you save it, it shows you the style variation in the preset area, and focuses a text area where you give it a name and hit a checkmark to save it? Context: I think of modals as necessary but avoided if possible territory.

The other thing I'd really love to see is a little red dot, or some sort of visual feedback that you have now made changes that are different from your currently selected preset. I love that little touch in the Templates screen. It can be hard to remember if you've made any changes or not, and a little visual feedback would really help.

[critterverse]

👋 Revisiting this issue to think through some of the potential flows for saving custom style variations.

Note: These mockup include text labels under each style variation thumbnail, which is an addition to the UI discussed in #38918 (comment). Both updates to the UI are meant to bring more clarity around the style switching process.

Saving a style variation

saving-custom-styles-1.mp4

The above video shows how one of the theme-provided style variation styles could appear to be active until the user has made customizations in the Global Styles panel. Once a user’s Custom Styles have been saved, those customizations could appear as a “Custom Styles” thumbnail in the style variations panel.

I didn’t mock up every step of the flow but imagine the user makes some changes in the color panel around :13 😁

Switching between and saving over a style variation

saving-custom-styles-2.mp4

Even after making their own customizations, the user may still choose to reset their design to one of the default style variations provided by the theme. From a user perspective, this feels like it shouldn’t require the extra step of the saving panel.

Starting at :18, the video shows how the previously saved “Custom Styles” thumbnail wouldn’t be replaced until the user chooses to overwrite it in the saving panel.

“Saving as” a new style variation

saving-custom-styles-3.mp4

If the user doesn’t want to overwrite the existing “Custom Styles” style variation, another option could be to allow them to “save as” from the saving panel. This could open a modal (similar to the flow for creating Reusable blocks, etc) for entering a custom name.

Thank you to @jasmussen and @kjellr for helping think through improvements to the current UI.

Figma file

[annezazu]

How neat to see this continue to come to life! Thanks for these fantastic explorations. In case it's helpful, I wanted to pass along some feedback while watching the videos:

• How easy it was to overwrite custom styles.
• The friction in place to create a new custom styles option.
• The disconnect between the multi entity saving flow and the style options. I expected to see changes to "dark" rather than "custom styles" in your second video since you selected the dark preset and made changes.

Overall, it felt too easy to overwrite custom styles and too hard to save a new one. Perhaps this is intentional since, for example, it might not make sense to customize a style preset provided by a theme (even though we can with templates?). I just can imagine folks wanting to quickly create a few different style options and then select which ones to update in multi entity saving rather than creating one custom style option that they continually overwrite (this overwrite flow seems to be emphasized currently).

• A way to reset to default of what was provided by a style preset (unless we don't want to allow for this for technical reasons).
• Clarity in multi entity saving to overwrite or save new when I want.

[critterverse]

Thanks @annezazu, this is very helpful feedback for thinking about how more robust saving functionality could work in the long term!

TL;DR from the original PR: A "simple" approach was implemented that doesn't lend itself to some of the behavior you've described. I'll try to explain the limitations with the current approach below (others, please chime in with any clarifications 😅)

Overall, it felt too easy to overwrite custom styles and too hard to save a new one. Perhaps this is intentional since, for example, it might not make sense to customize a style preset provided by a theme (even though we can with templates?).

I expected to see changes to "dark" rather than "custom styles" in your second video since you selected the dark preset and made changes.

In the current system, the selected style variation is being saved as user changes. When a variation is applied and saved, the user's Custom Styles are just updated to match the values from the provided variation. This is also why the current UI doesn’t indicate which variation is active — the thumbnail for the "Dark" variation only represents the variation as the theme provided it, not including any user changes that have been made on top of that variation.

For more context, it may be helpful to start reading from this comment where I raised some similar questions in the initial PR.

Clarity in multi entity saving to overwrite or save new when I want.

+1 Seems like there's lots of room for improvement here.

I just can imagine folks wanting to quickly create a few different style options and then select which ones to update in multi entity saving

This is a great summary of how a user would probably expect to interact with this feature, and helpful to keep in mind as we keep iterating. Also wanted to add that it's still possible to revisit the simple approach in the future but it would be great to figure out ways to improve upon the existing architecture for now.

[aurooba]

I agree with much of what @annezazu said, the confusion I felt watching those videos felt great enough to wonder if this 'simple' approach is really 'simple' and the right direction to start from.

I think the option to create multiple custom styles needs to be more obvious. If I make a change, that change shouldn't necessarily be assumed to be an update to the existing Custom Styles variant, but should be assumed to be a new Custom Styles variant. In the video where you made a change while the dark variant was selected, I expected the save workflow to show Custom Styles 1 or Custom Styles 2, rather than overwriting the initial Custom Styles.

Thank you for making those workflow videos, it's really helpful to visualize the proposed ideas!

[mtias]

Currently modified styles are a separate layer that I think we should present slightly differently from style variations — maybe with a separator below the style variations saying there are custom modifications. Saving custom styles goes into the user style object, for example, but it should also be possible to package user styles as a style variation in case you want to save something for later, or you expect to make drastic modifications and don't want to lose a particular style you liked. This is a flow that might exist specifically within the styles panel only (save custom modifications as a separate style) even if we can surface better in the saving flow.

There are other management functions we should allow if we open variations to be saveable: it should be possible to duplicate an existing style as a base, it should be possible to delete user created styles, etc.

We should probably list if there are user modifications active as a first step.

[jasmussen]

Tangential to this effort, #39629 details style randomization. And if you happen upon a really sweet random style, it'll benefit from the work here, so you can save it.

[critterverse]

👋 Here's a quick sketch for a user-modified styles section below the theme-provided style variations. Within the modified styles section, the thumbnail previews could include a "more" menu (possibly on hover/focus only) with an option for saving the modified version as a proper style variation:

A couple of approaches to displaying the variation title are being experimented with in #39322 so that aspect is still TBD. But it seems likely that variation titles will be displayed in some form or another, so perhaps similar to @aurooba's suggestion above, the modified styles could automatically be named as a version of the base style variation (Dark 1, Dark 2, etc).

For starters, I can imagine only the user-modified items having a “more” menu, via an ellipses icon or similar. Once saved as a variation, the menu options could include renaming and deleting. (Maybe you could delete items from the modified styles section as well when not active.)

Tangential to this effort, #39629 details style randomization. And if you happen upon a really sweet random style, it'll benefit from the work here, so you can save it.

The randomizer option would be an awesome addition to this panel and could be a great use case for modified styles? I can do some more thinking around this!

[clubkert]

I'd give a +1 to this feature. As I've been testing 6.0 and creating some interesting styles, I've been wanting to save them in the editor :)

I also found that I've lost my changes when switching to new variations. I created a separate issue, since I think a quicker solution to that problem might just be a warning. But perhaps they can be considered together.