Twenty Fourteen: Audit Theme Customization Options

[celloexpressions]

Right now there are too many options that don't do enough to customize Twenty Fourteen. Let's fix that.

Specifically, here are some candidates for removing:

• I see no reason to have the ability to hide the header text
• If the header text color is customizable, that color control should change all of the white text in the navbar, sidebar, and footer (ie, it shouldn't be a header text control)
• So, do we really want the custom header feature at all? Having the header itself requires us to use $( window ).on('scroll' ... JS, which is laggy and one of the reasons we removed the fixed navbar in Twenty Thirteen
• Do we really need a custom background feature? This is more necessary since we're not doing #25013 (one of the reasons I wanted to do that). For the sake of simplicity, would a custom background color, but not image, be sufficient, since the background is only in the right margin?
• The "Theme Options" section should be renamed to something like "social links". But is it a theme's position to specify these? Even when switching to a child theme, they need to be re-entered. This seems like plugin or maybe core territory.

Additionally, here are some things that would be useful if added:

• The green and lighter green colors should be customizable with a color picker (call them "accent" colors?)
• It would be nice if the black header/right sidebar/footer background color could be changed. There would be a lot of flexibility there if the text color could also be changed, but still a fair amount without that.

I'll hold off on patching anything until this is discussed.

[cainm]

I see no reason to have the ability to hide the header text

If the header text color is customizable, that color control should change all of the white text in the navbar, sidebar, and footer (ie, it shouldn't be a header text control)

Both of these are core features, and good examples of how to use them. There are a number of use cases for both, but specifically for the first, a user may want to set a custom header with a logo and remove the redundant header text.

As far as the header text color goes, I don't think we should be automatically setting all header/sidebar links the same color as the header - a user might just want their site title to be a different color.

So, do we really want the custom header feature at all? Having the header itself requires us to use $( window ).on('scroll' ... JS, which is laggy and one of the reasons we removed the fixed navbar in Twenty Thirteen

The fixed header adds a lot to the design of this theme. I believe the removal of Twenty Thirteen's fixed navbar came down to just a lack of support for keeping it, not necessarily concern about the speed of the JS. I vote to keep the header.

Do we really need a custom background feature? This is more necessary since we're not doing #25013 (one of the reasons I wanted to do that). For the sake of simplicity, would a custom background color, but not image, be sufficient, since the background is only in the right margin?

Another good implementation of a core feature. I think that not fixing #25013 should be a vote in support of leaving the custom background feature, since larger viewports will be able to see this area.

The "Theme Options" section should be renamed to something like "social links". But is it a theme's position to specify these? Even when switching to a child theme, they need to be re-entered. This seems like plugin or maybe core territory.

Although I agree that Social Link functionality could be pulled out into a plugin, one doesn't exist yet, and the social links in the connect bar are a nice addition to the theme. Vote to leave unless a core plugin is started.

[sabreuse]

I'd agree with changing the label "theme options" to something like "social links" since that's all that's in that section. (Incidentally, I don't think they should be in a plugin, because they're so tied to the theme's design.)

+1 to the suggestion of customizing the green to use some other highlight color.

But I disagree with all the other suggestions here, for reasons @cainm explained very nicely.

[MikeHansenMe]

I see no reason to have the ability to hide the header text

• Some people do not like to show this at the top and it is a core function so I think we should leave it

If the header text color is customizable, that color control should change all of the white text in the navbar, sidebar, and footer (ie, it shouldn't be a header text control)

• This is a core function as well but lets leave it as is and not try changing anything else based on it.

So, do we really want the custom header feature at all? Having the header itself requires us to use $( window ).on('scroll' ... JS, which is laggy and one of the reasons we removed the fixed navbar in Twenty Thirteen

• I am fine with removing this, if we leave it thought it looks like the gap problem still exists with a custom header image

Do we really need a custom background feature? This is more necessary since we're not doing #25013 (one of the reasons I wanted to do that). For the sake of simplicity, would a custom background color, but not image, be sufficient, since the background is only in the right margin?

• I think a background image is a good thing to leave it allows everyone using the theme to change it just a bit.

The "Theme Options" section should be renamed to something like "social links". But is it a theme's position to specify these? Even when switching to a child theme, they need to be re-entered. This seems like plugin or maybe core territory.

• Usually I feel things are plugin territory however this is tied closely with the theme and should stay IMO. Fine with renaming it.

Additionally, here are some things that would be useful if added:

The green and lighter green colors should be customizable with a color picker (call them "accent" colors?)
It would be nice if the black header/right sidebar/footer background color could be changed. There would be a lot of flexibility there if the text color could also be changed, but still a fair amount without that.

• this would be a cool feature but could be built in a plugin

[obenland]

I'd like to keep the header and its functionality around (for now).

In Twenty Thirteen, not supporting custom backgrounds made sense, but it's such an easy to implement feature that I think we should just keep it around.

I'd like to axe the Theme Options completely. And possibly make the search field work like in Twenty Thirteen.

[celloexpressions]

Let me clarify the "why" of this ticket (I sense an underlying "why would we remove these wonderful features"). Obviously, I'm not suggesting that we remove features for the sake of removing features, or even because of code bloat. I'm more worried about user experience and ​decisions, not options. Since decisions not options is a core philosophy, and Twenty Fourteen will be the default bundled theme, we should be deliberate about what options we're packaging with the default experience. It makes much more sense to add functionality with plugins than to overwhelm new users with functionality that's there because it only takes a few lines of code and could be useful for some users. I think Twenty Thirteen and ​Thirteen Colors are a good example of adding edge-case theme options via a plugin; users who want more advanced features are also more likely to know to look for plugins. On the other hand, we need to make sure that users have the ability to easily customize their site to some extend; my primary goal with this ticket is to work on finding that balance.

So, with that out of the way, here are some more specific thoughts on the feedback others have left:

• Is anyone against adding one or more colorpickers to customize the default green accent colors? This is one case where I think a majority of users would appreciate a default UI for customization. I see at least three different shades of green; should we generate lighter and darker variants of a custom color or include multiple color pickers for this?
• The main reason I'm unsure about the need for a header image is that there is no image by default, the demo site has no header image, and none of the sites running Further/Twenty Fourteen that I've seen use it. I didn't even realize that the custom header feature was being used in Twenty Fourteen until I started digging through the code (I was suspicious of the header text controls in the customizer, since the header image section is not present until images are uploaded). That's clearly a problem with the core feature, but combined with the lack of use, decisions not options, and the javascript thing, I think we should consider whether we really need it (and fix the core implementation at least of no-image-by-default header UI if we do need it). Twenty Thirteen didn't do custom backgrounds, maybe Twenty Fourteen shouldn't do custom headers (which would also further distinguish it from previous default themes).
• Thinking from a (first time) user's perspective, the "Header Text Color" label logically applies to all of the text in the sticky header, not just the site title. The only reason that this option would make sense as title-only would be following conventions from other themes. And generally, just because the customizer gives the user instant feedback about exactly what a given option does doesn't mean that it shouldn't be clear before any interaction and behave logically. A user that wants just the site title to be a different color is probably an edge case.
• "Display Header Text" again seems referable to all of the text in the header, not just the site title (especially for users who can't differentiate navigation from text). And that really doesn't make sense. It looks like we can keep header images but drop the header text color and header text controls by specifying 'header-text' => false in twentyfourteen_custom_header_setup(), perhaps that's worth considering?
• To clarify, I think we should consider dropping header image support in order to improve the fixed header. The fixed navbar in Twenty Thirteen (#24184) had a fair amount of support, but not from most of the final decision-makers. We'll need to add a whole bunch of additional JS to make the fixed header work in IE (as we did in #23841 for Twenty Thirteen). It currently doesn't work at all in IE (including 10), see (#25144). So in summary, rather than going down the same path as in Twenty Thirteen and potentially eventually removing the (much more functional) code-heavy Twenty Fourteen header, let's seriously consider whether a currently barely-if-ever-used feature (header image) is more important. If we drop header images we can do the header without js.
• I do think we should keep custom backgrounds because we aren't doing #25013, I was just including that for completeness. I would be interested in the percentage of users who would prefer the #25013 suggestions over having a more visible & customizable background, though. Slight annoyance: the majority of users won't be able to see the background at all in the customizer.
• The social links thing is an interesting issue. I also like the design direction and think that this sort of thing should be implemented in a default theme since it's difficult to integrate the design with a non-theme-specific plugin. But I think the current configuration is a non-option because of the annoying UX of where the data is stored (and how easily it is lost). This seems like a good opportunity to seriously consider storing some social information in core or having a (permanent) core plugin for it. Having a canonical place for social links would ultimately be a better user experience than adding social details for every social plugin/theme that needs the data. But on the other hand, it's more bloat and the concerns about user-specific social media in #11541 are applicable here as well. Long-term maintenance and potential eventual removal would also be strong arguments against putting it in core. The easiest solution for Twenty Fourteen is removal of that feature entirely, unfortunately.

Sorry that was so long, but I think it's important to take a step back and look at this from some different angles. And of course, this requires a lot of discussion since there are so many components involved.

[obenland]

Nice write up, Nick! Let's talk about it during office hours tomorrow and make decisions on those.

[nacin]

I'm +1 for everything celloexpressions just said.

[cainm]

Is anyone against adding one or more colorpickers to customize the default green accent colors? This is one case where I think a majority of users would appreciate a default UI for customization. I see at least three different shades of green; should we generate lighter and darker variants of a custom color or include multiple color pickers for this?

I can get behind a single "accent color" option in the customizer and then generating the lighter/darker shades.

As far as the Custom Header goes, your point about the header image being missing from the demo site and how infrequently it is used is a good one. It would be interesting to hear iamtakashi's opinion on its inclusion (there might not be a reason more than header images being a .com requirement, which is definitely not a case for keeping it in Twenty Fourteen), but I'd be up for removing it.

I'd love to keep the social links, but agree that it's current implementation isn't ideal. What would you think about something like a theme hook and a plugin?

[obenland]

In todays office hours, we decided ​to remove the custom header, but ​keep custom backgrounds around.
We ​did not come to specific conclusion about the fate of Social Links, but ​will re-iterate on Thursday.

For now need a patch to remove the custom header functionality and its styles.

[DrewAPicture]

remove custom-header

[DrewAPicture]

25094.diff​ removes the custom header bits. Did I miss anything'?

[obenland]

The header image is in #site-header, not .site-header. Other than that is seems fine.

[DrewAPicture]

25094.2.diff​ removes #site-header instead, good call @obenland.

[celloexpressions]

I added a patch to #25144 that cleans up the sticky header code so it doesn't need to account for a header image and works in all browsers.

Other thing to discuss Thursday is the potential to add controls for anything else (I'm thinking customizing the green color would be the most useful). We should strive to make the theme customization tools as useful for the average user as possible, and I think we're fine adding one new control along with removing three less useful ones.

[celloexpressions]

First-pass at adding an "accent color" option, and generating the needed shades from it to override all of the default greens

[celloexpressions]

25094-accent-color.diff​ is a first-pass at an accent color option. The value defined by the color picker overrides all instances of #24890d from style.css.

Additionally, alternate shades are generated to replace the two other default shades of green, #35921f and #5ff23d. Here are some notes on the direction I took with the math for the offsets I used. Note that we need to adjust the default colors slightly:

1. Base color: links, ::selection, search/social default
#24890d = rgb(36,137,13)

2. Search/social box hover/active, button hover
#35921f = rgb(53,146,31)
base offset: (17,9,18)
proposed generated offset: +14
resulting default value: #32971b = rgb(50,151,27)

3. Link hover, active buttons
#5ff23d = rgb(95,242,61)
base offset: (59,105,48)
proposed generated offset: +71
resulting default value: #6bd054 = rgb(107,208,84) (visually muted but works well)

alternate option for 3: offset of 54 but use 105 for highest base value r/g/b
resulting default value: #5af243 = rgb(90,242,67)

The algorithm works by converting to rgb, adding the offset value to each r/g/b value, then converting back. Applying the same offset to each vaalue ensures a similar hue with primarily a change in brightness.

The selectors are currently a bit verbose, but that's what we have in style.css right now (I concatenated all instances of each color). Because we're generating colors and there are so many selectors, I think it's best to stick with 'transport' => 'refresh'. I'd also rather do the output in wp_head so we can keep all of the customizer stuff in customizer.php (which will pretty much only have this once the social links are removed). We can also apply these customized colors to the editor styles; probably only needs the base color, for links and ::selection.

In terms of the UI, this is fantastic. Users can use a very wide range of colors without things visually breaking (even fairly light/dark), and the generated variants seem to "just work." The variants are subtle enough that I don't think many users will want to customize them separately, and by generating them from the original color, Twenty Fourteen retains a cohesive look. Since this changes all of the non-grayscale colors in the theme, the resulting look is pretty custom with minimal effort.

Next step is to discuss possible improvements to the implementation and address any concerns.

[obenland]

What do you think about calling it Link Color, like in Twenty Eleven?

We could make twentyfourteen_adjust_color() a sanitization callback, and return an array of the initial color and the two derivatives. We could call it in twentyfourteen_customizer_styles() with

<?php
list( $link_color, $accent_light, $accent_dark ) = get_theme_mod( 'link_color' );

This way we have to calculate the colors only on save and not on every page load.

In $wp_customize->add_setting(), type, capability, and transport can be omitted, these are their default values.

Could we also use wp_add_inline_style() in twentyfourteen_customizer_styles()?

[celloexpressions]

Generate accent color variants on save, only output color overrides if using a custom color

[celloexpressions]

25094.accent-color.2.diff​ implements obenland's suggestions and also only outputs the color overrides if a custom color is selected (borrowed from Twenty Eleven); this way, child themes and custom css aren't overridden. We can also keep the current shades for all three default colors, since they aren't generating.

I think Accent Color is better because we're changing more than just the links. This control lets you change all of the colors in Twenty Fourteen other than the background and grayscale tones. While that isn't much beyond the links (notably, it covers the header search button and the text selection color), I think the visual impact warrants a more substantial label.

In terms of the internal variable names, both generated colors are actually lighter than the original, so I'm not sure what the best naming convention would be.

I would like to apply the primary accent (or whatever we call it) color to the editor stylesheet for links and ::selection but the only method I know of to do that requires creating a file; anyone know a better way to load a few lines of css into TinyMCE?

Revisiting the color generation itself, anyone else think we should lighten the first generated color a bit more than 14 steps? The best place to test the contrast between those shades is the normal and hover states of the search button; I've found the contrast to be small enough to look unintentional for several initial colors.

[celloexpressions]

Just noticed a bug - we'll need to extract the primary color from the array when the customizer first loads. Closing then reopening the customizer currently throws a ton of errors.

[obenland]

Replying to celloexpressions:

Just noticed a bug - we'll need to extract the primary color from the array when the customizer first loads. Closing then reopening the customizer currently throws a ton of errors.

Yes, not sure what I was thinking there. Giving both values their own theme mod should work just as well. Prior to passing $color to the adjustment function, we should sanitize it with sanitize_hex_color().

[celloexpressions]

Don't save as an array, but save all three colors as theme mods. Add style tags (see [25202]).

[lancewillett]

In 25214:

Twenty Fourteen: remove Social Links integration. Props obenland, see #25094.

[lancewillett]

Loving the ideas and directions here. Could we split the ideas and concepts into new tickets, please? It'll allow them to be worked on independently.

[celloexpressions]

See #25220 for the additional color picker (plus a refreshed patch).

I think the only other component we decided to change is the removal of the header image, which has a straightforward patch here that's probably ready to go in.

[lancewillett]

Discussed the removal of header image support at length again today in Twenty Fourteen office hours. ​Chat log.

Here's some data from WordPress.com Further usage (the theme that became Twenty Fourteen).

• Roughly 47% of current Further sites have an active custom header image.
• Here's a sample list of sites that you can look through to see how and why they might have chosen to use the header image: ​https://gist.github.com/lancewillett/6427469

[goofydg1]

Why can't the header be left as a configurable option. uncheck it if you don't want it.

[MikeHansenMe]

After looking through most of those sites. I am in favor of keeping custom header images in Twenty Fourteen. A lot of the sites looked pretty good with their header image. Some did not look very good but I think that happens with all themes.

[lancewillett]

Discussing in office hours today (​log). Since the header image (and the color and hide text options) are core Appearance I think it's smart to let authors decide to use them or not. *Not* deciding as theme creators that not very many people will find them useful so we should remove them.

One compromise is disabling the "change header text color" option if we implement the accent color option.

Next steps:

1. Work on IE support for header image + fixed navbar. See #25144.
2. Work on accent colors: #25144