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.

[annezazu]

Noting that this once more came up in the seventeenth call for testing for the FSE Outreach Program and I imagine will come up more so when TT3 launches with 10 variations as a feature:

If I change the styles manually (colors, etc.) then switch to a different style variation, there is no way to get back to my previous version. There is also no warning that I will be losing all of my hard work. I had reported this previously, but ran into this issue again 🙂

This comes from @clubkert who shared months ago as you can see above that he ran into this!

[clubkert]

Thanks, @annezazu .

Personally, I think a warning that your style changes will be lost by changing to another variation would be a positive sort term solution.

Longer term, being able to save changes would make sense.

[jameskoster]

I think a warning that your style changes will be lost by changing to another variation would be a positive sort term solution

I agree with this. Style variation management is a pretty big feature, for now a warning would help mitigate the biggest issue which is the loss of custom variations on-switch.

[jasmussen]

I went ahead and made new mockups based on the work presented here, and shared in #45371. I kept things separate for now, as the new flow includes options to import and export style variations as files, but depending on feedback I'd be happy to merge into this issue instead, or vice versa.

[jasmussen]

#45371 has been updated to include design elements from Channing's designs here (props are due!), but in addition to this, allow importing, exporting, copying styles from another theme, deleting, and otherwise. Would it be useful to close this one in favor of the other, or update this one and close 45371?

[beafialho]

I was thinking briefly about managing style variations with @jasmussen, in the context of the Create Block Theme plugin, which I use to create block themes, and here are some ideas that may be useful for this issue:

• Similar to how the plugin handles font management, it could have a "manage style variations" panel. We would create or edit a style variation, save changes, be able to review all changes, confirm and go back to finally export the theme. I made a rough prototype.

prototype.mp4

[annezazu]

This was raised in the FSE Outreach Program's Rapid Revamp call for testing by @paaljoachim

Selected the Style section and clicked the various styles. So many things change when clicking a style. What if I just wanted the font or the background color. It would be nice to drill down into a style and turn options on or off depending on what one wants. A style is very opionated based on the person whom made it. It would be good to be able to customize the style and save it as a new style. Creating user modified styles.

[jameskoster]

Updated the title to make this issue about managing style variations more broadly, which still needs some design exploration.

Inspiration can potentially be found in the pattern management experience. For instance there it is possible to clone theme-bundled patterns and subsequently edit them. A similar requirement exists for style variations.

[ellenbauer]

I'm not 100% sure if this is the correct issue to add to, but having some form of indication which style variation is active right now, would also be very useful.

RIght now, the only way to see which style variation the user is customizing is under 'Browse Styles'. I feel it could be more prominent. E.g. I feel it would be helpful for users to see that they are customizing the color palette of which style variation which customizing colors. Same for Typography and Layout.

[SaxonF]

I'm not sure whether we want to be working from this one or the issue @jasmussen linked to above but lets assume this one.

I like Joen's proposal and think we can start simple by allowing saving/updating/deleting in a way that aligns with the block inheritance issue (e.g. blue dot to show changes).

This is from Joen's issue:

One other adjustment which satisfies @ellenbauer feedback is that we can surface style name in the root of the styles panel and use that to access style list vs "browse style" as it allows us to adopt the dot to signify changes (similar to keynote styles in a way). We'll also want to alert on variation switch which is a big pain point right now

So acceptance for V1:

• Show style name in root of styles panel
• Clicking style name takes you to variation list
• If a user makes a change to a theme variation and attempts to switch variation, prompt them to "save" their styles first
• If they choose to save, create a new variation called "custom style"
• User created variations should appear at the top of the list.
• User variations are tied to the theme for now (unless its technically easier not to)
• If a user makes a change to a user variation they will see an "update style" button under the style name. Clicking this button will update the variation and the dot will disappear
• If a user makes a change to a user variation and attempts to switch variation, prompt to "save" their styles first which just updates the selected variation
• In the list of styles under the "custom" group they can hit the "+" button which triggers the style creation modal
• the style creation modal has a single field for style name
• Creating a new style copies whatever style changes are active in to a new variation

[annezazu]

To focus efforts and consolidate next steps, I'm closing this out in favor of #45371 Thank you for all the discussion and ideas shared here. @SaxonF mind sharing your great next steps comment on #45371?