Styles: better connect top level dedicated Styles screen with the in editor Styles screen

[annezazu]

As the work for #65619 lands to introduce a dedicated styles screen at the top level in the Site Editor per this issue , I wanted to open an issue to discuss removing the in canvas/editor Styles option after the full functionality is ported into this top level item. I didn't see this discussed as a follow up item but I could have missed it so opening this to be safe and keep it top of mind.

From what I have seen in years of testing the Site Editor, removing the in editor option will help reduce confusion in a few ways: less icons/options in the toolbar, remove a global option that sits next to local options (block settings), confusion around the icon itself, and general misunderstanding that the changes made in the Styles section impact the entire site rather than just the template or page being viewed.

[annezazu]

FYI to @jameskoster @aaroncampbell @ramonjd @andrewserong @tellthemachines who have been diligently working on much of this.

[ramonjd]

removing the in canvas/editor Styles option after the full functionality is ported into this top level item
From what I have seen in years of testing the Site Editor, removing the in editor option will help reduce confusion in a few ways: less icons/options in the toolbar, remove a global option that sits next to local options (block settings)

Thanks for opening this issue.

I think relocating global styles (including the style book and possibly revisions) is consistent with:

• the progress made on the style panel in view mode, as well as
• the proposition to bring global styles features to classic themes.

An inextricable condition of doing so, for me, would be to offer an obvious and low-effort bridge between the site editor and the dedicated global styles view. A change this large I think would require something obvious, like a prominent "Edit site styles" button, or keeping the existing global styles icon around for a while - maybe it would open up a modal containing the dedicated view.

Furthermore, it'd be worth having a two-way channel for communication between global styles and the site editor, for example to allow for deep linking to global styles controls.

So, if I'm in the site editor and editing a block's style, it would be convenient to have a direct path to edit the global styles for that block.

This PR is kind of related to this idea.

Conversely, if I'm editing my site's global styles, I might want to slip back into the editor to tweak the current template, or fiddle with an individual block's styles.

Without such a bridge, features like this one would have no context or recourse for undo or further customization:

One possibility might be to have the current template enter zoom out mode and then the global styles panel open up from the left:

A high-level discussion on how to build a dedicated global styles component/package/whatever is going on over in #62216 (comment)

[jasmussen]

Good notes above.

Another thought coming to mind, is showing a notice like was done when the block inspector was split in settings and style tabs: "Looking for block settings? Try the style tab."

Some quick options:

We should pick, of the above, the one that's easiest to implement. Ideally there's a design system task in this as well, to figure out a consistent use of dismissible feature notices like this.

[jameskoster]

Are we certain about removing it entirely? We're potentially introducing several clicks to go from the editor to global styles.

Could the button remain, but navigate to the new Styles area? The significant shift in context might reduce some of the existing confusion.

[jasmussen]

Are we certain about removing it entirely? We're potentially introducing several clicks to go from the editor to global styles.

There are several benefits to entirely removing it, including removing the confusion between the local block inspector and the global style inspector often intermingling. Also, the space in the top right is becoming slightly crowded, and finally with the use of the style icon for the split block inspector, the duplication there is also addressed.

I would agree that there are many ways we can get there, and that there needs to be no rush to do so. In fact we might even show a "Styles are about to move" notice inside the existing global style inspector, for a while. Outside the initial shifting concern, do you have overall concerns about the move in general?

[jarekmorawski]

Not sure if it's helpful, but would it make sense to create a custom interaction that will explain to the user where the 'site view' is when they attempt to locate the old Styles button in the UI? Here's a quick animation I put together. Notice how the icon appears in the home button in the top right corner, indicating where the user will find Styles after the change.

styles.mov

[jameskoster]

removing the confusion between the local block inspector and the global style inspector often intermingling

This shift in context might resolve this, without introducing extra clicks. I understand the confusion that exists today, but I also believe that moving quickly from editing a document to managing global styles is a common flow that we risk adding a lot of friction to.

[jarekmorawski]

I understand the confusion that exists today, but I also believe that moving quickly from editing a document to managing global styles is a common flow that we risk adding a lot of friction to.

Imagine less savvy users who don't know the editor's UI very well yet. Looking for specific settings, they may click around, not knowing what each button does. It may startle them if clicking the Styles button will suddenly change the context and interrupt their workflow, especially when all other buttons in the toolbar open and close panels and do not impact the rest of the UI.

[supernovia]

My work is in interacting with users and processing feedback. I love that we're surfacing styles in a much clearer, dedicated way. I wouldn't remove the existing icon, though.

It may startle them if clicking the Styles button will suddenly change the context and interrupt their workflow, especially when all other buttons in the toolbar open and close panels and do not impact the rest of the UI.

My sense here is that while a few users might startle once, frequent users will experience an ongoing hassle with extra clicks, not to mention the frustration of having their tools moved around.

About concerns of duplication and clutter: as long as we're not maintaing two different style features, my guess is that most people who use the site editor extensively would prefer quick access where they need it. Shortcuts are popular for a reason.

Could we connect the old icon to the new styles experience? That would surface styles for new users while respecting the needs of savvy users.

[richtabor]

Could we connect the old icon to the new styles experience? That would surface styles for new users while respecting the needs of savvy users.

Is there any reason not to do this?

[andrewserong]

Could we connect the old icon to the new styles experience? That would surface styles for new users while respecting the needs of savvy users.

Is there any reason not to do this?

At the very least, this sounds worth trying in a draft PR so we can have a play with it and get a sense for how it might feel?

[stokesman]

Conversely, if I'm editing my site's global styles, I might want to slip back into the editor to tweak the current template, or fiddle with an individual block's styles.

I agree it seems ideal to have low-friction way of supporting this. Something that might work for that is having the canvas be made editable while still in the top level view. Besides this use case, more generally it could be nice to facilitate jumping around multiple pages or templates to make small edits. This seems to be much like what you suggested in your comment just that I don’t see that the canvas would have to be zoomed out. Zoom out as an option seems fine and would be available in the top toolbar given the canvas is made editable. I could be speculating too much for now but it also seems like editing from the top level could work a bit like Distraction Free where the editor UI hides if the canvas isn’t hovered as a way to quickly preview the canvas again.

[jameskoster]

Attaching a mockup to be sure the idea is fully captured:

• While editing a document, clicking the Styles button will 'zoom out' to the dedicated Styles section, while keeping the document visible in the preview frame.
• Clicking the preview frame would return the user to the document they were editing before.

If discoverability of the second part is a concern, we might invoke a Notice for this particular flow:

[metabreakr]

@annezazu I admit that I haven't read through the entire thread here (got some catching up to do), nor the process that came to moving global styles, though I'd like to advocate for myself (and my fellow designers) that adding another layer of findability/accessibility/extra clicks for global styles could be a hindrance for those clicking on that button daily and very often.

Just getting to "Additional CSS" takes too many clicks, but if this change is settled on, please at least expose that alongside typography, colors, etc. 🙏

[ramonjd]

I'm seeing "Additional CSS" at the bottom of the global styles UI, beneath block styles:

Is that prominent enough?

[annezazu]

Agreed with @ramonjd here. I don't think we need to make it more prominent than this!

[metabreakr]

@annezazu I'm not see Additional CSS in the changes from here: #66376 (comment)

I mean, so long as it's easy to access and not buried under too many ⋮ dots or chevrons, then I'm happy either way.

[annezazu]

Renaming this issue as it's becoming clear that at this point it isn't likely to remove the full styles experience from the editor itself. Instead, the approach is likely going to be one where the Styles interface is accessible from both the top level option and, in some way, within the Editor itself. This is partially to accommodate block themers who will want easy access while working on a template. This matches a similar experience as accessing all patterns within the editor and within the dedicated Patterns section at the top level.

With that said, we do need to figure out a better UX to communicate the global nature of the Styles interface as we don't want to end up in a situation where folks think the Styles interface in the editor is just for the template they are looking at whereas the Styles interface at the top level is for the entire site.

[tellthemachines]

Renaming this issue as it's becoming clear that at this point it isn't likely to remove the full styles experience from the editor itself. Instead, the approach is likely going to be one where the Styles interface is accessible from both the top level option and, in some way, within the Editor itself. This is partially to accommodate block themers who will want easy access while working on a template.

Could we provide that easy access by making Styles in the left hand side pop open when clicking a "Styles" button from the editor canvas, and make it show whatever template is being edited in its preview? Or do themers need to keep global styles open while actually editing the canvas?

[annezazu]

The feedback I've been hearing is that themers will want to make changes while actually editing the canvas and that this would take them out of that, even with the "apply globally" option for styling blocks individually.

An off the wall idea might be to do what you describe and, for themers, add in styling in the editor to the Create Block theme. I am concerned about the confusion duplicate styles sections is going to have.

[ramonjd]

The feedback I've been hearing is that themers will want to make changes while actually editing the canvas and that this would take them out of that, even with the "apply globally" option for styling blocks individually.

We could go in the other direction and think about how we could improve the existing global styles UX.

Some of my own off-the-wall thoughts:

• Remove the vagueness. Refer specifically to "Site styles" rather than "Styles".
• Block canvas interactivity when the Site Styles™ panel is open, or better, enter zoom mode. The point here is to emphasise that the entire page's styles are being affected, not whatever block or template the user has selected.
• I might give the designers heart palpitations here, but what about when global styles is activated, have an option to preview other templates so that it's clear that the styles affect all of them.

[richtabor]

I think this needs much more design/big-picture thinking before moving forward.

[richtabor]

that adding another layer of findability/accessibility/extra clicks for global styles could be a hindrance for those clicking on that button daily and very often.

Agreed. I'm hesitant to remove the control as well, rather than requiring backing out of the editor and to "Styles" to get to the same view. And then in-and-out to manage the styles/navigate the site. It seems quite heavy/disorienting—even if the styles toggle stays in the header and opens back to the site editor styles panel.

CleanShot.2024-11-13.at.19.12.18.mp4

[tellthemachines]

Just thinking out loud here.

On one hand, having the global styles sidebar where it currently is beside the editing canvas is confusing for new/occasional users and can easily lead to mistakes being made due to confusing global with local styles.

On the other, that same location is very convenient for site/theme developers to build and style their templates. There are also good arguments for making some of the controls, such as additional CSS, visible by default.

Can we perhaps make it a preference, or an option like "Top toolbar" under "View", that can be toggled on by users (and saved in the browser for ease of use), but is off by default for everyone else? That would substantially reduce the chance of user accident while preserving the smooth flow for developers.

[afercia]

I'm seeing "Additional CSS" at the bottom of the global styles UI, beneath block styles:
Is that prominent enough?

@ramonjd @annezazu it's worth reminding Additional CSS appeers at the bottom of the panel only when there's already some custom CSS set. By default, it doesn't show there. It was implemetned in #47266 and, to me, it;s source of confusion for users. See #66476 where I'm proposing to make it always visible.

[afercia]

I thought #66376 / #65619 aimed to move the Styles panel to the navigation top level. Instead, I see there are now two Styles panels. I'm not sure I understand how having _two places for global styles in the UI is any helpful to reduce confusion for users.

Quoting a couple of the main goals of moving the Styles panle to the toop level navigation panel summarized by @jasmussen on #66376 (comment)

• 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

My take was that a new concept was going to be introduced: anything that is 'global' is now in the navigation panel. That makes totally sense to me and I'm not sure how keeping the 'local' in-canvas Styles panel helps making 'clearer where and how to style your site, globally'.

[jartes]

One thing that @ktyfuller604 brought up is that the Reset styles button is not in the top-level Styles option.

Is this something we are considering as well? We are adding Styles revisions to the top-level menu, so it could be something to consider as well.

I was thinking 1) adding a trash icon next to the Preview link or 2) adding it as the last option below the Additional CSS button:

[ramonjd]

Reset styles button is not in the top-level Styles option.
2) adding it as the last option below the Additional CSS button

Sounds reasonable to me.

Of the two options, if folks think a reset functionality should be included on this view, I think the second would fit best into the panel. The reason is there's more room to be explicit about what is happening versus a lone trash icon.