Styles: Relocate the revisions toggle

[afercia]

Description

Splitting this out from #63243

The global styles panel header contains 3 additional buttons besides the X close button:

• Style Book
• Revisions
• More

In #63243 it was pointed out that this buttons shouldn't be placed in the panel header in teh first place.

• It's a pretty unique case. The only other case I can think of it's the 'Pin / Unpin' button in the Plugins panel.
• These buttons take way more horizontal space when the showIconLabels preference is true. The length of the text is unpredictable as translations may provide strings that are way longer than the English ones. Fix Global styles panel header buttons text overlap for 'Show button text labels' #63243 tries to improve things but there may still be cases where the buttons visibel text overlaps.
• The original design didn't take into account the showIconLabels preference.
• Ideally, all panel heaaders should only contain the panel Title and the X close button. Any other content should be moved to a 'sub-header' as proposed on Add heading title and optional sub-header to all panels #63251

It was also noted that the Revisions toggle placement is inconsistent with other parts of the UI:

While in the Site editor navigation panel it's placed at the bottom of the Styles panel::

I'd tend to agree with @jameskoster comment:

The revisions button invokes a drilldown, which feels strange given the access point (panel header toggle button).

As such, I'd like to propose to consider relocating this button at the bottom of the Global styles panel:

• For better consistency.
• As a temporary improvement to mitigate the text overlap issue. A more future-proof option would certainly be to not place any additional control in the panel headers.

Cc @WordPress/gutenberg-design
@t-hamano @aaronrobertshaw

Step-by-step reproduction instructions

• Go to the Site editor > Design > Styles (in the left navigation panel)
• Observe the Revisions toggle button is at the bottom of the panel.
• Go to the Site editor > Styles (the Global Styles panel)
• Observe the Revisions toggle button is in the panel's header.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

[jameskoster]

For now it could be as simple as:

[t-hamano]

To me, the following description seems redundant, because the same description is also included on the next screen:

What do you think about just displaying the button like this:

[afercia]

Personally, I would be in favor of removing the descriptions and placing the navigation buttons grouped together.
Cc @WordPress/gutenberg-design

[jameskoster]

I wouldn't object, but feels like a detail to discuss separately.

[afercia]

I tend to think the best path forward here is to tackle this issue together with #66333.
To me, it's important to consider these two proposed changes holistically to better evaluate the overall change in the design and user experience.

To recap:

• Remove the Revisions icon button from the panel header.
• Add a 'Styles revisions' navigation button at the bottom of the panel. This button should appear only when there are revisions.
• Remove the 'Additional CSS' menu item from the ellipsis 'More' menu.
• Make the 'Additional CSS' navigation button in the panel always visible, also when there's no custom CSS set. This basically reverts Move Additional CSS from the top-level Global Styles sidebar #47266
• Remove the descriptions for 'Blocks' and 'Additional CSS'.

Re: the navigation button styling: for now, I'd propose to use the built-in variants of the ItemGroup component, which is the component already in use to group many nqvigational controls in the settings panel. Specifically, I'd use the variants isBordered isSeparated.

I wouldn't object to use other variants of the component. However, I think it's important to use built-in variants and avoid ad-hoc implementation and / or CSS overrides. If a different styling is desired, I'd strongly recommend to create a new issue to consider to introduce a new variant.

Screenshot before and after:

[jameskoster]

There is a lot of high level design work around the Styles panel happening in #66376, so I would lean towards keeping changes focused on functionality for now.

[richtabor]

There is a lot of high level design work around the Styles panel happening in #66376, so I would lean towards keeping changes focused on functionality for now.

Yes, let's not do design work on this panel here. One-off changes aren't going to improve the experience—it's going to continue making WordPress feel more and more fragmented and difficult to understand.

[afercia]

feel more and more fragmented

We may have different perceptions. To me, the editor is already largely fragmented and the current design is far from ideal.
Specifically to the various 'navigation buttons' in the styles panel, they are all inconsistent. See #66448. That is a result of the design direction that has been implemetned so far.

There is a lot of high level design work around the Styles panel happening in #66376,

It all depends on when the redesign proposed in #66376 will land in WordPress. If it will take long time and it won't make it for the next release, I vote for moving on with this improvement for now.

[afercia]

let's not do design work on this panel here.

@jameskoster @richtabor I carefully read all the ongoing discussion on #66376 and I'm not sure I understand how that relates to the content of the Syles panel.

Basically, so far, #66376 is about moving the entire Styles panel inside the 'Content frame' of the site view. It doesn't touch the content of the Styles panel.

Also, #66376 removes the 'Revisions' toggle from the panel header, which is the same direction this issue and its related PR are taking.

This issue and the proposed PR #66476 aim to improve the content of the Styles panel. Overall, I don't see the ongoing exploration in #66376 as a blocker for #66476.

Can you please share whether you have other concerns about improving the content of the panel? Thanks.

[aaronrobertshaw]

Basically, so far, #66376 is about moving the entire Styles panel inside the 'Content frame' of the site view. It doesn't touch the content of the Styles panel.

That wasn't my read of #66376, @afercia. There are a few comments discussing moving the initial screen of the global styles panel into the main site editor navigation. It stands to reason that if that path were taken we wouldn't duplicate the revisions button, instead we'd use the button that is already there, as shown in this issue's description.

As this process unfolds, the panel will evolve further. All the lessons learned can then be brought back to the Global Styles panel within the editor.

This demonstrates the in-flux nature of the styles panel at the moment and highlights the wisdom in keeping changes limited in scope and to functionality if possible. The energy that would go into re-work can otherwise be invested into the final result.

There was also a design update on #66376 overnight that would address a lot of the discussion here.

I'd expect most of that to be worked on either in #65619 or follow-ups to it.

That's just how things are shaping up in my view. Hopefully, it helps clarify that we're all working to the same end goal, improving usability.

[afercia]

There was also a #66376 (comment) on #66376 overnight that would address a lot of the discussion here.

@aaronrobertshaw thanks for pointing that out. That changes a lot. I see the discussion on #66376 is now evolving from a '1:1 transplant of the existing global styles sidebar into site view' into a complete rethinking of the Styles panel as well.

I have no strong opinions. The PR for this issue #66476 may be considered a temporary improvement. It's relatively small and self-contained, I don't think it would cause any overhead. It's also going in the same direction as also in #66376 the Revisions and Additional CSS are always visible in the main panel. I'll leave it to you all.

[aaronrobertshaw]

into a complete rethinking of the Styles panel as well.

I think it was always heading that way. The question, as always, is how we get there. In this case, we might need to make more of a jump than normal.

The PR for this issue #66476 may be considered a temporary improvement

I'll comment over on that issue shortly.

This is just my view but I'm not convinced on #66476. You've raised the consistency argument across a number of related issues and PRs here. That PR just moves the inconsistency somewhere else.

Locating the revisions at the bottom of the panel matching the styles screen of the site editor would achieve that consistency. The discussion around changing existing UI elements into an item group etc is also expanding the scope beyond what's advertised.

I agree that it is the "in the same direction" but it's still making multiple changes when we should only make one. I know you're a huge advocate for users, so you'll probably also appreciate we should avoid making users adjust twice, to successive UI changes.

As there is active work on #66376, it shouldn't be too long before the dust settles and we can properly address all the concerns we share. This is just my two cents but it appears we don't have a consensus so might need to take a little time before pushing too far ahead.

[afercia]

I think it was always heading that way.

My understanding is that the initial scope of #66376 wasn't a complete refactoring. The PR initial description clearly states that:

For the moment, the visual mockup above assumes a 1:1 transplant of the existing global styles sidebar into site view.

Only later the conversation evolved towards a broader rethinking of the Styles panel. This doesn't change the value of the points mentioned in this discussion. It's just to be accurate and provide correct context to the ones who may read this conversation in the future.

I know you're a huge advocate for users, so you'll probably also appreciate we should avoid making users adjust twice, to successive UI changes.

Absolutely. I would appreciate that principle to be applied to all future UI changes. I would have appreciated that principle to be applied also to all the past UI changes in the last 7 years but that's often not been the case.