Consider reverting back the Settings Icon to the Gear

[masperber]

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.

[tanjoymor]

+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.

[noahtallen]

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

[kathrynwp]

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.

[annezazu]

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.

[tanjoymor]

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.

[ghost]

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!)

[jameskoster]

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.

[masperber]

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.

[richtabor]

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'.

[tanjoymor]

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.

[annezazu]

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).

[Clorith]

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).

[tanjoymor]

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.

[noahtallen]

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!)

[aaronrobertshaw]

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.

[talldan]

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]

I am not sure what this refers to, can I get a little text context?

[talldan]

@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.

[alexstine]

@talldan What is the current label? Trying to figure out which button this is.

[talldan]

@alexstine The label is 'Settings'. It's one tab stop before 'Options'.

[joedolson]

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.

[alexstine]

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.

[richtabor]

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?

[tanjoymor]

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.

[tanjoymor]

@joedolson

Open to discussion on those suggestions, but conceptually I think that's what they represent.

Solid thinking imo.

[alexstine]

@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.

[tanjoymor]

@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?

[joedolson]

@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.

[alexstine]

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:

1. Remove the button, super easy.
2. 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.

[joedolson]

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.

[alexstine]

@joedolson Why is that? If you remove the settings/styles button, you can still open the panel with the button near the end of the DOM. I believe it gets a label of Open document settings. Not sure if there is one for styles, but these actually work in comparison to the settings/styles buttons.

[richtabor]

There's a button to open the Save panel near the end of the DOM "Open save panel". Perhaps that's what you're referring to @alexstine?

[alexstine]

No, if you close the settings sidebar, there is a button labeled Open document settings? It disappears once sidebar is open.

[joedolson]

OK, I found that. It's...interesting. That button is contained inside .edit-post-layout__toggle-sidebar-panel, which is positioned offscreen 9999em above the viewport. It has no visibility state at all. I'm guessing this was added at some point as a tool for screen readers only, as it's only even observable if you're using a screen reader. It's basically the same as the 'Open Publish Panel' control, but with no visible focus state.

That control needs a visible focus state.

Image shows the control with a manually adjusted position of top:20em.

[alexstine]

Haha, wow. You do not see that every day, something inaccessible to the sighted.

Maybe that could be a worthwhile solution? Make these buttons visible for everyone and then get rid of the ones that do not manage focus properly?

[tanjoymor]

@joedolson thank you for the explanation! Still don’t know exactly what DOM is haha, but I do understand the gist of problem. Unfortunately, I’m of no use on that one other than to agree it’s a problem, and I’m glad that this thread has raised the discussions for it again. 😊

[courtneyr-dev]

Will we remain consistent, in that an icon that slides a panel out from the side should also be true for the left panel (List View)? I am largely wanting the Settings icon to remain as it previously was, but if we don't do that, then be consistent with similar icons for the left panel as well. These are roughly like the header and footer icon too, which are not about the Editor experience but rather position of content on the published site.

[sethrubenstein]

For those that know me know that I mostly lurk, but this is one instance where I'm opinionated enough to chime in.

Please keep the current "Panel" icon for the sidebar. It matches what action it performs, display the sidebar panel.

Our users always found the gear icon confusing. They thought this would open some sort of "settings" interface, when they were looking for a way to "open the sidebar".

[cat-og]

While I understand the desire for a button that indicates opening that panel, ultimately the panel icon does open a settings interface. That settings interface happens to be displayed in a sidebar. The sidebar is not functioning as a sidebar on their site, it's sole purpose is to provide access to block and page settings. The button we have now indicates the form, not the function.

In order for users to look for an option to display the sidebar panel, they have to know that the sidebar panel exists, and that it has the options that they need. If they aren't familiar with WordPress, this will not occur to them. In contrast, the gear symbol is a universally recognized indicator for Settings options.

For the reasons mentioned above, I also believe that it would help to set the Settings icon back to the Gear icon. Creating our own symbols to the same effect makes WordPress more insular and inaccessible to new users, and it helps in chat and support documents to have icons that can be quickly and easily described.

[porg]

The icon for that button

1. Should not be the cogwheel, as that's also used inside panels now generically.
   • @annezazu showed that.
2. Should not signify a side panel — b/c the other buttons (Styles, 3rd party) open that same side panel too!
   • @cat-og sharply analyzed "The button we have now indicates the form, not the function."
3. Should signify "Block Settings" or "Template Settings".
   • The problem is that an icon for this may visually closely resemble °2.
   • Hence I propose the generic "Block" symbol as it is used already at wordpress.org/plugins
   • Being not widely known is a lesser problem if discovery is aided (panel auto-opens on several occasions)

But yeah it is tricky! My argument has its weaknesses too

• Alternative: Think about an alternative icon for the cogwheel inside the panel.

[afercia]

Noticed this discussion in the context of from https://github.com/WordPress/gutenberg/issues/49989

I'd think the main point here is the whole concept of 'sidebar'. A sidebar refers to a specific placement in the UI. It's only about visuals and doesn't communicate anything about the underlying features or about what this 'sidebar' content is. It's only a 'positional' concept.

Visually, the icon is honestly just a rectangle with a vertical line. Again, it only represents the visual aspect of the UI. No information at all about the available features or about what this button gives access to.

In https://github.com/WordPress/gutenberg/issues/49613 and https://github.com/WordPress/gutenberg/pull/49614 we updated several labls in the editor to actually remove the term 'sidebar'. For a feww good reasons. Quoting from the issue:

• The term 'sidebar' should be avoided for a few reasons:
  • The whole concept of 'sidebar' is extraneous to blind screen reader users. The term 'sidebar' is mostly used in various aria-label attributes and in some tooltips. Text that is mainly provided for blind screen reader users should avoid spatial terminology such as 'sidebar': as a blind user, I wouldn't mind whether this region is visually placed on the side, top, bottom or in any other spot of the screen.
  • Ideally, UI sections should be named based on their functionality rather than on their visual aspect. Same applies for components.
  • When translated, the term 'sidebar' is generally way longer than in English. For example, 'Close Document Overview Sidebar' becomes:
  • 'Chiudi la barra laterale di riepilogo del documento'
  • 'Cerrar barra lateral de resumen del documento'
  • 'Fermer la colonne latérale de vue d’ensemble du document'

That's way too long when shown in the UI.

I'd also like to point out that on small screens the Settings panel renders in a full-screen overlay. It's not a sidebar any longer, which makes the sidebar icon inappropriate.

In my opinion a good UI should always avoid positional naming and references. Instead, naming should be based on more abstract concepts. For example, instead of 'sidebar' I'd think 'panel' is more appropriate. The same concept should be applied to icons. Icons that only represent a visual concept don't tell me anything about the underlying funcitonality.

As mentioned in https://github.com/WordPress/gutenberg/issues/49989 seems to me the only reason why the cog icon was changed to sidebar icon is that the Settings panel can now contain other settings, the ones used in the panel tabs:

Those tabs should never have used icons in the first place. I even struggle to identify thos as a tabs interface, not to mention the icons don't tell me anything about thunderlying functionality. Those tabs should use visible text instead, thus avoiding the issue of two cog icons rendered at the same time.

In these tabs, while the cog icon is universally associated to the concept of 'settings', the other icon doesn't tell me anything. To me, it's just half a moon:

and certainly doesn't make me think at the concept ot 'Styles'.

Overall, I'm not sure the usage of icons in the editor is always ideal. In my opinion, visible text should always be preferred. To get the best from both worlds, icon + visible text could be considered as a new pattern. Actually that's what web appications that aim to be accessible do. For example, we can argue about many things related to Microsoft as a company, but historically they have always ben very focused on accessibility. As an example, this is what they do on the Web version of their Teams app:

In the screenshot above, the Microsoft Team web app toolbar, with icons associated to visible text by default.

[scruffian]

I've been working with users this week and this has been a cause of confusion for there. Jakob's Law says that we should be using familiar icons, therefore I agree with the proposal to revert back to the gear icon.