Layout content and wide width controls: remove confusing icon and clarify labels #64891
Conversation
afercia
added
[Type] Bug
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: -34 B (0%) Total Size: 1.78 MB
ℹ️ View Unchanged
|
|
@WordPress/gutenberg-components do the inputs on the ToolsPanel story need to be updated to use |
|
cc @mirka and @WordPress/gutenberg-design who have recently discussed this in #64520 (comment) |
Personally, I don't have a strong opinion on keeping the icons. If the label is clear, I think we can do without them. It's also worth noting that in a separate issue, the current labels were reported to be confusing (#43468). Or, if we're stacking vertically anyway, there's plenty of horizontal space, so moving the icons to the prefix might be an option. Global Styles:
Block Layout:
However, we think we should take into consideration the points mentioned in this comment:
|
That's an option to consider. However, to me, wherever we try to move the icons they will look like clickable icon buttons anyways because the editor already uses patterns with clickable icon buttons in several spots around inputs (which isn't great anyways IMHO). To me, the simplest option to make this UI clearer, consistent, and more predictable is to just remove the icons. |
I think @mirka didn't opt for adding the |
I reckon it may actually be beneficial for each input to have its own help text.
A good one to discuss separately, but I wonder if "Default" might be a better name... I find "Content" a bit ambiguous. Most blocks contain content, but they can all have different widths.
We need to write detailed guidelines to clarify decorative icon usage. Icons as internal prefixes that serve as (additional) visual labels is a fairly established convention, as is internal icon suffixes that serve as interactive elements, some examples: 
As long as we're consistent, it could work imo. Perhaps this could be added to Storybook? |
Then you loose the correlation between the wide and content visual queues in the block toolbar. I'm all for simplifying, but this makes the content/width width input fields lack context (important context). I'd consider this a regression.
|
|
I'd like to approach changes with more accountability for the user-experience of the elements in focus. For example, instead of removing icons and stacking the fields, looking at how this plays into the greater Layout and Dimensions panels. Otherwise, we keep pushing ad-hoc changes that make the greater experience worse. If there's not a clear experience-forward approach, we start there—not on the other end, making focused changes without accounting for the relative user-experience. |
@jameskoster Yeah, I considered to rename it to 'Default' but then reverted. The concept of
I just disagree on this specific usage of decorative icon. We need to distinguish different cases. For example:
Consider the following screenthos:
In the same panel there's a total of 7 icons. Visually, all of them are placed after a control or a visual label. They look like they have the same functionality. As a user, I would expect all these icons to work the same way. But no. Only 5 of them are clickable icon buttons (the ones highlighted with a green circle). To be fair, this is less than ideal. It's extremely confusing and I would say not a great design pattern. Actually, I did try to click those icons. I've been fooled by the look of these icons, more than once. I'm not sure this pattern contributes to make the user experience better in any way. A completely different case is the example you provided, where icons are used in a complex form within the input fields. Ideally, meaningful label text should be enough to identify what an input field is about. I do recognize in very limited cases an icon can further help e.g. the lens in a search field. Lastly, the vertical stacking is necessary because the labels need to be more meaningful. The current labels are less than ideal. The new ones are cleared but also longer. when translated in other languages, they may be even longer. As such, the two columns layout is just not appropriate for such inputs. We've had other cases already where a two columns layout was used without taking into consideration the larity of the labels and translations. I would argue that's not a good design. Content comes first. Clarity of controls labels and functionality come first. The layout should be crafted around the content, not the other way around where most designs in the editor try to 'squeeze' or truncate content just to make it fit into the design. I'm all for establishing guidelines but those should be based on these basic principles. Design around the content. Overall, I think this PR is an improvement as it removes ambiguity and potential source of confusion.
I don't think icons establish a clear context for all users. They may help some users. Instead, labels and descriptions should provide context. I do agree both labels and descriptions should be improved as these settings are really unclear for users. |
|
One more thing I haven't mentioned yet: the current icon for the 'Content' input width is the wrong one. If the desire to visually associate these inputs with the settings in the block toolbar is valid, we should at least use the correct icon. Screenshot:
|
|
Even if I personally disagree with the usage of decorative icons within input fields, and because it's Friday 🥳 , in the last commit I'm trying to use the icons in the inputs Screenshot:
My personal opinion: it's better compared to the current UI. Still, the icons within the inputs may look clickable for users and be potentially confusing. |
afercia
force-pushed
the
update/layout-content-wide-settings-remove-icons
branch
from
6eab042 to
5c6c889
Compare
|
Generally I feel this is a step in the right direction. The labels are clearer, and aligned between control + toolspanel. I appreciate that the icon placement follows a more standard convention. Separate rows is a tricky one... it does seem a shame to split them when they're so close to fitting on one row. But ultimately my feeling on this subject is that the layout should be governed by a different component—something like the Settings form layout designs we've been exploring in https://github.com/WordPress/gutenberg/issues/63624—rather than forced to work in this one instance via ad hoc styles / overrides. Clearly that is a separate, much larger discussion, and for that reason I don't consider separate rows to be a deal breaker in the short term. It would be good to adjust the spacing between the rows so that it is consistent across the block inspector and the Layout panel in global styles. Shouldn't the help text be consistent as well, and potentially polished a bit? |
@jameskoster they're not. They are in English. WordPress is translated in many languages though. Design should always take into account that many translations have strings that are way longer. A two columns layout inevitably breaks in many languages e.g. german, Italian, Spanish and many others. I'd really love the design team to always provide mockups and designs with examples of at least 2-3 languages that are known to be the ones with longer translations. |
|
Re: tweaking descriptions etc. I'd totally agree but prefer to split that in a separate PR. See #64842 (comment) |
I disagree here. This doesn't seem like a meaningful step forward to warrant a change. I'd rather think of layout as a holistic control set than ad-hoc changes that likely further confuse users. Otherwise we'll keep shifting the UI around, making the experience less familiar with every change. |
Rather, I'd argue the current UI is an ad-hoc implementation. Those two icons aren't part of the base component. They're an ad-hoc implementation that only contributes to make the UI inconsistend and confusing. This pattern is clearly problematic because those icons look clickable. I'd strongly encourage everyone to prioritize simplicity and clarity of the UI. Icons on the right of an input field are already a pattern in the editor and they are meant for icon buttons i.e. for interactive controls. In no case icons that are non-clickable and only have 'visual labeling' purposes should ever be placed in that spot. |
The last commit tries to make the vertical spacing more consistent between the two editors. Screenshot:
Re: labels and help text / descriptions: I'd totally agree they should be improved. I'd prefer to do that in the context of #64906 |
There was a problem hiding this comment.
Looks good, code-wise and in the editor. Regardless of any further tweaks we may want to make to this UI, I think there's a lot of value in merging this PR as soon as possible, since these are the last remaining UnitControl instances with the old component size (#63871).
Then we should design a pattern for that purpose, based on the system fundamentals and established conventions. One that will elegantly adapt to different environments. Thinking further down the road, if/when support for additional custom widths is available, 
But obviously this needs a dedicated exploration. |
If screen estate was a concern, we could also switch to a icon-based |
My comment still stands. This isn't an improvement in user experience, but it is a change—one not worth the change. It's clear this isn't an ideal state of this UI/X. |
Fixes #64842
See #64862
See #43468
What?
The layout Content width and Wide width controls have icons on the right that are confusing and unnecessary, as they look like clickable buttons but they aren't buttons, thus breaking an establisehed design pattern in the editor. They also prevent these inputs from using the new 40 pixels size.
Tha labeling of these inputs is shortened to 'Content' and 'Wide' only because the design wants a two-columns layout. However, the labels are unclear and confusing for users as these settings refer to widths. Additionanlly, the panel to reset these settings incorrectly uses the term 'size' e.g. 'Wide size' while in the block toolbar this is called 'Wide width'.
Why?
How?
A note on labels:
I see a trend from the design team to shorten or truncate control labels only to make the controls 'fit' in specific design e.g. a two columns layout. This has the only effect to make the controls unclear for users. Features and settings must have clear, meaningful, understandable names. Please do not ever shorten labels only for visuals reasons.
Labeling a control by an adjective e.g. 'Wide' seems to me far from ideal and not the best UI.
Regarding translations, the new labels may be way longer in other languages. For example, in Italian they woul dbe:
As such, the two columns layout nheeds to be removed in favor ov vertically stacking the inputs.
Testing Instructions
Screenshot before and after:
Screenshot before and after:
Worth reminding the names 'Content width' and 'Wide width' are consistent with the pattern of the settings name used in the block toolbar > Align setting, see the 'Wide width' menu item in the screenshot below:
I will creeate a separate issue to consider to rename the 'None' setting, as it is actually the 'content width'.
Testing Instructions for Keyboard
Screenshots or screencast