-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add: Styles section to the browse mode sidebar. #49014
Add: Styles section to the browse mode sidebar. #49014
Conversation
Size Change: +373 B (0%) Total Size: 1.34 MB
ℹ️ View Unchanged
|
0686ba8
to
6a4a301
Compare
Flaky tests detected in dea59c1. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4514465701
|
Thanks for the PR! Here's a quick GIF showing the new "Styles" item added to the site editor sidebar, and how it allows you to quickly pick a style variation: This is working well as it's showing high level global actions, which feel appropriate in this receded view, whereas intricate editing should go in the fullscreen editor. It even feels like this section helps contextualize what this new view is all about, even recontextualizing the Navigation screen: it's all high level. I'd love to get this in soon, even if we don't get it in 6.2. I'd love to hear @jameskoster and @SaxonF's thoughts on this. Seems like there are a couple of metrics, styles, active states, focus states and such for the style variations as well. Here's one doodle: Note by the way we need an edit button just like on templates. This edit button should deep-link you into the fullscreen editor with the global styles open. I think |
I love this PR because it surfaces the styles feature so well, and it also makes applying them a better experience. The problem I have with it is that it makes the sidebar a mix of settings and navigation which is a bit confusing. |
Can you clarify what you mean with this? I see the ability to surface contextual controls in drilldown detail pages as a key value of the site editor going forward, and I could see us surfacing the most common controls contextually in these places, such as "posts per page" on the Index template, or even page template: |
That is different @jasmussen and correct, because in your screenshot you already are in a new context and the sidebar is contextually adapting, showing new things. But initially, as this PR stands, we have navigation, templates, template parts, three actions which result in a list of things, click on one and you open something on the right side. And now we add the fourth which is different, it is a setting - the style to apply. The selected style does not open on the right side, it's globally applying to the whole website. I think I saw some layout which included a sidebar menu item named "Design" and from there you can tweak design settings, such as style? Nevertheless, I think we can add them as they're implemented here and reiterate on structuring the menu and interaction better later. |
I agree, this a compelling PR. In addition to the button states Joen mentioned there are a couple other issues: zindex The iframes in the thumbs are overlapping the panel header. Animation animation.mp4I'm not sure we can do anything about that but I wanted to note it. Not necessarily blockers to this PR, but I think we should pay a little more design attention to:
My worry with this approach is that the full-screen editor still feels like its optimised for template / content editing. So if you close the global styles panel and begin playing with some blocks, it could subsequently feel a bit unnatural to see the Styles panel when you click the W. A couple of options to consider there:
I suppose if we can get the edit button in there and see how it feels, that can help guide us. |
Those are excellent questions to ask, Jay, and they might be good to extract into a separate issue, because it's good to solve. We have all the pieces: a receced high level view, a low level technical view, a style book. But the questions emerging is: how much, if any, should you flow from one section into another? I.e. should you be able to go from styles to template editing, or should you have to go "back" before doing that? To an extent these lines are already somewhat blurred with templates and content being mixed, so it's good to think about, high level. |
c09c220
to
dea59c1
Compare
Hi @jameskoster, @jasmussen this PR was updated, and the z-index and border issues were fixed. |
Nice one. This is coming along well. Outside of any feedback others might have (cc: @SaxonF), from my pov the main thing missing here is a link to edit the full global styles. A deep link to the fullscreen editor with the global styles inspector open. And I wonder: should that be the edit link, or perhaps this one? |
dea59c1
to
30670ce
Compare
Thank you for the feedback @jasmussen I added a button with the brush icon to switch to edit mode with the global styles sidebar open. |
I'm seeing the icon and it works as expected. I do have some questions around the general experience though:
Switching variations in the dark material is a pretty nice feature on its own, I wonder if we should take some more time on the flows in/out of granular style editing, perhaps in a separate issue/PR? |
Yes, I think there definitely is. But I also think that's a larger effort we can visualize separately. If we think of the "site view" (dark material nav on the left, preview on the right) as a mode of the single app that is the site editor, and "edit view" (fullscreen editor) as another mode, is there a similar mode for "style view"? Ultimately you'll flow in and out of these modes in a few different ways. To an extent, the fact that we zoom out the canvas in browse styles view, is an early attempt at such a mode. Speaking of, should we explore a similar zoom out for this "browse styles" in the site view?
Without getting too technical and just discussing the heuristic at a high level, I wonder if we could do this: If the styles inspector is open, Back button takes you to Design > Styles. If the regular inspector is open, or both inspectors are closed, the Back button takes you to Design. What do you think? |
@jasmussen, the button should be visible I guess maybe you need to pull and rebuild to see the changes?
This seems like an ok solution; if we agree on it, I can look into how to make it happen. |
I think it's worth exploring, yes. Maybe the canvas is permanently zoomed out when the Styles panel is open? And perhaps clicking a block on the canvas takes you to that block in the Styles panel (I think we had an issue for that somewhere).
Again, this seems worthy of a dedicated exploration. Zooming out alone might not be all that useful, but zooming out and showing a mosaic of 3-4 other templates could be very handy.
Using panel visibility seems sensible and likely a good place to start, but I'm not sure how intuitive it would be in practise. Just because a panel is open, that doesn't mean you're actively using it. This is likely one of those interactions that needs to be felt out. If it's easy to try in the PR then I wouldn't object. But these are both quite tricky issues, which is why I think it might be worth tackling them separately after some further design exploration. Not a strong feeling though :) |
I got it working now. Nice: On observing this, yeah let's use the regular edit button, but thanks for trying the brush.
Agreed.
I wonder if this panel visibility could be the context that triggers the "mode" shift? That is:
In my mind, each of these contexts, if their modes are designed right, could set the context for what you're looking at, and thus the context for what you see when you press "Back". This kind of context shifting might be worth thinking about regardless, if you are to be able to flow from Pages > Add New and into Styles, etc. Worth an exploration, sure, but it might allow this PR to move forward even if the GS panel isn't the biggest context shift yet? |
Yes that's roughly how it works in my mind. There's a primary thing you're editing:
And the primary entity determines which panel is revealed when you click the W. But for that to feel intuitive, the primary entity needs to feel obvious and apparent. As discussed, the issue is that even with the Styles panel open, it doesn't feel primary which is why the W behavior might feel a little unnatural. But yes, if we're committed to addressing that then we can include it in this PR. |
We would need to be very careful with this behaviour because of how we treat the relationship between sidebar/admin and frame. I'd mostly expect sidebar/admin to dictate what's in frame/editor and rarely the other way around as its a little more predictable. e.g. You might start editing a page, globally style something, then want to switch pages. If you're taken to styles instead of back to where your original entry point was you'd feel quite lost as there isn't anything anchoring the navigation. |
Yep, I share this concern. But I do wonder if we can make a substantial enough visual shift when shifting between inspector and GS tabs, that this could help with that context? Something to explore separately from this branch, IMO. |
FWIW this is why I've concluded in the past that the W should open to the root of the design section, at least in the short term, because it's the only behaviour that will always feel predictable. To be clear I'm not saying we should definitely do that, because there are trade-offs. But it might be worth trying separately, particularly after the Command Center (#49330) is merged and switching entities becomes a lot easier. |
30670ce
to
f448186
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took this for a spin. Here's a GIF showing the new section, switching style variations, and going to edit the full global styles:
Small detail, still seeing the brush icon, let's replace that with the Edit icon.
Giving tentative approval to this one, but would appreciate sanity checks. CC: @richtabor @jameskoster @SaxonF @mtias. I think we should land it, including the Edit button to go to the full global styles, for a few reasons:
- Global styles as is, is very hidden inside the fullscreen editor. By adding a deep-link, we surface it with more clarity.
- The site editor is meant to conceptually split configuration in high level controls in Site View (dark material on the left, preview on the right) and low level granular configuration in Edit View (fullscreen editor). By landing this first step, it lets us move forward in the plugin.
And there are a few things we need to move forward with. As relates to styles:
- Explore also showing font pairs and color harmonies as high level controls in the Site View
- Explore letting the global styles sidebar toggle a more visual shift in the fullscreen editor, to make it clear this is not like the inspector, perhaps make it be more of a modal experience.
But those explorations don't preclude landing this in the mean time, and by landing this, global styles will be more discoverable again.
f448186
to
015bf99
Compare
015bf99
to
6d681ca
Compare
It's nice to see this merged 👍 |
This PR adds a style item to the browse mode sidebar following the design proposed at https://make.wordpress.org/design/2023/02/15/design-share-jan-30-feb-10/.
This is the first step in the addition of styles to the browse mode sidebar, the edit action to customize the styles instead of just selecting a style variation is not added yet.
Details
The style variations UI was not available as a standalone component we could use, there was a single component that included the global styles sidebar navigation effects like opening the zoomed out mode and rendering the the UI. We are extracting the rendering part that is now used by the browse mode sidebar and by the existing global styles sidebar.
The we use the newly extracted component the add a new menu item in the browse mode sidebar.
Screeshots
Testing
Verify that changing the style variations in the browse mode sidebar and the existing global styles sidebar is possible.