Iterating on Details → Styles to lower emphasis on style variations

[annezazu]

Currently, the Style section of the Site View emphasizes style variations with a deep link to open Styles. In writing calls for testing and thinking about current issues with changing style variations, like Custom CSS: Unsaved Additional CSS is lost after browsing different style variations & Custom colors are lost when styles are changed, it feels risky to surface style variations to this degree and doesn't align with what I imagine is a common action a user will take. For many, style variation switches would constitute a pseudo theme switch in terms of impact to the site's design and potentially layout. Right now, it's really easy to switch and not know how to switch back to what you originally had too without an undo button visible. I know we have revisions but to access those revisions one would have to know to go to the granular Styles view > three dot menu > view revisions.

What else can we emphasize here? Font management is worth considering if this lands in time for 6.3 #45271

cc @mtias @WordPress/gutenberg-design

[jasmussen]

I'd like to see Color palettes and Font pairs as two drilldowns in this section. As soon as we have one of either, that would make "Style variations" into its own drilldown, and therefore reduce its prominence. If #45271 can land, it seems possible we can make a minimal fonts section.

Alternatively, we can just go and make Style variations into a drilldown already. It would feel a bit bare to have a Styles section with just one item, plus the edit and style book items, but it might still be worth it temporarily. Depending on what lands, we can even convert the style book and edit items into menu items to give them more prominence, while we wait for the other drilldown sections to land.

[jameskoster]

One thing to try could be an iteration that lists the selected style variation, and offers a pathway to choose a different one. It could even be similar to the theme button that has been design for the Design root:

Such a UI can potentially help users understand that choosing a different variation is akin to starting again, and will wipe out their customisations.

[jasmussen]

I like the button, and I like the two color dots. I think it can still be worth it to have a style variation drilldown, the active style variation isn't always "kept" — i.e. as soon as you make your own custom changes to it, unless you save them, you're effectively disconnected.

One thing we discussed was potentially having a "Fonts" link here, that just opens the modal from #50927.

[jameskoster]

I think it can still be worth it to have a style variation drilldown

Agreed, that's what the button would link to.

the active style variation isn't always "kept" — i.e. as soon as you make your own custom changes to it, unless you save them, you're effectively disconnected.

Yeah, it's about making that behavior intuitive in the UI. Another option would be to display the variation as the current style, until you make changes at which point it switches to Custom.

[mtias]

I think this treatment overtly emphasis color at the expense of everything else and can be misleading. For example, the TT3 variations won't be well captured with a dotted color approach.

[jameskoster]

We could try a minimised version of the tile from the main Styles panel, to capture typography a bit:

But it might be simpler to only display the name.

[mtias]

Sort of related, can we try a quick prototype that lifts the entire styles sidebar as is in the full editor and change the color of the dark material to light gray when entering styles? I'm curious if it might work.

[jameskoster]

@mtias it seems a little clumsy on the left (different panel header format etc), but this is obviously without any massaging of the details:

styles.mp4

It's a bit less awkward if the Styles panel appears from the right:

styles.2.mp4

[paaljoachim]

Ahhh that is interesting James!
Appearing from the right shows a kind of shadow of what it would look like when going into a template and clicking the top right Styles icon to enter the styles area. It would give a kind of consistency of the location of Styles.

[jasmussen]

I think if we transplant the styles panel from the edit view to the site view, we can probably do light-weight tweaks for it to match the detail page structure, like the subheading etc. But overall, this seems like it could be a good short term solution that solve a bunch of problems including the inspector/global inspector confusion, as well as the prominence of the variations. @mtias what do you think of Jay's sketches above?

[jasmussen]

With fonts looking unlikely to land, one thing we could do is to put style variations into a drilldown (so it's Design > Styles > Style variations), and then have a button above the drilldown that just says "Global Styles", which takes you into the full editor just like the edit button does at the moment.

[annezazu]

Sounds good to me except I still feel like we should shy away from "Global Styles" in the interface, similar to this issue #51202. Perhaps something more action oriented like "Open all Styles" or simply "Open Styles" indicating an action?

[jasmussen]

A quick visual:

CC: @jameskoster what do you think?

[jameskoster]

That lowers the emphasis a bit, but since it's the first item of only two, it is still quite prominent. It also makes the panel feel a bit empty.

If something like #50924 (comment) isn't going to be feasible for 6.3, maybe the Styles button at the root should just deep-link into the full-screen editor with the Styles panel open?

[jasmussen]

That can be feasible for 6.4 and later, I'm thinking of the above as a 6.3 bugfix, so the changes have to be minuscule.

[jameskoster]

It could be worth trying, but it makes the panel feels lacklustre to me because half the action items just send you to the main styles panel anyway.

If we do try it, should "Style variations" be "Browse styles" to match the main panel? Also, perhaps "Edit styles" instead of "Open styles"?

[jasmussen]

Like so?

[jasmussen]

@ntsekouras The mockup in the comment immediately above, would that be tricky to implement, and can we get this in as a bugfix for 6.3?

[ntsekouras]

@jasmussen Regarding the browse styles should it show the style variations in the navigation sidebar like it's now, or it should go to edit mode and open the inspector(right) sidebar?

[jasmussen]

Regarding the browse styles should it show the style variations in the navigation sidebar like it's now

Yes exactly, the same detail is just buried one level deeper.

[draganescu]

The styles element in the site editor sidebar now disables distraction free mode on purpose, because in this mode we go to great lengths to make sure no chrome is present (due to how the editor UI is built it's not immediately obvious how to interact with overlapping z-index items).

[annezazu]

Closing this out as the initial PR to address this was closed: #51964 (comment) in favor of #52158 which matches current behavior in Trunk. While I disagree with no deprioritizing due to the current bugs, let's see how this lands and reopen/iterate as we need.