gutenberg
gutenberg copied to clipboard
WordPress
Consider reverting back the Settings Icon to the Gear
The Gutenberg block/page/post settings icon was changed. Please consider rolling back this change to the old icon.
Old icon:
New icon:
What problem does this address?
The new icon is less intuitive, and it is more difficult to describe what the icon is when trying to help someone find how to change settings.
What is your proposed solution?
Please consider reverting the icon back to the old icon, pictured above.
+1 to this. The gear/cog icon is a Universal "settings" icon that the general public are familiar with and that is easy to describe and identify. The new icon is non-descript and confusing. It also makes all existing documentation, webinars, tutorials, videos etc outdated in a very big way.
I believe this was changed in this PR: https://github.com/WordPress/gutenberg/pull/45005/files#diff-b20e58387aaaf1809d52371285cc4ac37a5d860ab462647f038cbdaf54e9b876L81
cc @talldan @jameskoster @aaronrobertshaw for feedback on this one
Totally agreed, for all of the reasons @tanjoymor and @masperber mentioned above.
it is more difficult to describe what the icon is when trying to help someone find how to change settings.
This is what we're faced with now:
"Click the icon between the word Update and the green round circle with the two white blobs in it. It looks like a rectangle with a vertical line through it. Oh wait, you haven't published the page yet, so instead of the word Update, look for 'Publish'. Oh, you don't have Jetpack active, so it's just to the left of the question mark in a circle in that case."
You get the picture. :) So much easier just to say "Look for the gear/cog Settings icon at the top right."
Also 100% agree with Tanya that we should stick with standard icons as much as possible, to make it more intuitive for people to figure out what the icons do.
For broader context, this was likely done to better differentiate now that we have split settings. For example, here's what it would look if the icons were the same and it was reverted:
Compared to what is in place now:
While in the short term this might feel like a setback. In the long run, this is intended to provide better clarity between the various options. Perhaps the better question is to iterate on the Settings icon itself rather than reverting.
cc @WordPress/gutenberg-design.
Even in light of the context provided by @annezazu I still feel that the gear/cog icon at the top is better than the new one. In the second screenshot we're keeping two separate instances of the Styles "half moon" icon, so it doesn't feel out of place to me to have the same situation with the Settings icon. There are many situations of having settings within settings with all sorts of software, and is something people generally understand.
I respectfully disagree with reverting the icon... Sometimes we don't voice enough when there is a good change happening in front of us. Instead, we commonly "create issues", so yeah, I created an account to contribute here with my positive point of view regarding the new icon... it seems to be one good change which needs recognition...
I believe the new icon doesn't face lack of meaning, as it is being voiced. In the contrary, the new icon is presented on several applications and OS nowadays. Not exclusive to Apple, but Apple applies this icon in many applications on MacOS and people understand its meaning...
When considering future developments to Gutenberg, there is just so much happening under the cog and more is to come! A cog doesn't represent well. The new icon does. In my point of view, Gutenberg is (finally) with a proper symbol for what it happens when clicking on that area.
Besides that, the new icon seemed to be thought ahead of the strategy of (necessary) reorganization of panels, sidebars... There are many experimental changes to come together, which together they make it easier to understand the reason behind this change. As the new Browse Mode is fully developed and released, I believe the resistance regarding this new icon is soon going to reduce.
Also, the Browse Mode itself and developments related to the reorganization of infos on a left sidebar, is going to open possibilities regarding better integration between Editor-Settings and the WordPress-Admin Settings (those settings available from the dashboard). In my opinion, those are the "settings" capable of receiving a "cog", and not the current right sidebar, which is local setting...
Just for the record, inside the Editor, currently there is a "Preferences" modal available from the "three dots" list... No icon is applied to it. In my point of view, the Preference modal should have been more suited to receive a cog icon than the current document sidebar, in the current organization, if that was the current discussion... It is okay as it is, and things are going to change as noted, I just want to say that I respectfully disagree with reverting to a cog icon on the button which opens the document sidebar.
I am sensible to the argument regarding "It also makes all existing documentation, webinars, tutorials, videos etc outdated in a very big way." But truth be told, since WP 5.8, 5.9 or so, every single release of WordPress brings changes to UI which require revision to tutorials. Either in new icons, rearregenment or rephrasing of existing commands. Those are not problematic changes, when in face of a long-term strategy.
Honestly and respectfully I only agree with the argument regarding the half moon in this thread. Unfortunately, when that one was introduced, none of the several comments of feedback were considered, when many people have required here on GitHub better icons than the half moon.
(I created an GitHub account, just to voice my comment here. Hope it helps to the discussion!)
Just to add a little more detail to the excellent points made already by @annezazu and @kaionstromer; an upcoming part of the work in #36667 includes moving global styles and menu management to the dark navigation area on the left of the site editor. Once this is implemented the site editor document toolbar will include only two icons in the top right – the sidebar icon and the ellipsis icon:
This reduction will hopefully make the new icon more intuitive.
Thank you for the addition context @jameskoster
As clean as it looks in the image you provided, remember that users may choose to install plugins that add additional icons in the top right corner, such as Jetpack and Yoast.
Moreover, I feel that the familiarity of the cog icon is a good thing for the user experience. For example, the floppy disk icon is still the universally recognized icon for “Save,” despite the fact that the floppy disk itself is now obsolete.
If the community decides not to bring back the gear icon, I would still urge iteration on the new icon, as @annezazu suggested, to create an icon that is easier to describe with language.
I like that the sidebar icon provides more visual context relative to the button's action — that is, opening and closing the sidebar/tray of controls.
To add more context, perhaps the tooltip should be more relevant as well — 'Open sidebar' and 'Close sidebar'.
Thank you all for the excellent points and additional context provided above, it definitely does influence the perspective on things.
I think it also illustrates a deeper issue that is more about timing, order, and communication. Things definitely move fast in tech, which of itself isn't an issue. However, when changes are made today that won't make proper sense until the changes still come at a future date have been implemented, it causes a great deal of unnecessary confusion. Add to this the reality that UI changes are never announced or pointed out within the software and we end up confusing (and often frustrating) users (especially beginners). I've personally had to assist users who were following instructions that specifically said "Click the gear/cog icon in the top right corner" and because they take things literal and aren't comfortable clicking their way through exploration, they stopped right there because there was no "gear" icon.
I'll admit that the missing cog even tripped me up the first time I noticed it had changed.
If changes like this came with a temporary pop-up pointing out the change, it would be far less disruptive and would also minimize the impact that these changes have on existing documentation. People have a better chance of following instructions that say something different to what they're seeing when that something says "btw this has changed".
While veering a bit off the direct topic, this is an excellent example to emphasize the importance of ensuring that UI changes are taking place at the right times, when they should happen, and not in advance of when they will make sense. And the importance of in-product notifications that guide users, to proactively reduce confusion. Even for seemingly minor changes.
As to the question at hand, to revert or not revert XD it's a tough one in my opinion. Some icons and designs definitely do change over time, and if WordPress wants to be on the leading edge of those changes, then it's going to implement them ahead of mainstream usage. That said, as @masperber noted, the save icon is a universal icon that has never changed (though it's also worth noting that WordPress doesn't use a save icon of any kind, anywhere).
It's also an easy argument that this particular setting icon (regardless of the design changes, and coming layered approach) is still the entry point to get to "settings". It feels a bit irrelevant that once in that section there will be additional icons and sections, that's kind of par for the course when you go into any settings section. And the gear/cog icon is still in fact a universal icon.
I do agree that once you understand 'what' the new image icon is, and what it represents, there is a level of logics to it. It's a wireframe of a page indicating a sidebar location. But that is not at all intuitive to a large number of users, and it's not easy to explain in layman's terms. So what might be some suggestions around how to describe the new icon, in a brief, user-friendly way? And what should it be called? Since the gear/cog is the universal "settings" icon, it goes against all conventions and general knowledge if we say "click the settings icon" that isn't actually a known settings icon.
I also agree with the suggestion of a tooltip that provides more relevant context. Not sure if Open/Close "Sidebar" is quite enough, but maybe "Settings Sidebar"?
In my mind, these are discussions and decisions that should have taken place before the icon was changed. But since the change has already happened, there should likely be careful consideration around whether or not to keep it, and if yes, what can we do to make it a better user experience – before more changes are made.
Noting that this icon was discussed here: https://github.com/WordPress/gutenberg/issues/40204#issuecomment-1276264434. The design that @jameskoster shared above is also what's being attempted for 6.2 with the work done here for browse mode: https://github.com/WordPress/gutenberg/issues/36667 (see the to do items at the bottom of the issue description around moving pieces to the left). While this change in the icon has landed sooner than that, it's part of the trade off of building various pieces at once in a large open source project. In this case, the split icons landed first as an experiment with more to come in browse mode.
Changing any icon is difficult so keep the feedback coming either way. This impacts Learn WP resources, documentation, etc and, even if it's the right move, it needs to be done over time and with broader communication. I'll be doing what I can there assuming this stands. cc @courtneyr-dev (Learn WP) & @zzap (documentation).
I want to echo the comments for keeping the new icon. It much more clearly relays what is expected of this button action, in a way the cog never truly felt right for (and kudos to those who were able to put this into words!)
It's a valid point that if dotcom is having issues because they are auto-enabling, and updating, the Gutenberg plugin on every site, it may be time to stop doing that on their end? Given that the editor has been in core for a few years now, and should be stable enough to not need the plugin to build off, as it feels wrong to negate the fast pace that is expected of a beta plugin (this with the implication that this will likely impact the amount of potential feedback we may be getting from real world usage though).
Quick apology, I've removed my previous comment as I was veering off into topics not appropriate for this thread.
Updated comment:
The discussion noted above didn’t cover the impact or pros and cons of changing the icon. That’s what I’m referring to in my comment. We certainly don’t want to red-tape or bottleneck progress, but I do feel that we should be asking (and answering) “What problem is this change solving?” and “What impact will this change potentially have?” Perhaps some of those conversations are happening somewhere, but they’re not always easy to find.
Also to note that Dotorg Learn isn’t the only documentation area that gets affected. Every partner and collaborator in the broader community who are providing materials to help users use the WP software, are also impacted, which could be potentially damaging to their own projects and even livelihoods.
My point is only to stress the widespread impact of seemingly minor changes. It extends far beyond tech savvy users, who can take changes more in stride.
There are other nuances as well around whether or not users are using the GB Plugin (and if they are doing so knowingly) that compound this dilemma.
It's a valid point that if dotcom is having issues because they are auto-enabling, and updating, the Gutenberg plugin on every site, it may be time to stop doing that on their end?
I won't speak for Automattic as a whole, as there are definitely many perspectives to this, but we do see a lot of value in getting new Gutenberg features quickly (especially around full site editing and global styles), and providing a way for the Gutenberg project to get large-scale feedback. On top of that, we try to maintain stability in this fast-paced environment by releasing plugin patch releases with bug fixes. (And we do test fairly extensively before updating the plugin!)
Great discussion. Sorry, I’m a bit late to the party as I’ve been AFK for a few weeks.
I think @annezazu, @kaionstromer, @jameskoster, @richtabor and others promoting keeping the current icon capture my thoughts on the matter, which essentially boil down to the fact the icon represents a sidebar panel that relates directly and neatly to what that button’s action is.
I'd also suggest that the icon change isn't really targeted towards satisfying future requirements but that it stands on its own merit in the context of the current editor.
The points regarding the impact on pre-existing documentation, labelling, general communication of the change etc., are all well made, though.
One additional point to consider, relating to the suggestion to revert the icon to a gear/cog while the new icon is iterated on, is that this chopping and changing would lead to further confusion.
My personal vote would be a big +1 to keeping the current “sidebar” icon. We can still aim to improve communication of this change, such as updating the labelling from “settings” to “Open/Close sidebar” etc.
To add more context, perhaps the tooltip should be more relevant as well — 'Open sidebar' and 'Close sidebar'.
This might be good, I do feel like 'Settings' is a little too close in meaning to 'Options' which is right next to it.
With any renaming there are a few things to be aware of:
- The updated label should work well when the 'Show button text labels' option is active.
- The sidebar is a region that has it's own label and is announced by screen readers (currently 'Editor settings') and should really match the button label.
- It'd be worth getting accessibility approval on any change. I'm not sure 'Sidebar' really conveys exactly what the button does. 'Inspector' might be the closest, but that does sound a little technical. There could potentially be a more descriptive aria label that's not visible (e.g. 'Open editor settings sidebar'), but I would like to get a thumbs up on that from an accessibility expert.
@alexstine The discussion was originally around a recent change to the icon for the 'settings' button in the 'editor top bar' region.
But the chat has more recently pivoted to discuss updating the label for the button and what would be a good label.
@talldan What is the current label? Trying to figure out which button this is.
We should try and keep the visible label matching what screen reader users get as much as possible. It is sometimes necessary to get more context (e.g., to differentiate to identical links), but if we believe that a label is sufficient for a sighted user, then we should not try to provide screen reader users with different information. One reason for that is support: support becomes very difficult if one user reports a problem with the "Open the Editor" button, but the sighted support person sees an 'Edit' button (e.g. #47335).
I agree that "settings" and "options" as two separate links are confusing; they sound like the same thing, and don't help the user understand what they'll be able to do, or easily remember which tool is which.
Thinking out loud, the 'Settings' button opens a panel to adjust settings for the current template or block; the 'Options' button opens a panel to adjust settings for how you use the editor. The difference is mostly context. 'Settings' opens a container with the name 'Editor Settings', but is really settings for adjusting blocks and templates, not for adjusting the editor.
With that in mind, I think I'd propose changing 'Options' to 'Editor Options'; 'Settings' to 'Settings Panel' (because the content of that can vary widely, and the location of the panel doesn't really matter), and the name of the panel from 'Editor Settings' to 'Settings Panel'.
Open to discussion on those suggestions, but conceptually I think that's what they represent.
Thanks @talldan, makes sense now.
I actually have a different proposal to share. I think this button should be removed completely from base wordpress/interface. The button adds no value for screen reader users as focus is never transitioned. I think it is currently very confusing regardless of the label as activating it appears to do nothing for non-sighted users. It is simply too far away in the DOM to add any required value.
To add more context, perhaps the tooltip should be more relevant as well — 'Open sidebar' and 'Close sidebar'.
@joedolson What do you think about using the "open" or "close", based on the sidebar state?
Fwiw, my recommendation is to leave the word “settings” in the label. We’ve taken away the icon people will recognize, let’s not also take away language they will recognize. And that icon is used in the page editor as well as the site editor, and in the page editor it is opening the “page settings”, as well as access to all the “block settings”. But expanding it to “open settings” and “close settings” would be fine.
The accessibility concerns is another matter entirely and sounds like it’s more than a naming issue based on the comments above.
@joedolson
Open to discussion on those suggestions, but conceptually I think that's what they represent.
Solid thinking imo.
@richtabor Probably no need to change the label if it is communicated visually and via ARIA attributes. Changing label context can often times be a mistake.
@tanjoymor
The accessibility concerns is another matter entirely and sounds like it’s more than a naming issue based on the comments above.
Issue is, this package is super old and probably just needs to be deprecated anyway. See the related PR where I tried a few ideas to fix it but ultimately gave up after receiving some feedback. I understand this issue has focus on the label text but I think a better use of our time would be removing it all together and closing this issue. It is purely visual.
https://github.com/WordPress/gutenberg/pull/38360
Related issue from ages ago: https://github.com/WordPress/gutenberg/issues/15322
Do not know your opinion but at this point, doubtful anyone is going to fix it.
@alexstine I’m not familiar with the ins and outs of accessibility to be much use on this one, and I’m not a coder.
It sounds like you’re suggesting to completely remove the settings icon from UI entirely. Is that correct? While I am seeing the concerns with the accessibility component of this, and do agree that it should be addressed and fixed, I’m not sure that removing the icon from the UI entirely is a good idea.
From an educational perspective and through the lens of beginners, it would be a bad idea to eliminate that icon and easy access to open/close the settings sidebar.
But maybe I’m misunderstanding your suggestion?
@tanjoymor The accessibility problem here is that the Settings panel control toggles open and closed the settings panel, but does not provide any mechanism for users to get to the settings panel after opening it. The same problem is true of the Styles panel. Once you've used that control to open or close the panel, the panel itself should be in close proximity in the DOM to the control. The Options, which operates a popover, is fine, because the control moves focus into the popover.
The accessible name for Settings and Styles already indicates it's open or closed state using aria-expanded; there's no need to do anything with that. However, the user needs to be able to find the panel.
I can understand why Settings and Styles need to be handled differently: they need to be persistent, because they contain tools that impact blocks.
The suggestion in #15322 that would be simplest to resolve is to move focus into the settings panel when it's toggled.
My point was the focus fix might not be so easy from a coding perspective because of the legacy wordpress/interface functionality. My above PR and issue has some discussion around that. The two solutions are:
- Remove the button, super easy.
- Refactor the functionality to move focus on settings/style panels open. Lots of dev time, not easy.
If someone wants to take it on, by all means lets get it done so these buttons work well for everyone. Simply changing a label is not going to fix our problem on this one and I think this is a great opportunity to get this done right.
Just to clarify, Alex: when you say "remove the settings button" what do you mean? The practical interface change would be to remove both the Settings and Styles buttons, have the settings panel be persistently open with tabs to switch between styles and settings within the panel.
Just removing the button with no other changes is a non-starter.