Try: Remove the sidebar close button on desktop breakpoints #9784
Conversation
Why do this? Right now the sidebar close button does the same as toggling the cog from the Editor Bar. Redundant UI is usually okay in situations like these, but given the overall complexity of the top right desktop breakpoint UI already — which features both the editor bar cogs, tabs in the sidebar. By removing a single piece of UI, we keep the exact same functionality as before, but reduce the visual footprint just slightly. Thoughts? Yay or nay?
This commit does a few things: 1. It makes the panel heading the same color as the down chevron. 2. It adds a label to the font size picker, grouping it all together 3. It tightens the margins between switch and contextual help text. 4. It relaxes the margins for base controls inside panels, to make them a bit lighter. Together with #9784 it reduces the weight of panels in the sidebar.
|
This is a great exploration, and I really want it to work. In general though, I find myself clicking the
At a glance, its' not 100% clear that the cog controls the sidebar. And if the sidebar has been open for a while (or if it's open by default), I sometimes forget that the dark gray background means that button is activated — it could be read as just be an alternate button style. I do think we could get away with removing the
Part of me doesn't like that at all (it makes this seem like a popover or something?), but I do like how it links the sidebar up with the icon. 😄 |
|
I agree with everything @kjellr wrote — I want this to work, but I too use the X in almost every case. It might be force of habit at this point though… Pages' sidebar, which feels like the closest analogue for the Inspector sidebar, doesn't have an X, and I never have problems there. Admittedly in Pages by default you have the extra context of a label below…
I also think the caret might not work if you have lots of plugin icons. There aren't a ton of plugins leveraging the plugins API yet, but I expect once they do the icons could flow too far to the left, and end up above the document canvas instead of the sidebar. It's already getting close on my personal site… two or three more icons and the settings icon won't be positioned "correctly" anymore:
I was also going to suggest that maybe this could be a case for an animation, similar to the block switcher, where hovering over the icon drops an "X" into place, but after a quick try it feels too much like you're deleting the icon itself rather than closing the panel. |
|
Personally, I always use the cog in the top bar to close the sidebar, rather than the "X", so I am fine with it being removed. |
|
Super lovely feedback here. I'll let it sit for some further thoughts, but I just want to take a brief intermission and note that it's such a pleasure to see cogent, polite and intelligent discourse on a design suggestion like this. One core item of feedback so far seems to be that we all use the X all the time, therefore it's the best UI. I use it all the time too — it's the obvious button to press. But perhaps that fact is, counterintuitively, a reason to remove it? We have a plugin API that adds buttons to the top. Perhaps by removing the X we implicitly help teach how to manage plugin sidebars? Tangentially related, here's a crazy idea that aims to do the same, reduce cognitive load:
The very least I'm going to do is make sure the X in the sidebar aligns vertically with the ellipsis and the chevrons. |
|
The little chevron could work (also in the whiter presentation above), and maybe we can make the cog always be the item to the left of the ellipsis, with extra plugins going between the publish button and the cog? |
|
The white certainly makes it easier to make a chevron connector like that.
Well, we could add the chevron connector as a pseudo selector on the cog itself, that way it would always be beneath the cog and we wouldn't have to reshuffle plugin icons to make sure it was in the right place. We'd definitely want this chevron below plugin sidebars too, right? |
Maybe, but the point is that if you have enough plugins, there's going to be one living outside the sidebar boundary, where the connecting thing doesn't make sense. Also, I think this is mostly to reinforce a relationship that might not be immediately clear because the sidebar is open by default. With plugins, you are invoking them, so it's much more clear. |
I feel like if we are to have a connector, all sidebars should have them. We could limit the amount of pinned plugins to n (matching the 280px width of the sidebar) so we never run into the issue you describe? |
|
Minor: Something is bothering me about the white sidebar, maybe it's the similarity it introduces with the header toolbar but I can't really put words on it, I just don't like it a lot. |
I have the same gut reaction, only... I like it, but I don't like it. I'm pretty sure in my case it's change aversion, which means I need to sleep on it and come back to it. Can I ask you to look again tomorrow? :) |
Yeah, I think having just the one way to close the document settings sidebar will help teach users how to manage plugin sidebars.
I don't think having a caret connecting the button and sidebar is worth limiting how many plugins a user can pin. As for making the tabs-except-they-are-not-really-tabs use a white background, I am not really sure how I feel about that. At the moment, I do not really prefer one over the other. |
I think this is the core of the issue here: if you were to click the cog button and open the sidebar, you'd know that you can close it by clicking that same button. But when it's open by default, there's no indication that you'd click that icon to close it. If we went with a chevron, I agree that it makes sense to show on all plugins as well as the settings sidebar. That could definitely get difficult if there are a lot of plugins installed. I kind of went on a side-quest with this and began thinking about how to more closely associate the toolbar toggles with the sidebar itself. I tried removing the buttons from the top toolbar entirely, and placing them on the right side of the screen instead. I think that actually makes a bit of sense:
This paradigm is loosely based on a sidebar control I saw over in Google Docs. The icons might overlap content in some full-width cases, so that's a new problem to solve. It's certainly more complicated than most of the other solutions, but I find it interesting at the very least.
I like the all-white sidebar. I've frequently felt like that was something I wanted to try out, but never got around to it. It feels light and comfortable. 🙌 |
|
I like the white sidebar! I'm definitely open to this change — the close button may be a "comfortable" choice, but like you noted it's not necessarily the right choice. The only real questions I have now are around accessibility and keyboard navigation… are there any issues there that need to be accounted for? (Genuinely don't know, not trying to raise rhetorical questions!) |
|
@kjellr That mockup looks really cool, but I am worried about it constantly overlapping full-width content, and moving the controls down there feels a bit weird since you use the More menu in the top right to open non-pinned plugin sidebars.
This is something that is already covered by the NUX tips, isn't it? |
We'd likely need to sort out the overlap in some way, and the ellipsis issue is a good point I hadn't thought of. My initial thought is to put an ellipsis menu down on the right too, but we probably don't want to have a bunch of ellipsis menus all over the place. 😄
Theoretically, yes. But if you skip the tips (which lots of people do), we still want to make it as clear as possible. |
|
@kjellr I dig that exploration, we've actually been around something similar with an iteration way back by @folletto that had a vertical bar with icons, very much identically in fact to what Gmail does today. The benefit of that is that there are quite a few challenges with overlaying icons directly on the editing canvas, specifically around very small breakpoints and long documents where you are writing right near the bottom of the viewport. In those cases, experiments with this (like showing word count in the corner) were very disruptive to the experience. At the same time we are now allowing editor styles to colorize the canvas, causing some challenges with contrast of icons overlaid. |
This PR extracts an idea from #9784, a white sidebar. This looks a little jarring at first, but can grow on you. Because it's sort of a jarring change, I think it needs to be tested in a PR, rather than be discussed. That way people can actually _feel_ it, rather than look at screenshots. What do you think?
|
Thanks for the discussions, everyone. In a bit of cleanup, I'm going to close this one in favor of #10062. Give that some thoughts :) |
This commit does a few things: 1. It makes the panel heading the same color as the down chevron. 2. It adds a label to the font size picker, grouping it all together 3. It tightens the margins between switch and contextual help text. 4. It relaxes the margins for base controls inside panels, to make them a bit lighter. Together with #9784 it reduces the weight of panels in the sidebar.
* Try a white sidebar This PR extracts an idea from #9784, a white sidebar. This looks a little jarring at first, but can grow on you. Because it's sort of a jarring change, I think it needs to be tested in a PR, rather than be discussed. That way people can actually _feel_ it, rather than look at screenshots. What do you think? * Try sticky and light gray tabs * Address feedback.
This commit does a few things: 1. It makes the panel heading the same color as the down chevron. 2. It adds a label to the font size picker, grouping it all together 3. It tightens the margins between switch and contextual help text. 4. It relaxes the margins for base controls inside panels, to make them a bit lighter. Together with #9784 it reduces the weight of panels in the sidebar.
* Rework font-size selection to improve clarity of options and the UI. * Add label, relax margins, tighten help text for switch, fix color This commit does a few things: 1. It makes the panel heading the same color as the down chevron. 2. It adds a label to the font size picker, grouping it all together 3. It tightens the margins between switch and contextual help text. 4. It relaxes the margins for base controls inside panels, to make them a bit lighter. Together with #9784 it reduces the weight of panels in the sidebar. * Tweak the reset button, make it disabled until a number is input. * Fix reset clearing input value. * Use different sizes for buttons and render. * Convert font picker to a dropdown select showing real visual sizes. - Add "huge" and "normal" variants. - Normal equals a "reset". * Remove unusued CSS code. * FontSizePicker: a11y: Wrap with NavigableMenu * e2e: Update to accommodate new font size picker * Amend editor-modes test * Accessibility improvements to the FontSizePicker component
Why do this?
Right now the sidebar close button does the same as toggling the cog from the Editor Bar. Redundant UI is usually okay in situations like these, but given the overall complexity of the top right desktop breakpoint UI already — which features both the editor bar cogs, tabs in the sidebar.
By removing a single piece of UI, we keep the exact same functionality as before, but reduce the visual footprint just slightly.
Thoughts? Yay or nay?
Before:
After: