Dedicated Styles Screen

[jasmussen]

Brief

Global styles allows you to change the visual appearance of your whole website. It is also the visual interface to the singular theme.json file for a block theme. For the moment, global styles uses the sidebar API to make it live as a sidebar panel in the edit view of the site editor. Historically this has been useful to iterate the interface and make progress on the engine itself.

Fundamentally, however, the Site Editor edits individual templates or pages, making it a local interface rather than a global interface. Further, the contextual global styles sidebar panel (click a block to change the global styles for that block) is easily confused with the contextual local block inspector. You might have the global styles sidebar open, click a paragraph wanting to change the font size, and click "Typography".

A solution to that can be to move the global styles out from the edit view, and into the site view.

Proposal

In this view, the Style book can be the default view for the site editor, loaded in the frame on the right. The frame in this case, is not interactive, it's a visual preview of the styles that are chosen in the interactive panel.

This mockup relies on, and integrates design iterations to the Style book as tracked in #53431. In that issue, a curated "Overview" section of the style book is created to show the most important aspects of your website visual identity; color, typography, heading level sizes, etc.

• If you click Typography, the frame preview updates to show an exploded view of all type styles of the site.
• If you click Colors, the frame preview updates to show just a map of the color swatches.
• If you drill into the block section, each individual block, perhaps even patterns that leverage this block, can be shown. This will, for example, be useful should we move in the direction of showing pseudo states as well, in this exploded view (see Standardized way to modify interactive states (:hover, :focus .etc) for blocks #38277 (comment))

For the moment, the visual mockup above assumes a 1:1 transplant of the existing global styles sidebar into site view. See more explorations in Figma, here and here. One of those explorations can be seen here, and can be part of a future evolution of this work:

styles.mp4

Related: #53483.

[richtabor]

In this view, the Style book can be the default view for the site editor

I'm not particularly confident in having style book as the default for this view. I would think that you'd want to see the effect of style changes on your site, rather than abstracted in style book.

[tellthemachines]

I'm all for moving global styles to a place where it's easier to access! I do think we have to be careful with screen real estate and the double sidebar. Looking at the figma links, this one looks like it might make best use of space:

Alternatively, it could also work to have the whole global styles menu in the black sidebar and open up "browse styles" by default in the second sidebar (my shitty mockup below, sorry)

Whichever way we go with this, we need to consider where the stylebook is going to live in the future.

• Is the goal to transfer global styles completely to the left hand sidebar, eventually removing it from the right where it is now?
• If so, the stylebook will also move the left sidebar, and that means we have to add the tabs and clickable interactions we aim to add as part of Style Book: Iterate on presentation and design #53431.

Or

• Is the current global styles going to stay forever where it is, with the full stylebook hidden inside it, while the version of global styles in the left hand sidebar shows only a reduced (non-tabbed, non-clickable) style book?

I think we need to decide which way to go soon, otherwise we risk doing a ton of work on the stylebook that will later have to be changed or undone if we decide to move it somewhere else.

[youknowriad]

I think we need to acknowledge that the current mix of global styles and templates or global styles and document editing is bring unclarity to regular users.

I understand the arguments about Changing global styles and wanting to see the changes in a given template/post...

But for me, we've over optimized for this causing more confusion for regular users wanting to just change some obvious global styles (colors, backgrounds...), the common case over advanced users that know what they're doing when they open the global styles sidebar.

For regular users, they mostly get confused about What is this sidebar in the editor even about, is it about the current selected block, the current selected document or global (unless you know your way around WordPress, and FSE, for most it's very hard to understand that it's global) and no snackbar, guide or whatever is going to change that, these are complementary and not the real solution to the problem. It is also really easy to be overwhelmed when you go into the editor when you only want to make some global styles changes.

So, yeah, for me the only solution is to actually pull away the sidebar from the editor into its own global "styles" section. This doesn't come without challenges, but I think the confusion above is more important to solve than the challenges that come with moving this to a global place:

---

Challenges:

• What to show when you edit global styles: Yes, showing "style book" is not sufficient or is not ideal but IMO, for the common cases, it's better than forcing users to go to the editor. So practically speaking, I'm more than happy with shipping with stylebook as initial iteration (while keeping the current sidebar in the editor as we iterate for advanced use-cases). Also worth noting that this allows us to open the screen to classic themes, as these themes don't have templates that can load in an editor but they can still benefit from global styles and stylebook.
• As a second step, I saw same Ideas about a full browse mode where you actually load the frontend in the "preview" and not an abstracted version (editor) and you allow the user to actually navigate the frontend normally without the addition of "style injection" into the frontend. This is also not without its own challenges but it's worth exploring.
• An intermediary step could be to offer a toggle in this "global styles" focused editor to switch between "home page" and "style book".
• Advanced usage: I think what would be great as well, would be to allow themes to build their own "style book" / "design system kind of showcase" and use it in this section.

All these become possible if we start thinking about this section as an "editor focused on global styles" which free us from thinking about templates, pages... and I believe clarify things for the users and simplifies the mental model.

---

Another challenge raised above is about the sidebar design. I think that's an ok tradeoff to embrace for now, I agree it's not ideal, but the same issue exists for "list views" for pages and we didn't see too much dramatic feedback about it. It deserves a unified solution rather than one that is specific to styles.

• The unified solution could be to "ditch" this middle sidebar entirely but that requires rethinking the design of these middle sidebars.
• It may be simpler for global styles to move everything to the "black" sidebar. The challenge there is that our UI components are not yet capable of rendering in a dark background cleanly yet.

[tellthemachines]

The challenge there is that our UI components are not yet capable of rendering in a dark background cleanly yet.

How hard a problem would that be to solve though? I reckon it's worthwhile considering, especially now that this pattern of black sidebar + white sidebar seems to be spreading throughout the UI 😄

[youknowriad]

How hard a problem would that be to solve though? I reckon it's worthwhile considering, especially now that this pattern of black sidebar + white sidebar seems to be spreading throughout the UI

I can't tell for sure, I know that we did experiment with the global styles in the "black area" with @jorgefilipecosta a long time ago, it was doable with some CSS hacks. It might be better today. So we won't know unless we try it (if designers think this is a good approach)

[jameskoster]

How hard a problem would that be to solve though?

Themeable components is an important part of the admin redesign and design systems work. It will enable user personalisation through light/dark modes, contrast preferences, and so on. It's not a trivial task though cc @ciampo @mirka @tyxla.

The unified solution could be to "ditch" this middle sidebar entirely but that requires rethinking the design of these middle sidebars.

At its core, the dark sidebar is primarily for navigating through the admin, so elements of the Styles UX—such as switching between variations, colors, typography, and blocks—could theoretically be placed there (needs design exploration). However, I believe that forms should remain within the Content Frame (the middle sidebar). It's important to note that the Content Frame is the same container in which Data Views live. Ideally, we should align with these emerging conventions to maintain consistency and avoid ad hoc solutions that water down the overall UX. I appreciate that documenting layout would be helpful, it would be good to do this as a part of the design systems work.

Initially it seems simplest to place the entire Styles panel inside the content frame, like the mockups in the OP. Moving the navigational pieces to the sidebar could happen (as mentioned above), but needs some design exploration.

In terms of switching between site / style book, there is a mockup here:

[jasmussen]

We can potentially make the style vs. templates even more visible a switch, by making it a segmented control (if we can find good labels). But even then we have to acknowledge that in this site-view first version of styles, there's currently no interface for choosing which template you can see. It's just the homepage. Which has value of course, and is arguably sufficiently representative of "the site" to be useful. But I agree with the arguments presented, for why Style book is ultimately a better default, including these:

I think we need to acknowledge that the current mix of global styles and templates or global styles and document editing is bring unclarity to regular users.

I understand the arguments about Changing global styles and wanting to see the changes in a given template/post...

But for me, we've over optimized for this causing more confusion for regular users wanting to just change some obvious global styles (colors, backgrounds...), the common case over advanced users that know what they're doing when they open the global styles sidebar.

An added value of global styles in site view is that this can much more easily make the site editor with global styles available to classic themes, or even hybrid themes, because a style book can be useful for any one of those configurations.

An additional benefit is that if we were to move towards the style book being the primary place where you can see and style every state of a block (current menu item, hover, active, focus), it may increase the prominence and discoverability:

The style book is a coffee-table book, a visual identity of your website. It shows every block, heading, color, and setup that you have available, even when those blocks are not used in your site yet.

[mtias]

@jameskoster also curious if instead of a dropdown with two options it could just be a segmented control with two options.

[jameskoster]

With the right icons and tooltips, sure.

[jasmussen]

Can be text, "Site" & "Style", perhaps.

Addendum thought: it will be slightly disruptive to relearn where to find global styles when it moves from edit view to site view. Should we want to do this in steps, we could potentially start with template by default to start.

[andrewserong]

Themeable components is an important part of the admin redesign and design systems work. It will enable user personalisation through light/dark modes, contrast preferences, and so on. It's not a trivial task though

From the discussion, it sounds like if we're looking at just the top level navigation living in the dark sidebar (as in the mockup from @tellthemachines #66376 (comment)) then we can likely use some CSS hacks in the short-term, and since that panel won't include any forms (as it's only the top level screen)?

Initially it seems simplest to place the entire Styles panel inside the content frame, like the mockups in the OP. Moving the navigational pieces to the sidebar could happen (as mentioned above), but needs some design exploration.

So in this case, the thinking is that we'd go with moving the entire Styles panel inside the content frame as a first step, and could potentially look at utilising the dark panel in a follow up PR?

The style book is a coffee-table book, a visual identity of your website. It shows every block, heading, color, and setup that you have available, even when those blocks are not used in your site yet.

I like the coffee-table book metaphor 👍
For the purposes of thinking about the Style Book work, it sounds like we're going to retain tabbing (or a tabbing-like UX) for the foreseeable future. Just wanted to mention that as there are a few iterations in the works or that have landed recently (e.g. Color tab) that are from this idea of a tabbable interface or one with categories, so it would be good to highlight if we think that approach is going to change.

Thanks for all the great discussion here!

[tellthemachines]

At its core, the dark sidebar is primarily for navigating through the admin, so elements of the Styles UX—such as switching between variations, colors, typography, and blocks—could theoretically be placed there (needs design exploration).

There was some exploration here which looks like a pretty good starting point.

Ideally, we should align with these emerging conventions to maintain consistency and avoid ad hoc solutions that water down the overall UX.

Given the conventions are still emerging, this seems like the ideal time to shape them to our needs 😄
Reaching for ad hoc solutions is usually a sign that the conventions aren't entirely suited to the problem they're trying to solve.

Having said that, in this case I think that having a list of style elements in the black sidebar is very similar to the list of page states that populates it in the Pages section, so the consistency would be maintained.

It would also be worth exploring ways of collapsing the white and black sidebars at medium/small screen sizes, because currently it all looks pretty squished:

Let me know if there's a more relevant issue to share that last bit in!

[jameskoster]

Having said that, in this case I think that having a list of style elements in the black sidebar is very similar to the list of page states that populates it in the Pages section, so the consistency would be maintained.

I don't disagree! Like I said in the previous comment it could make sense to place the navigational pieces of the current styles panel in the sidebar. If it's not a big lift to do that, then let's try it. My only reservation is about potential wasted effort due to the lack of an agreed upon design vision—not only for the Styles panel outside of the editor, but the broader iA as well.

Given the conventions are still emerging, this seems like the ideal time to shape them to our needs 😄

Of course, but I think it makes sense to push what we have to the limit in order to validate additional shaping.

For the purposes of thinking about the Style Book work, it sounds like we're going to retain tabbing (or a tabbing-like UX) for the foreseeable future.

Eventually those tabs might go away in favor of intrinsic navigation. For instance when you open the 'Color' section in the Styles panel then preview frame shows the color 'page'. In any case I don't think we should show the tabs outside of the editor – the preview frame there should be inert like in #65619.

[afercia]

Bringing in my two cents:

An intermediary step could be to offer a toggle in this "global styles" focused editor to switch between "home page" and "style book".

Ideally, it would be worth offering both experiences as in: the style book and the preview. I'm not sure whether the actual point is a distinction between regular users and advanced users. Regardless fo the users ability, they may want to either make wuick adjustments or exploring more deep changes so that I'd think providing both interfaces would be valuable.

It may be simpler for global styles to move everything to the "black" sidebar.

I'm not sure that would be ideal. To me, the 'black sidebar" (is there a code name for it?) should be reserved only to navigation. Actually, it's an ARIA region labeled 'Navigation'. The fact it also contains some selection tools like the style variations is, to me, slightly confusing becuse it's now a mix of navigational and editorial tools. I would love to see the black sidebar provide a more simple mental model and be reserved to navigation.

At its core, the dark sidebar is primarily for navigating through the admin

I'd agree with @jameskoster here. As a consequence, it seems more appropriate to use the 'Content Frame' (the additional sidebar). But, I'd recommend to not underestimate the screen real estate issue. As @tellthemachines reminded, sidebars inherently provide a limited horizontal space. The editor suffers from this problem in many places. Usign two sidebars doubles the problem. This applies to the data views 'Content frame' as well so it's a broader issue but I'd like to suggest to explore solutions that would provide more horizontal space.

With the right icons and tooltips, sure.
Can be text, "Site" & "Style", perhaps.

As per the book/site switch: yes please, text would be more accessible. Please consider to avoid unnecessary icon buttons when possible.

[jameskoster]

Today I spent some time updating the prototype shared in the OP. It's still rough (especially the visual details), so I'd welcome feedback.

styles.mp4

• Top level Styles navigation moves to the dark sidebar.
• Sidebar includes a toggle for switching Preview Frame display; Style Book or Site.
• Style book page updates as you navigate.
• Switching from a customized style variation produces a warning.
• Color + Typography sections feature a UI that splits simple editing (choose a preset) and advanced editing (customise all the values) via Tabs.
• 'Site' section combines existing Layout and Background panels.
• Elements move out of Color and Typography panels into a dedicated section so that users can style them entirely without having to switch sections.
• Revisions and Custom CSS panels remain as they are for now.

There's a lot here, and it may not all be good. It seems likely we'd need to find interim steps as well. So let's continue to discuss :)

[andrewserong]

Lots of cool ideas in there @jameskoster: one question came up for me while watching. There are a fair few differences between what's proposed there and what we currently have in the global styles sidebar within the editor. Were you imagining these both coexisting? If we wind up with different versions of similar screens (e.g. style variations and typography), it sounds like there could be a fair bit of duplication if we want to maintain different versions.

To put the question slightly differently: is the proposal here to redesign the inside of the global styles panels wherever they live, or to create an additional (and slightly different) set of screens that lives at the root level?

[tellthemachines]

is the proposal here to redesign the inside of the global styles panels wherever they live, or to create an additional (and slightly different) set of screens that lives at the root level?

Curious about this too! I do like the idea of having basic and advanced controls in separate tabs as this would make it easier for less advanced users to make sense of things. On the other hand, will that make things harder for more advanced users? #48157 presents an argument for having all things visible at all times. I wonder if it would be worth exploring some sort of theme development mode (which could be as simple as toggling a preference to show advanced tools by default instead of basic).

I also love the navigation! Having top level styles navigation in the black sidebar is consistent with the ARIA role as @afercia mentions above, though we do need to refine the responsiveness of the double sidebars.

The stylebook view changing according to which styles section we're in feels much nicer than the current tabbed stylebook, which makes me wonder if there'd ever be a case for browsing the stylebook independently of global styles.

[jasmussen]

Some good visioning there, Jay. I think there are good ideas there, potentially to explore at a later stage. They all assume that moving global styles into the site view works, so we'll need some stepping stones to get there first, with a reduced set of variables.

[afercia]

Sidebar includes a toggle for switching Preview Frame display; Style Book or Site.

I'd kindly ask to use visible text for that button. Icon buttons should be avoided when there's enough space to use visible text. Also, buttons should not be used to convey the state (the icon switches), Instead, they shoudl clearly identify the button's action.

[afercia]

As a first accessibility feedback related to the last iteration on #66376 (comment) I would strongly recommend to improve the sections in the navigation panel.

Those are 3 sections that contain logically grouped concepts. However, only the firsst section is clearly identified by a visible heading. The other two sections aren't.

I'm not sure distinguishing these 3 sections only by the means of white space is sufficient. Sections of content, where in this case 'content' is a set of logically related controls, should alays be identified by a meaningful label.

[jameskoster]

Were you imagining these both coexisting?

Excellent question, one we should answer before redesigning the panels for sure. I see a lot of feedback that the Styles panel in the editor creates a lot of confusion, I sometimes get caught out by it myself! That said it should still be possible to reach global styles from the editor somehow.

refine the responsiveness of the double sidebars.

Agreed, though this is a global consideration. Saxon shared some ideas here.

Sections of content, where in this case 'content' is a set of logically related controls, should alays be identified by a meaningful label.

I'm not against labels for each section at all.

[jameskoster]

They all assume that moving global styles into the site view works, so we'll need some stepping stones to get there first, with a reduced set of variables.

Agreed. Landing the PR associated with this issue feels like a good first step. I think it's just missing the Style Book toggle.

[ramonjd]

I think it's just missing the Style Book toggle.

iI wasn't obvious to me at first, but I think I found it. Maybe I was expecting a different icon. 🤔

2024-10-30.08.05.09.mp4

[annezazu]

iI wasn't obvious to me at first, but I think I found it. Maybe I was expecting a different icon. 🤔

This isn't obvious enough IMO. I could not find it until seeing this video :)

[ramonjd]

I'm thinking it could be moved to the header (if that's possible). We're still relying on the icon telling the story, it might be more accessible and faster to grok with a text button. 🤷🏻 I'll play around.

[tellthemachines]

it might be more accessible and faster to grok with a text button

It'll definitely be more accessible. Those icons all look the same to me 😅

[afercia]

This isn't obvious enough IMO. I could not find it until seeing this video :)
Those icons all look the same to me

Please use a text button.
Icon buttons have inherent accessibility and usability problems. To be more clear: the proliferation of icon buttons is problematic.
As reported several times in many other issues and PRs: icon buttons may add value in certain cases when they are limited to a set or well recognizable icons. However, wherever the UI provides enough space to show visible text, text buttons should be preferred.
I'm not opposed to buttons that show an icon and visible text, as that would use the best from both worlds.

I find particularly confusing icon buttons that 'switch' icon depending on the state. This has been reported as problematic several times as well. Buttons should not be used to communicate the state or the selected value. Instead, buttons must clearly communicate the underlying action. I do see this pattern is used in other places in the UI but I'd warn against it and strongly recommend to reconsider it.

[richtabor]

iI wasn't obvious to me at first, but I think I found it. Maybe I was expecting a different icon. 🤔
This isn't obvious enough IMO. I could not find it until seeing this video :)

Same. I'm not a proponent of this one button toggle icon to switch between the two views. Do we have this pattern elsewhere?

[ramonjd]

I'm not a proponent of this one button toggle icon to switch between the two views

It's going through iterations. I'll aim to implement @jameskoster's tip on the Menu component.

[jasmussen]

#65619 is close to landing. I shared a slightly updated mockup there, will copy it here as well:

Same button, compact, lines up vertically with items in the list, same style as is used in similar contexts (including the document inspector, etc). Click to toggle between style book and templates.

It's worth remembering what the goal is here:

• Make it clearer where and how to style your site, globally, by placing it in context of other global items like templates and patterns.
• Remove confusion about style vs. global inspectors in the edit view (we've seen user test of people switching between inspectors, wanting to change a single paragraph size, then clicking "typography" which is global instead of local).
• Bring fonts and style tools to classic themes (Consider exposing the Style Book for classic themes #41119, Consider exposing the Font Library for classic themes #64409).
• Elevate the style book to be more legible and useful (Style book: creating landing page view #66517).
• Provide a clearer interface for seeing all variations of a block, so that you can style each variation individually (Standardized way to modify interactive states (:hover, :focus .etc) for blocks #38277 (comment))

Details are important. But it's also easy to get caught up in looking far ahead, through style updates, the appearance of menu items, separators or not. All of those are valid and worth getting to, but it's useful to focus on the specific improvements at hand first, get this into the plugin so that it can be tested, and to help inform those future iterations so we move with intent.

To that end, I would suggest putting the few final tweaks on #65619, and then moving all attention to improving the style book (#66517). After that, we can make progress on bringing these improvements to classic themes (#41119, #64409), which is oft-requested and can be a big win, and after that, allowing the styling of pseudo states (#38277 (comment)). This will significantly help block themes, that users are able to finally provide clear and contrastful focus styles, in the visual editor where we can show contrast warnings as aids. Default browser focus styles are not always sufficient.

This will also not preclude future enhancements, as noted initially in this issue, which refer to space efficiency, merging columns, and providing theme packages to enable the styling controls in additional color contexts. As noted on details, we'll get to this, but perhaps best to focus on the more meaningful steps forward that we can take first.

[tellthemachines]

Should this issue have been closed by #65619 or are we still planning to improve the double sidebar experience by moving the global styles navigation into the black sidebar?

To that end, I would suggest putting the few final tweaks on #65619, and then moving all attention to improving the style book (#66517).

With #65619 merged and with #66719 upcoming, the designs in #66517, which explicitly deal with a tabbed interface, are less applicable.

I've started work on a landing section for the style book in #66545, so playing with that should be a good starting point for working out what this landing will look like with the style book in its new location. I'd appreciate feedback, ideas, designs on this!

[andrewserong]

Should this issue have been closed by #65619 or are we still planning to improve the double sidebar experience by moving the global styles navigation into the black sidebar?

We've implemented the first stage, and there's quite a lot of discussion here, so closing seems appropriate to me. We could open up a follow up issue to tackle the next stage(s) of working on moving some things to the black sidebar and progressing the designs further?