WordPress.org

Make WordPress Core

Opened 7 years ago

Last modified 5 years ago

#29158 closed task (blessed)

Customizer UI Design lacks contrast for visual hierarchy and does not match wp-admin — at Version 33

Reported by: celloexpressions Owned by:
Milestone: 4.7 Priority: normal
Severity: normal Version: 3.8
Component: Customize Keywords: color-contrast ui-feedback has-patch needs-testing needs-refresh
Focuses: ui, accessibility Cc:

Description (last modified by rianrietveld)

WordPress 3.8 (and the mp6 project) introduced a new design language for the WordPress admin, including a flatened design, higher contrast, more color, an icon font, and more. While it reskinned the Customizer, further work on the Customizer UI has proven difficult because the Customizer still lacks enough contrast for proper focus/hover/active styling.

Implementing things like Widgets, Menus, and Panels into the Customizer, has shown that most background colors need to be between #fff (the section heading color) and #eee. This makes it extremely difficult to create visual hierarchy between UI elements using color.

Customizer controls themselves are on a white background, not the off-white that is now used in wp-admin, making input elements stand out less and generally making something about the Customizer UI not feel very "WordPress". While the other accordion in the admin (in Menus) also uses this convention, it doesn't fit well in the Customizer since the Customizer accordion contains the primary actions.

The goal of this ticket is to introduce more breathing room for stronger visual hierarchy in new development with the Customizer, and to resolve the lack of contrast for focus/hover and active (open/current-section) states. Additionally, we should address concerns that the Customizer doesn't really match wp-admin (or the front-end toolbar, for that matter, which it should be more similar to given the front-end context) in the process.

MP6 did experiment with a considerably different design for the Customizer at one point, but it was pulled because the dark styling, which was keyed to color schemes, was too heavy, and felt more appropriate for a menu than for tools. However, one potential option for addressing this ticket is to re-explore color scheme integration, since color schemes are under-utilized in the Customizer. This is one approach I'm proposing, but not the only possible solution here. Many options have been explored, and I like this the best, but this is design so not everyone will. I'm open to anything that addresses the issues above.

The coming patch uses admin menu colors (keyed to colorschemes) for the navigation components of the Customizer, but uses wp-admin body styling (the off-white background and light UI) for the functional tools/controls regions of the Customizer. Not perfect, but an interesting proof-of-concept at the very least, and does address some of the issues with this approach in mp6.

Tracking label: #a11y-color

Change History (44)

@celloexpressions
7 years ago

Failed experiment at improving contrast between inactive and active/hover/focus styling, with panels.

@celloexpressions
7 years ago

Failed (too many shades of gray, though likely to end up in 4.0) attempt to introduce more contrast/hierarchy but keep things very light.

@celloexpressions
7 years ago

Initial attempt to re-introduce color schemes and stronger contrast/hierarchy, with the default colorscheme and 29158.colors.diff.

@celloexpressions
7 years ago

Insufficient range of shades (of gray) for good color-based visual hierarchy in Menu Customizer.

#1 @folletto
7 years ago

Please note that as mentioned in #28979 the visual hierarchy could be hugely solved just by switching from accordions to slide-ins (as Widgets are), thus reducing any need of complex visual hierarchy solution, which would be just a stop-gap. ;)

#2 @celloexpressions
7 years ago

Also, a very important thing we need to resolve as part of this process is that the current focus styling for control sections and panel headers is horribly inadequate. We either need to achieve color-inversion, significant luminosity change, or add some other indicator like a border (not ideal since we'll also use that styling for open/active sections, unless we slide them over like panels and drop the accordion). See #28267 for more details.

#3 @dauidus
7 years ago

I would really appreciate a darker styling, and don't think something keyed to color schemes would present itself as too dark. As we stand in 4.0, its difficult to distinguish where one section ends and the next begins, particularly in sections with more than one option. When we also consider the coloring of standard buttons within the customizer, we begin to see a real disconnect in the overall styling. After all, settings in the Customizer should be easy to find and simple to navigate through. I'm just not getting this with the light grey color scheme, though.

Perhaps the disconnect when using a darker color scheme presents itself most in the secondary panels (the ones that slide in). No clear distinction is made between the "You are Customizing" title and the setting panel.

I understand that tying the Customizer colors to the chosen color scheme might not be the best option. But, it would provide a more cohesive UI and help direct the user to the desired areas.

#4 follow-up: @folletto
7 years ago

As we stand in 4.0, its difficult to distinguish where one section ends and the next begins, particularly in sections with more than one option.

This is an accordion issue, which surely could be reduced by a different color scheme, but in the end it will still be the issue of using accordions. If we switch to sliders for every block we will solve this issue once and for all. ;)

@celloexpressions
7 years ago

Proposed design of "open" section if sections use panel-like side-sliding.

@celloexpressions
7 years ago

Proposed design options for "open" sections if sections use panel-like side-sliding.

#5 in reply to: ↑ 4 @celloexpressions
7 years ago

Replying to folletto:

This is an accordion issue, which surely could be reduced by a different color scheme, but in the end it will still be the issue of using accordions. If we switch to sliders for every block we will solve this issue once and for all. ;)

I think our best approach is to do both - utilizing a broader range of colors to achieve adequate visual contrast, and doing a better job at organizing section and panel hierarchy appropriately.

I tried exploring some options for side-sliding accordion sections (screenshots above), and we're actually going to run into the same colors issue if we try to implement it in the current scheme (we either have input elements blending into the background (which the admin addresses with the global #f1f1f1 background) or a bunch of slightly different grays competing for attention). By leveraging a broader range of colors and removing the accordion behavior, we can achieve a visual and organizational distinction between navigation and content.

For example, when no section is open, everything is dark, but we can use bright (colorful) hover/focus states. Once a section is open, most of the visible space is on a light background, but the navigation controls at the top and bottom remain dark to provide a clear UI hierarchy. I think we should try using something like #000 for the hover/focus-states of the back/close buttons instead of the color there, to avoid making it distracting (since we removed the blue hover states from the light theme).

Changing the accordion behavior depends on #28709, but we may be able to do this for 4.1 depending on the timing. Also, one note: we should make #customize-info, and the panel-description sections retain the accordion behavior, since making those side-slide would be pretty inefficient.

#6 @folletto
7 years ago

I think our best approach is to do both - utilizing a broader range of colors to achieve adequate visual contrast, and doing a better job at organizing section and panel hierarchy appropriately.

I agree that these are separate issues.
That said, what "contrast" are we trying to achieve? Consider that there's a page on the side, so the main contrast needs to be with the page on the side, which must be kept in consideration in designing this panel. :)

With this I mean that if the panel uses different bands of color or solutions that don't make it perceived as a "single piece" it would create perceptual interference with the page on the side.

That's why of the solutions you propose above, the one with just a single color and no boxes is the one that works better: it's cleaner, understandable, and create a single object contrasting on the page to the right. :)

I have no preference on light vs dark choices, I feel both can work well (in the end, you can have a white or a black theme to the right, which we don't know), I just feel we shouldn't use multiple layers / tones there, but aim for a single one.

tl;dr: in your mockups above, I'd go for the leftmost ones.

#7 @celloexpressions
7 years ago

Once we implement side-sliding (a 4.2 thing at this point, unfortunately), I think we could explore a redesign along those lines, although that actually has less contrast as a whole, so we'll see. Removing borders and other visual elements would reduce the need for as much contrast.

@JohnPixle
7 years ago

#8 @JohnPixle
7 years ago

Looking into this, I think it reveals a further inconsistency in styling. I have to agree that indeed the customizer page does not blend nicely with the rest of the admin in terms of styling. Given the functionalities of the customizer page, I instantly make a connection between this page (customizer), the widgets page and the menus page. I attached the image above, to point a couple of things:

At the widgets page and the menus page, while the UI follows the same approach, the field labels are styled differently (highlighted in green). At the customizer, we see even a third style for the labels, which is quite similar to the main tabs.

A second inconsistency (highlighted in blue) is between the widget and menu titles, and the main tab at the customizer.

So, perhaps we could refine the hierarchy here and follow a consistent styling. Personally I think that the field labels at the customizer are quite emphasized. Personally I would go with the same styling which is used for the labels at the widgets page.

Ideally I would also suggest to change the styling of the labels at the menu page as well, but I guess it is another chapter

I will try to make some mockups for a proposed Customizer text styling later today or tomorrow. Let me know any thoughts!

@JohnPixle
7 years ago

Proposed design for better hierarchy in the customizer accordion tabs

#9 @JohnPixle
7 years ago

Above is a quick draft I designed as a suggestion. This one uses an inset for the current accordion tab title and content, and a color accent for the current accordion tab.

In the example I am showing a case where there are 2 field sets in the accordion content.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

#11 @celloexpressions
7 years ago

#31336 now has a patch for addressing the more fundamental issue of the accordions not being good UX here. Once that's resolved, we can circle back here to evaluate the visual design options within the more logically structured Customizer for improved contrast and color schemes.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

#13 @celloexpressions
7 years ago

  • Milestone changed from Awaiting Review to 4.3
  • Owner set to ocean90
  • Status changed from new to assigned

The latest designs for #31336 address the issues of contrast and hierarchy here pretty thoroughly, establishing a pattern of white elements being interactive juxtaposed against a gray background. Navigational elements also receive colored backgrounds on hover/focus, whereas inputs get borders/shadows for focus indication.

Unless anyone sees a need for further work here, we can close this when a first pass on #31336 is committed. (see screenshots and screencasts on #31336).

#14 @folletto
7 years ago

I agree. :)

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

#16 follow-up: @celloexpressions
7 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

This is currently fixed in trunk by #31336. However, @helen has expressed concerns with the blue hover states introduced there; if we end up with a change there that doesn't provide adequate contrast for focus styles for accessibility, we'll need to reopen this.

#17 in reply to: ↑ 16 @hugobaeta
6 years ago

Replying to celloexpressions:

@helen has expressed concerns with the blue hover states introduced there; if we end up with a change there that doesn't provide adequate contrast for focus styles for accessibility, we'll need to reopen this.

I was trying to make sense of the many tickets around this, and this solution (that you proposed in #31336) seems to help with what @helen mentions, and make the most sense (notice, I'm looking at the hover colors specifically):

https://core.trac.wordpress.org/raw-attachment/ticket/31336/customize-ux-redesign.gif

#18 @ocean90
6 years ago

  • Keywords needs-patch added; has-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

#19 @ocean90
6 years ago

  • Owner ocean90 deleted
  • Status changed from reopened to assigned

This ticket was mentioned in Slack in #design by ocean90. View the logs.


6 years ago

This ticket was mentioned in Slack in #design by stephdau. View the logs.


6 years ago

#22 @obenland
6 years ago

@hugobaeta, @ocean90: What's the status on this? With beta1 is one week away we should make a decision on this.

#23 @celloexpressions
6 years ago

  • Focuses accessibility added

This probably needs to become a task and slide into beta. We can't really not fix it/punt again at this point I feel like, especially with all of the related changes that have happened so far in 4.3 (#31336 and the corresponding unified approach menus took, but not doing menus yet and having some bits reverted with the blue). I have one more idea to propose here that focuses more on improved handling of borders than changing backgrounds/colors, which I'll put together this weekend if a solution isn't finalized before that. But ideally we need to start looking at a bunch of design proposals in the form of screenshots attached to this ticket.

Adding accessibility focus due to the severe lack of a visual indicator of focus that is one of the main issues we need to fix here after the blue was re-reverted.

This ticket was mentioned in Slack in #design by celloexpressions. View the logs.


6 years ago

@celloexpressions
6 years ago

Audit usage of borders in Customizer Navigation. Introduce clearer, higher-contrast hover/focus styling for navigation, with visual non-color focus indicators.

#25 @celloexpressions
6 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

29158.borders.diff takes another look at this, specifically focusing on improving visual focus styling for accessibility purposes (including better contrast for users with less-than-ideal screens).

This patch introduces darker borders and slightly darkens the text color to accentuate the extremely slight difference in background color that is currently in place. Additionally, rather than adding an even darker border, colored box-shadow, or other more distracting focus indicator, it implements an icon change that makes it easy to distinguish the hovered/focused item fr om the others. In practice, playing around with the patch, I think it works, but I'm interested in other opinions on this.

Leveraging borders as a means for improving contrast/distinction between elements is the broader proposed solution here, and would be the recommended way for developers to introduce hierarchy when color isn't enough in the Customizer. This allows us to keep the light UI without using too many different grays and while ensuring there is adequate contrast between elements of different hierarchies. I've audited the use of borders throughout the Customizer navigation for consistency in this patch as well.

Once we've resolved this for the main navigation and general governing principles, we can address more specific issues like unifying widgets and menus and improving visual contrast and hierarchy there (in #32679).

This ticket was mentioned in Slack in #design by marita. View the logs.


6 years ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


6 years ago

#28 @ocean90
6 years ago

  • Milestone changed from 4.3 to Future Release

Moving this out of 4.3 because it definitly needs more eyes, especially from designers if we want to change colors and such. This should probably have some variants too so we can run them through user tests to find the best combination of several ideas.

#29 @afercia
6 years ago

After the blue on hover/focus was reverted in 32823 see #31336, using just a shade of gray wouldn't be sufficient. Also, focus indicator shouldn't relay on color alone and secondary marker is required. 29158.borders.diff is an improvement since it uses also an icon change.

By the way I would propose to make an effort to establish a unique design pattern to be used also in other places in the admin, see for example #28599 or what Press This currently uses (see screenshot below).
Worth considering WordPress should have a unique way to indicate focus on this kind of menu items and users shouldn't be forced to learn new patterns depending on the different screens/components.

Menu items focus style in Press This:

https://cldup.com/gxI1O-FC6z.png

#30 @celloexpressions
6 years ago

29158.borders.diff has been implemented in the Customizer UI Experiments plugin to facilitate testing. Interested parties: please install and test that plugin and share back thoughts on the UI here. Anyone interested in making code changes via the plugin let me know and I can give you commit access; for mockups and discussing ideas, let's keep the discussion on this ticket.

After seeing the skin that WordPress.com has added (using light blues), I think we should definitely do everything we can to avoid that, unless we can find colors that feel better and more neutral. Given the stated intention (either above here, or on slack) to keep the Customizer as minimal as possible so as not to distract from the site preview, the subtle changes in the borders patch would probably work much better than something like what press this uses, at least for now.

That's not to say that the Customizer wouldn't benefit from a broader redesign from the ground up, but given the current UI I think the borders patch is the best path forward for now. Would love to see concepts for an entirely new Customizer UI eventually (only requirements being that it needs to include panels, sections, and controls, and the preview in some way).

#31 @afercia
6 years ago

From an accessibility point of view what the Customizer UI Experiments plugin does it's a clear improvement, see below without and with the plugin enabled:

https://cldup.com/FeQqbITd1c.png

The focus indication is given both by the subtle changes in the background color/borders and from the arrow's shape change so it's not conveyed by color alone but also by an additional visual clue. Will ask the accessibility team to have a look :)

Maybe the only place where focus is still unclear is on the reorder buttons:

https://cldup.com/ZAVr23QA6M.png

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


6 years ago

#33 @rianrietveld
6 years ago

  • Description modified (diff)
Note: See TracTickets for help on using tickets.