Styles panel: Rearrange the Revisions and Additional CSS toggles #66476
Conversation
afercia
added
[Focus] Accessibility (a11y)
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: -411 B (-0.02%) Total Size: 1.83 MB
ℹ️ View Unchanged
|
|
Thank you! I have nothing against the move, and it does decrease the icon overload. I've smoke tested revisions/stylebook in the editor and it works well. Since this affects the UI mainly, I'll lean on the advice of @jameskoster and co, since they have a better idea of how it would fit within any upcoming design changes.
+1 |
|
I think I know, more or less, why the tests are failing on this PR as the 'Revisions' button in the panel header has been removed. However, the Output of the failing test on trunk: |
I'm not opposed to that but then the styling should be consistend for all the similar navigation buttons. I created #66448 to address that. |
|
To avoid multiple changes in quick succession should we wait for a final design in #66376? |
|
Flaky tests detected in 875bd10. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12234507829
|
@jameskoster as I mentioned in #66307 (comment) I'm not sure I understand why #66376 is a blocker for this PR. Basically, #66376 aims to move the entire Styles panel but it doesn't touch its content. Instead, this PR is about the Styles panel content. |
|
Checking out this PR and I see the new buttons are in a sort of segmented button with all borders on. This kinda keeps the problems around - what are these buttons and why are they so separated and special. In fact the previous way of having a description and a simple text + chevron (no border) is the right choice for this drill down panel. Can we try the suggestion from @t-hamano and @jameskoster - have explanatory label (that always shows) and normal link-to buttons (text and chevron)? |
|
@draganescu thanks for your feedback.
Anyways, I'll gladly change to one of the built-in styles please just tell me which one to use. Please consider the same styling should be used for all the other occurrences detailed on #66448
I'm not sure I understand the point about labels. These buttons do have visible labels. Did you mean the descriptions perhaps? Those must be removed as they are aunique ad-hoc, inconsistent pattern. Tehy're duplicated in the sub-panels and they just add clutter.
I'm not comfortable with this kind of tone. Saying |
|
In the screenshot below: these are the available built-in styles, respectively:
For completeness, there is also an |
afercia
force-pushed
the
fix/relocate-styles-panel-buttons
branch
from
46b623b to
7643334
Compare
|
Latest commit tries the
|
Thanks for iterating @afercia - I think the style I was reffering to is
I don't think consistency should trump any other objective. The descriptions are there because the buttons "Blocks", "Additional CSS" and "Styles revisions" are disconnected from the above options, although in the same functional space "Styling". For a well versed user they may sound redundant but the role of these descriptions is discovery. And since your PR helps discovery by moving additional css and revisions into the main display then we should also leave the descriptions in place, so at the very least the buttons make sense in this context. Previously, by having them in secondary areas (the dot menu and the extra panel buttons) the intent was to highlight that they're "secondary", special utility. You'd have to know what you want to access them. Here, bringing them front and center we require the descriptions so that users have the benefit of learning what these things do before venturing in. They're deffinitely not clutter. |
I kindly disagree. As I mentioned, that's a unique, inconsistent pattern. I can't support this kind of design direction as I think consistency is key and all that text adds unnecessary cognitive load, so that's also related to usability and accessibility. Furthermore: descriptions should be placed after the object they refer to and never before. Also, descriptions should be programmatically associated to the object they refer to by the means of an About discoverability: these descriptions are used also in the sub-panels. For example, as an usrer, if I want to discover what 'Additional CSS' is I can just click on it and get the panel with the description. Overall, I think the descriptions in the main panel are just redundant and inconsistent and their design is arguable. I vote for removing them. |
To me, as I already mentioned, all the navigation buttons in the styles panel and its sub-pabels should look the same. At the moment, they are largely inconsistent, see #66448 Controls that have the same functionality should use the same styling. This is key to allow users to identify, predict, and understand what these controls are. To me, this point sounds so obvious that it shouldn't even warrant discussing it. I'm not sure the |
|
Just reminding everyone this PR also fixes and existing bug:
That should be fixed, either by this PR or a new one. |
There was a problem hiding this comment.
I'm in favor of this. It also seems like an iteration that shouldn’t much impact further design efforts in #66376 but I could be missing something. One thing I noticed while testing—though it’s probably unrelated to any changes here—is that when drilling down to Revisions or Blocks, the scroll position seems like it should reset to the top. It seems to do that a shorter viewport heights, but I'm seeing it around 680px.
styles-sidebar-drilldown-scroll-position.mp4
|
I'm a little late to this party but appreciate the discussion all around 👍 My vote would be to hold off on this PR until the dust settles on #66376. As I noted over on the original issue, the consistency argument has been raised a few times here and this proposed relocation swaps one inconsistency for another. The new location would still be inconsistent with the Styles panel in the site editor. There is active work happening on the broader issue for the Style Book via #66376. The consistency argument can also be applied to limiting changes to the UI. We can avoid making users adapt to multiple successive UI updates, so in my view it doesn't cost us a lot here to be patient and skip one more small paper cut to users. This is likely part of the reasoning behind @jameskoster's earlier comment. |
|
Fair enough, i will set this PR on hold. If #66376 doesn't make it for the next WordPress release I would suggest to bring back to life this PR and have at least this partial improvement in the release. |
There was a problem hiding this comment.
This PR seems to be working as expected.
New Styles screen:
Global styles sidebar:
@WordPress/gutenberg-design I'd be happy to receive any feedback on the design.
Thinking that the 'Styles revisions' button should now be shown conditionally;
With the new Styles panel, there's already a way to access Revisions. It's the 'Last modified' button in the navigation panel.
It may not need to be addressed in this PR, but does anyone know if there is a reason the revision button had to be in the footer? Perhaps in a follow-up PR we could move it inside the new Styles panel?
I'd agree that is something to consider. Now that the Styles open in the 'in-the-middle-panel' (sorry I don't remember the name for this design pattern) having the revisions button in the footer makes less sense? |
|
Couple of thoughts on the design:
I think it's an oversight. I agree it should move to the content panel. |
It's a historical thing - it was also previously used for templates, pattern et. al, which, back then, were not presented in data views. Agree it'd have a happy home in the content panel. 👍🏻 |
In this regard, does it make sense to place the "Additional CSS" menu at the end? |
|
Thanks all for your feedback. I'd lean towards making two changes in this PR, for now:
Rough screenshot:
|
|
Re: the other points:
I have no strong opinions but I'd like to see consistency with all the other navigational items with a chevron used elsewhere, for example in the right Styles panel.
That's the whole point of #66333. Why this feature should be hidden, buried down into the ellipsis menu in the first place? It's an editor feature, no different from other features. To me, the ellipsis menu is just a perfect way to hide features from users and make them little discoverable.
I'd totally agree that all drilldowns navigational items should use a consistent pattern to communicate they open a sub-panel. I'm not sure why the main Styles items (Typography, Colors, Background...) don't. That's already on trunk singe long time though. I'd be in favor of using chevron icons there too, but please not just on hover. Screenshot of current trunk inconsistencies:
|
afercia
force-pushed
the
fix/relocate-styles-panel-buttons
branch
from
1ead3d8 to
3e47bf2
Compare
|
The 'Revisions' button in the Navigation panel used to open the Revisions by switching the editor to the edit view and by opening the general sidebar on the right. Now that we're trying to move the Revisions button into the Styles content panel, I think it should behave like all the other navigation items there and open the Revisions in the content panel drilldown.
To my understanding, all the logic that was used to switch the editor to the edit view, reset preferences like Distraction free etc. to show the Revisions in the right sidebar isn't needed any longer. I may be missing something though so I'd appreciate a review from someone more familiar than me with revisions. Cc'ing @ramonjd who worked on #67180 🙏🏻 Note: Animated GIF to illustrate the new behavior:
|
Thanks for the ping. I've bee exploring exactly this over in #67660
If we move revisions into the content panel in "view" mode permanently, I agree: it would simplify a lot of the canvas view modes and route juggling. |
I agree which is why I think we should remove the stroke. It would be best to pick one of the two existing approaches; no strokes at all, or strokes between each item and around the container. The current state on this PR introduces yet another style treatment and adds to the inconsistencies. I lean towards no strokes, because the 'contained' style feels better suited when items in the list are directly related to one another, e.g. managing shadow styles or font size presets.
I know there are often disagreements about this but it's about managing prominence. Adding custom css is a relatively niche feature, and for folks who don't know how to write css it's practically useless. Placing it in the ellipsis menu feels appropriate according to how relatively useful the feature is. All that said, if @t-hamano feels strongly it should be included in the main panel I'm happy to defer :)
Yes I think so. The icon can help folks recognise the feature which feels important if we're going to move access to it.
Agree. |
|
@jameskoster thanks for your feedback.
A while ago I created #66448 which is specifically about all these navigational items inconsistencies. Maybe it's worth moving the strokes / borders considerations there?
not sure we have data to confirm that. And I'd argue the consideration that is a relatively niche feature may be valid for other features as well, e.g. Background or Shadows. To me, admittedly based on anecdotal feedback, one of the struggles users often face in the editor is that they can't easily find some features. Keeping burying features in the ellipsis menu isn't great for discoverability. Additionally, the ellipsis menu pattern has inherent problems in terms of accessibility (I reported many times the ellipsis icon is barely visible, see #61909) and in terms of its usage as it started to be a 'More' menu but now it is used everywhere, with different purposes and to show different tools. Overall, I'd like to see the usage of ellipsis menu being reduced rather than increased. |
Yes we should discuss and refine finer details separately, and ideally document them to avoid repeating conversations over and over :D That said I don't understand why we'd want to introduce another pattern here. Why not use an existing one? Just to be clear, I'm referring to the screenshot below, specifically the strokes between each item, which is totally unique so far as I can see: 
|
Well, it's not another pattern. It's already used in many of the other panels, as detailed in #66448. Admittedly, it's used inconsistently. That said, to me 'Blocks', 'Additional CSS' and 'Revisions' are different concepts / features and they should be separated. |
I agree. There are currently no
Opinions may vary on the order, but the Advanced panel in the block sidebar is placed at the very end. In the Customizer, Additional CSS is placed at the very end. Considering these things, I personally feel it would be natural to place Additional CSS in the new Styles panel at the very end as well. However, since only the revision menu has icons, placing Additional CSS at the very end can look visually unnatural. |
I'd bring in two considerations:
Overall, I think using the |
Fixes #66307
Fixes #66333
What?
The way to access Styles revisions and Additional CSS is inconsistent and little discoverable, especially for the Additional CSS. These features live in sub-panels of the Styles 'drill-down' menu. Other sub-panels use standard navigation buttons with a chevron icon to access the sub-panels.
For more details, please refer to the conversations on #66307
and #66333.
Why?
For consistency and better user experiences, accessing the sub-panels of the Styles drill-down menu should use a consistent pattern. Features should be well discoverable and not buried down into an ellipsis menu.
How?
Additionally: Fixes a bug where accessing the Additional CSS from the navigation button at the bottom of the Styles panel
did not switch back the canvas to the default view when the Style Book was enabled. See #66333 (comment)
Testing Instructions
revisionand titleCustom Stylesfrom the database.Edit:
Testing Instructions for Keyboard
Screenshots or screencast
Before and after: