Icons for Customizer Sections

[celloexpressions]

The admin menu has icons. Widgets have icons. With more and more options being added to the Theme Customizer in core and by themes and plugins, the addition of icons to section titles would make it easier to find the controls section you're looking for faster. This would work well with things like #27406.

Themes and plugins could specify their preferred dashicon when adding a customizer section, similarly to how they can specify icons when adding custom post types. I don't know that it would make sense to support custom (non-dash-) icons, though.

[celloexpressions]

Possible implementation of customizer section icons, with a way for plugins and themes to specify icons for their custom sections.

[celloexpressions]

Add a custom icon to Twenty Fourteen's "Featured Content" section.

[celloexpressions]

If we move forward with this, it would probably be worth creating new Dashicons especially for the customizer, with better ones for the default sections and maybe a couple that would be commonly used by themes and plugins. For now, I selected reasonably relevant icons to demonstrate the potential implementation.

[ocean90]

Not sure if icons are really needed. In Admin Menu they are still visible when the menu is collapsed, in Customizer they will not, yet.

[helen]

Punting - not convinced just yet, needs some more feedback.

[celloexpressions]

Alternate option, now: icons for panels, but not sections. See also #28979 and the need for visual hierarchy between panels and top-level sections.

[celloexpressions]

Icons for panels, to provide hierarchy between panels and sections and to make it easier to find certain panels if they're in mixed sorting.

[celloexpressions]

Icons for panels only, using same API as the sections approach.

[celloexpressions]

Icons for panels only, with mixed sorting between panels and sections.

[celloexpressions]

#28784 currently depends on this, so updating the milestone accordingly. We'd like to utilize icons so that we can improve the collapsed state on mobile (where you have to collapse to preview), and we'll probably also want to leverage that functionality on larger screens.

I can do an updated patch here for panels and top-level sections, with the ability to specify a dashicon when adding sections from plugins/themes. We should probably design some new ones for the core Customizer sections as well.

Still looking for UI/UX feedback here (and on #28784). Are there good reasons NOT to do this? Are there good alternatives for improving the mobile & collapsed states? Would it help if they were a slightly lighter color? Should they only be displayed on mobile? Also keep in mind that we don't really want the Customizer to look too much like the admin menu, as that could confuse users as to the difference between the Customizer and the admin.

[folletto]

Are there good reasons NOT to do this?

The only issue there can be one in my view: reduction of available space for translations. If however we don't have that concern I think it's a good idea. Note that even if this is a concern, given the available space still there, feels to me a minor one.

Are there good alternatives for improving the mobile & collapsed states?

I feel that a discussion I brought up in #28784 too is to switch everything from accordions to sliders. This will solve both mobile interactions and simplify the perception of the UI as well.

Would it help if they were a slightly lighter color?

Color can be a choice, but I feel another thing might actually be even better: align the text even with missing icons. ;)

Should they only be displayed on mobile?

Cross-screen consistency helps a lot in reinforcing visual recognition. So I would keep them on both screens. :)

Also keep in mind that we don't really want the Customizer to look too much like the admin menu, as that could confuse users as to the difference between the Customizer and the admin.

That's a good concern, but I don't think that the introduction of icons create ambiguity. If anything the removal of the same sections from the admin menu (#25571) and the "appearance" of that in the customizer will _reinforce_ that split. :)

[folletto]

Customizer: text-aligned list items

[celloexpressions]

Refresh, with support for panels and top-level sections, and adding icons to all core and bundled theme sections. A default icon is shown for sections without icons.

[celloexpressions]

28504.2.diff​ is a refresh that adds support for icons to panels and top-level sections. Note that a default gear icon is used for any that don't specify an icon, like is done in the admin menu.

@folletto outlined all of the reasons for this pretty clearly, and icons give us lots of options for an improved collapsed view, etc. and will be especially nice once we implement panel-sliding behavior for sections to replace the current accordion.

I've opened #29855 for discussion of any new icons we want to create here, so that that doesn't hold this up.

[celloexpressions]

This is now a dependency for #29949, which leverages the icons in a re-designed collapsed mode for the Customizer, and is a huge UI improvement there.

[ocean90]

Is it okay to only support Dashicons? Can we do something like we do for the admin menu? See trunk/src/wp-admin/menu.php#L111​.

[celloexpressions]

Replying to ocean90:

Is it okay to only support Dashicons? Can we do something like we do for the admin menu? See trunk/src/wp-admin/menu.php#L111​.

We could support other icons directly, although I'd definitely rather not since we don't need to for back-compat (unlike the admin menu) and because pngs can't be recolored/resized if we ever want to do that, and doing that with SVGs can be tricky.

It would be pretty easy to specify a custom icon with CSS (either from another icon font or using a background image), especially since they can use any class. I'd rather keep it simple and start with more limited support, then add additional options later if there's a lot of demand for them, but I really don't think we should directly support custom icons here, at least for now. We should also add a few dashicons for common sections, per #29855, and could consider doing some things like widget icons do, making smarter decisions for fallback icons. But I don't think that's needed for the first pass.

[ocean90]

This

add_action( 'customize_register', function() {
	global $wp_customize;

	$wp_customize->add_panel( 'foo', array(
		'title'    => 'Foo',
		'capability' => 'customize',
		'priority' => 1,
	) );

	$wp_customize->add_section( 'bar', array(
		'title' => 'Bar',
		'capability' => 'edit_posts',
		'panel' => 'foo'
	) );

	$wp_customize->add_setting( 'foobar[foo]', array(
		'default'    => 'Foo',
		'capability' => 'edit_posts',
		'type'       => 'option',
	));

	$wp_customize->add_control('foobar', array(
		'label'    => 'Foobar',
		'section'  => 'bar',
		'settings' => 'foobar[foo]',
		'type'     => 'textarea',
	));
});

produces 28504-icon-over-title.png​.

[celloexpressions]

Fix removal of icons in panels

[celloexpressions]

Oops, I had the padding change but forgot to hide icons in sub-panels. There shouldn't be icons in panels because all sections within a panel should have similar functions, so it wouldn't make sense for them to all have similar icons. 28504.3.diff​ should do it.

[SergeyBiryukov]

With src/

[obenland]

FWIW, I'm not a huge fan of the icons either. They feel repetitive, especially when the same ones are used between a section and a menu item, in different contexts.

Looking at the latest patches, what do you think of adding the dashicon- prefix on output in class-wp-customize-panel.php and class-wp-customize-section.php? Shouldn't they be escaped too?

[celloexpressions]

Replying to obenland:

Looking at the latest patches, what do you think of adding the dashicon- prefix on output in class-wp-customize-panel.php and class-wp-customize-section.php? Shouldn't they be escaped too?

By not assuming a dashicon prefix, we would allow other class-based font icons, or targeted background-image icons to be used (16) without worrying about potential conflicts with future dashicons. Also makes it clearer that it's a dashicon they're using when they add the icon.

We should probably add esc_attr() around the icon output, though.

[DrewAPicture]

Replying to celloexpressions:

We should probably add esc_attr() around the icon output, though.

Should probably use sanitize_html_class() there, there and a few other places nearby instead of esc_attr().

[folletto]

I'd rather keep it simple and start with more limited support, then add additional options later if there's a lot of demand for them, but I really don't think we should directly support custom icons here, at least for now.

Agreed. Also having something distinctive (either no icon, or a dimmed icon, or a placeholder icon) for the "extra" ones add a clear signal to the user to what's custom and what's native, something that people struggle with. :)

[celloexpressions]

sanitize_html_class

[celloexpressions]

28504.diff​ adds escaping. I don't have a screenshot handy, but the default gear icon seemed to work pretty well in my testing.

[ocean90]

Let's put this together with #28784.

[iseulde]

has-patch 4.2-early so moving to 4.2.

[ocean90]

Moving back until we have a plan to tackle this.

[celloexpressions]

Refresh.

[celloexpressions]

Refreshed in 28504.6.diff​. Unless I'm missing something, this is ready to go.

[paulwilde]

There's a minor typo in the patch "Dasicon".

[celloexpressions]

Fix typos.

[celloexpressions]

Fixed the typo in .6.2.diff.

[helen]

I find this to be visually quite heavy and a bit distracting. Is the goal still a different "collapsed" mode? The current collapsed mode is more "hide" so you can see the site at the full browser width.

[celloexpressions]

The proposed new collapsed mode is in #29949. We should get this in first rather than continuing to try to keep a combined patch in sync, but if icons happen in the next couple weeks we shouldn't any issues getting the rest into 4.3.

The design is https://core.trac.wordpress.org/attachment/ticket/29949/customize-collapsed-after.png, which provides quicker access to controls entering and exiting the mode, while also address the issue of mistakenly being in the Customizer preview vs. previewing the actual site, while still giving an almost-full-width view.

We should also keep in mind that the navigation will (thoertically) no longer be displayed at the same time as options UI, so you'd only see the icons in the context of navigating to a particular section once #31336 happens.

[valendesigns]

I really like the idea of having icons and I think we should 100% support them, but I'm not necessarily convinced they should be turned on by default for core sections. And if they are, there should be a way to turn them off if you don't want them.

[folletto]

Basic brightening of the icons

[folletto]

I'm ok with either with or without, and I see @helen's point on weight — but an option to me seems overkill for such a detail. Let's try to make it less heavy visually and see if it work. If it doesn't, we don't add them or find a different way.

Here's a quick mock with a lighter version:

Another option could be to shrink them to 16px.

[celloexpressions]

I'm fine with a lighter color, what exact color would you prefer? (or feel free to update the patch) May also help to tint them slightly blue as many of the grays have been recently. Unfortunately we can't really change the size without losing clarity because dashicons are designed to a 20px grid. Ideally we'd match the admin menu directly, but we're using a light UI here instead of going with the dark navigation pattern of the admin, so there're much fewer options in terms of contrast and hierarchy.

[folletto]

Customizer Icon Color Selection (Palette of 4)

[folletto]

Ok, I just uploaded four options based on the WordPress.org design handbook:

1. Silver Gray
2. Light Silver Gray
3. Medium Blue
4. Medium Blue / Tone 60%

I have probably a preference for "Silver Gray" since it matches a bit more the colors on the page, and "Medium Blue / Tone 60%" because it matches the button.

If she can, I'd love a check by @melchoice on this one tho. ;)

[valendesigns]

I would like Silver Gray with a Medium Blue / Tone 60% hover.

[valendesigns]

Though, if we end up doing a blue hover on the titles then I suppose a white hover would be appropriate.

[celloexpressions]

Silver gray looks the best, and the arrow icons should match that too if they don't currently.

[melchoyce]

I'm not super convinced the customizer needs icons, for a couple reasons:

• We're putting a greater burden on people extending the customizer (like .org theme authors, who are now required to put their theme options in the Customizer) to pick (and maybe eventually add their own) icons, some of which might not easily be represented by an icon. Using an icon poorly can actually decrease the overall understanding of the section and confuse users.
• Related to that point, we should not be using the same icon for two different parts of the admin. (This is actually something @jenmylo has been drilling into my head for the entire time I've been working on core.)
• Visually, I agree the icons are very heavy. I actually think the grey icons are worse, because they start to feel really muddy and blurry, making them harder to understand.

I'm worried we're starting to get a little "icon happy" in the admin. We don't need to add icons everywhere.

[folletto]

I'm quite neutral on the subject of icons here — but I agree on all these points.

I'd be fine either way.

[ocean90]

Replying to melchoyce:

We don't need to add icons everywhere.

+1. Moving this ticket out of 4.3 for now.

[celloexpressions]

If we're not going to do this, let's just close the ticket once and for all rather than spending another year just sitting on it. If anyone else has opinions in favor of this, now would be the time to say something about it. I'm still in favor of adding icons, fwiw.

[samuelsidler]

Based on comment:47 and comment:48, I'm going to call this a maybelater. If/when it makes sense, we should re-evaluate adding icons to the Customizer, but it doesn't make sense today and with the current design.