-
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
Set Style sidebar panel initialOpen to false #24073
Conversation
This has been explicitly changed to true in a previous PR #20617 cc @pento @jasmussen |
Size Change: 0 B Total Size: 1.15 MB ℹ️ View Unchanged
|
Ah, I see. I still stand by the reason behind the change back. I'd appreciate feedback from @pento and @jasmussen for sure :) |
It's kinda weird that Styles is even in the inspector in the first place. Every other control I can think of only appears in either the toolbar or the inspector. But Styles appears in both. If I recall correctly (and correct me if I'm wrong), Styles was added to the inspector to make it more discoverable. But the inspector is supposed to be for secondary controls. It's where controls are supposed to be intentionally hidden to a degree. To me at least, that seems to indicate that the real problem is that the purpose of the block/style switcher in the toolbar is not as obvious as it should be. The accessibility team has already pointed out some of the issues with the current switcher design. If the block/style switcher's purpose was more obvious, we wouldn't need the Styles panel in the inspector at all. |
As for a more immediate action, though, I'm fine with this PR. |
I agree that there appears to be too much going on in the sidebar in the screenshots of the Image block, but I don't think changing the Take the Quote block, for example: Starting with the Styles panel closed makes the sidebar appear underutilised, there's a huge amount of blank space not being used. Or looking at Jetpack's Map block: Closing the Styles panel improves things a little, but there's still a lot going on. I suspect the overload stems from having multiple panels open, one after the other. I'm wondering if a better approach might be to have a clearer boundary between panels. Eg, (Disclaimer: this particular style obviously doesn't fit as a standalone change, but I think it illustrates the idea.) |
Perhaps an optimal solution would be that the Styles panel remembers its open/closed state editor-wide (like how the Document panels do)? So if a use closes the Styles panel on one block, its closed throughout the editor. Is that possible? |
I don't think its a matter of how much white-space is available, but rather how much cognitive load is present one way or the other. With a block such as the Quote block its not a big deal having it open - as there are no other controls - but for other blocks, even the JetPack Map block, its quickly an intensive experience. Also, if JetPack - or even another third party plugin - adds more map styles (which isn't out of the question), the styles will keep pushing the others controls out of the way, and keep adding to the cognitive load. |
I think this is a good observation. However I disagree with changing it to be collapsed by default. Part of the purpose of the G2 design revamp was exactly that, to reduce, simplify, optimize, combine and lighten this very cognitive load, editor-wide. We did not get to the sidebar with those efforts. But that doesn't mean we shouldn't. There are many many efforts that can be taken to simplify things here, including finding a better grid system for controls inside, reducing borders where possible, and making labels consistent and in the same spot, add contextuality where possible. Many of my recent PRs have taken steps towards that, including by reducing the shades of gray, and by emerging steps for a grid system. I hope to continue that work on a per-control basis, work with @ItsJonQ to improve things there. This is a much harder process than simply collapsing by default. But ultimately, I believe it is the better approach. By allowing things to collapse we are, to an extent, encouraging kitchen sink sidebar design. Whereas if we attack head on what makes it kitchen-sinky, we can benefit the issue at the core. In this case, I do agree that the style picker is in a bad state. For starters we've done a little work to improve it directly in the switcher: I'd love if we found a way to make this feel natural enough that it might even be in the switcher only, but I'm not confident in that. In the mean time, what are the biggest problem with the style picker display in the sidebar? To me:
All that would help. |
The style sidebar panel has been redesigned (no longer including the image preview of style in the sidepanel) quite a bit and the initial issue has been closed (#24072); want me to close this ? |
The current implementation is much better. Closing. |
Description
This PR sets the initialOpen prop to false for the Styles PanelBody which will clean up the Settings Sidebar UI and lowering cognitive overload. Closes #24072.
Screenshots
Before:
After:
Types of changes
Checklist: