Description

Splitting this out from #62129 where an interesting conversation about cohesive design language in the editor UI took place.

I believe cohesive language should apply also to icons and their usage in the editor.

Some icons represent very familiar logical concepts for users. For example, a plus icon + immediately associates with the concepts of 'Add', 'Create new', 'Insert', or 'Increase'.

Other icons need to be 'learned' in the context of the application and UI they are used into. This implies some initial cognitive load and learning curve. When users get familiar with the meaning and purpose of that icon, the icon helps identifying a specific feature in the user interface. As long as the usage of that icon is consistent.

Noting that, from an accessibility perspective, proliferation of icons is a problem and it would be preferable to have icons accompanied with visible text labels, but that's another issue.

Consider the following icon:

Its name is settings. Visually, it's two sliders made of a track and a handle (or 'knob'). Regardless of the icon name settings, I would say the logical association isn't immediate but can be learned. It's about values that can be 'adjusted' and 'set to' so that, in a broader sense, this icon represent the concept of 'settings'.

How this icon is actually used in the editor

At the time of writing this issue I can find 5 occurrences of icon={ settings } in the codebase.

In the first three cases, this icon isn't used to access 'settings'. Actually, it is used to switch a control to an alternative version where users can set custom values.

1
SpacingInputControl component.
By clicking the icon button the range control shows an additional input field where users can enter a custom value. There are many instances of this component for the various margin, padding, block spacing values etc.

2
FontSizePicker component.
Same: clicking the icon button switches the control from preset values to an alternative version where users can enter a custom value.

3
ShadowInputControl control in the ShadowPopover component.
Same: clicking the icon button switches the range slider to an input field where users can enter a custom value.

As a user, it took me a while to 'learn' what this icon button is about. Now that I know what it is about, I would expect this icon to always be used consistently and always have the same purpose.

Instead, this is not the case.

4
The fourth occurrence of this icon usage is for the DataViews 'View options` button. Screenshot:

It opens a dropdown menu with a multitude of options for the data views layout, filtering, items to show, items per page. In this context, this icon button meaning and purpose are entirely different.

IMHO, this inconsistent usage doesn't help in building a cohesive design language. Also, as a user, the cognitive load is now doubled because I have to remember that this icon has different meanings in different contexts.

5
The fifth occurrence of this icon is in the Query loop block toolbar. Screenshot:

It gives access to a popover where users can set the items per page, the offset, and the max pages to show for the Query.

Again, the icon meaning and purpose in this context is entirely different and inconsistent. As a user, I have now to remember that this icon means something entirely different in three different contexts.

Conclusion

The 'settings' icon is a good example of how the actual icons usage can be problematic when it's inconsistent. Ideally, icons that need to be 'learned' should have only one, specific, consistent usage in an user interface. There is no point in forcing users to learn what an icon means when the icon meaning changes depending on the context.

Overall, I'd like to see a more strict, cohesive usage of icons throughout the editor, especially for icons that users have to 'learn'. I'm not sure the current situation helps much with building a good user experience.

To me, the cases 4) and 5) are less than ideal. Those controls should be changed to use another icon. The settings icon should be reserved to the 'switch' button for the controls alternative version.

The editor is already complicated. I'd think design should strive to simplify wherever possible and have UI conventions that are consistent to reduce cognitive load as much as possible.

Step-by-step reproduction instructions

N/A
Go through the various UIs illustrated in this issue description.
Observe the inconsistent icon usage.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes