Explore Custom Colors

[celloexpressions]

Once the design is implemented (#4), I'd like to explore potential custom color options. A lot of sites will be using this theme, and for sites that have less image content, custom colors would offer a way to skin the theme to convey a unique identity that would otherwise come largely from images.

I'd like to start by analyzing the completed stylesheet and all colors used. From there, we would look at what might make sense to be customizable, and which colors could be automatically set or generated based on user selections. @melchoyce could guide the ways that this dynamic design element can control the look and feel of the theme.

This is how the Fourteen Colors plugin, which started out as part of the Twenty Fourteen theme works. We'd leverage this technique to get instant live previews. This approach for custom colors works best when there are 1-3 user-selected colors, and everything else is handled automatically. We can also integrate with the customize notifications API to warn users when there is insufficient contrast in their selections, where applicable.

[josephfusco]

@kevinwhoffman was looking into a way for having these custom colors showing within TinyMCE which would be awesome.

Ref: https://make.wordpress.org/core/2016/08/17/wordpress-4-7-whats-on-your-mind/#comment-30869

[kevinwhoffman]

Thanks for the mention @josephfusco. I would be happy to incorporate TinyMCE styling to match the customizer. I worked with @mathetos on the Twenty Sixteen proof of concept you see above, but it can be adapted to work with any theme that stores customizer settings as theme_mods.

@celloexpressions I agree that for an image-heavy theme, a few color schemes would go a long way in terms of customization.

[celloexpressions]

I have completed an initial analysis of the theme's style.css file for color patterns. The results are in this gist: https://gist.github.com/celloexpressions/64e69ae9f6b5a47d97f77d230d0e7967.

The first file there contains a direct reduction of style.css, removing all non-color properties. The second file combines all selectors for each property and sorts them by color, dark to light; this would be the basis for a colors template. Here is a list of the colors used:

• #c0c0c0
• #ff9c0
• Need to add pingback in header.php #111
• Hover link effect legibility issues #222
• Fixes post date, title, and content vertically misaligned. #333
• #666
• #767676
• #707070
• #999
• #bbb
• #ccc
• #ddd
• #eee
• #fafafa
• #fff

Looking at how infrequently a could of these are used, I think a few could be combined. @melchoyce can you look through these? We also need to address some cases where there is inadequate color contrast in the base scheme, most notably with the social icons being #bbb on #fff right now.

The next step is to identify colors and groups of colors that could be made into options. A few ideas I have initially:

• Accent Color, for the mid-range grays (#767676 to #999)
• Background Color, for white and the light grays (#fff to #bbb)
• Text Color, for the dark grays, or this could be automatic based on the background color and always either light or dark grays (Need to add pingback in header.php #111 to Fixes post date, title, and content vertically misaligned. #333 and #666, with #666 as the user-selected color)

For any of those, we would generate colors by lightening/darkening the selected color proportionally to the amount of contrast difference with the base theme colors, to maintain the same hierarchy between colors. Since everything is gray by default, there doesn't seem to be a lot of room for adjusting these while maintaining color contrast, but introducing color will open up numerous possibilities there.

[melchoyce]

Consolidated the extraneous colors in #139 to get down to my original nine style guide colors. I'll take a look at the rest tomorrow.

[celloexpressions]

Thanks, that helps clarify the intent.

A few more (mutually exclusive) ideas:

•      User selects a hue that all colors are based on, monochromatically, with #fff remaining white
  

•      Light and dark color schemes, based on directly inverting all of the default colors, plus an accent color
  

•      2-4 user-selected colors, with generated variants for the remaining colors
  

If we go the user-selected route, the key decisions are which colors to group together, which color in each group is selected with the rest being generated, and what color contrast restrictions are imposed.

[melchoyce]

User selects a hue that all colors are based on, monochromatically, with #fff remaining white

This is an appealing option.

Light and dark color schemes, based on directly inverting all of the default colors, plus an accent color

What are you thinking re: accent color?

Worse comes to worse, we could go Twenty Sixteen's route and do a light (default) and dark (inverted), with a couple monochromatic schemes generated like the first option, but we curate the colors used.

2-4 user-selected colors, with generated variants for the remaining colors

Slightly less appealing than the first option IMO, just because color schemes are hard and giving people lots of color options doesn't always result in great color schemes.

[celloexpressions]

Since the theme is strictly monochromatic out of the box, it would be interesting to try that approach and see how it works.

The accent color would probably be used for secondary elements and things that currently use middle-gray colors, like #767676 and #bbb. I haven't looked closely at where each color is used.

If it is more on the user-selected side, I'd definitely lean toward fewer options, potentially only letting them change accent and background, for example, and generating the rest. This route or monochromatic still give users more control/customization than presets, while ensuring that the theme looks good regardless of their choices.

[melchoyce]

#767676 is mostly used for meta information — dates, post taxonomies, some comment meta, etc. #bbb is mostly used for borders/dividers. The only place I see accent colors really working well are links and buttons.

[celloexpressions]

What about three radio buttons:

Color Scheme

• Light
• Dark
• Custom Color

Where custom color shows a hue picker that applies the custom selection monochromatically? That seems like the best approach for this theme, assuming that we can get a hue-based monochromatic option working well. The light/dark options also work around the fact that you couldn't select those with a hue picker.

[melchoyce]

I'm up for trying that 👍

[celloexpressions]

Awesome, I'll take a first stab at it tomorrow.

If anyone has technical suggestions for mapping a user-selected hue to a particular shade, let me know. I'm currently thinking that using hsl colors will be the best approach, with the user-selected hue, an arbitrary saturation, and lightness at each of the nine color levels from the equivalent gray. The relative luminance (used for contrast checks) would diverge slightly from the lightness used with this approach, so we may need additional internal logic to correct that, but we'll see how it works. We can also consider mapping those values back to hex colors if we want to support IE8 and older.

[celloexpressions]

There are three selectors that are the only instances of colors still:

.site-description {
    color: #777;
}

.entry-footer .cat-links:before,
.entry-footer .tags-links:before {
    color: #999;
}

Should those be standardized to #767676 and #bbb? Not a big deal to keep them as is with the hsl approach, but wanted to double check.

[melchoyce]

Should those be standardized to #767676 and #bbb?

Yeah, that would be great.

[celloexpressions]

Perfect, I'll take care of it in my coming PR for testing (I actually just got to the #999).

[celloexpressions]

#167 has a first pass of an implementation of this. Here's a screencast:

I think this works quite nicely. The implementation is very straightforward, even with instalt live preview in the customizer. By preserving the exact color hierarchy of the theme and only changing hue, we can ensure that the original design intent is maintained and avoid implying things with color.

Color contrast is good for most hues, although it can have issues for a few. This is because the current approach uses lightness, which diverges from relative luminance (which is used to calculate color contrast). We could introduce corrections for that, but it's not bad,

The saturation is arbitrary and filterable. If needed, we could adjust it for certain colors/selectors

The dark scheme runs from a separate stylesheet. Right now it inverts all of the colors directly (I did it in my head quickly, so a few may be a bit off), but we can design this out. I'd suggest going lighter in general rather than all the way against #000 (based on the default going all the way against #fff.

[celloexpressions]

Oh, and the hue picker is currently a slider, if we decide to proceed with this we'll build out a hue picker control.

[josephfusco]

Here are some thoughts on it so far after testing locally.

• We shouldn't have the dark option go full #000 for the background but rather Fixes post date, title, and content vertically misaligned. #333 as that is the main text color.
• The hue slider should have a visual representation (just read your previous comment 👍 ).
• Defaults are inaccurate. The default .site-title is Hover link effect legibility issues #222 but the default button for header reverts to #000.
• Custom hue slider should not show unless custom is selected.

[celloexpressions]

@josephfusco yeah, I forgot to say that as well, but the hue picker will show only when custom is selected, and the dark scheme needs to be designed out rather than being a straight inversion.

I'd like to eliminate the header text color option, unless we feel it's critical to be able to change that over a video/image. In most cases something like a shadow would be needed to ensure it's always readable anyway. But I haven't touched that yet here since it's separate.

[melchoyce]

Does Iris have a hue slider we could borrow? The unlabelled slider is super ambiguous — there's not way to know what it is until you use it, and even then you can't easily look for colors. Something like Sketch or Photoshop's hue sliders would be more clear:

Functionally it looks pretty fun :)

[celloexpressions]

Cool, I wanted make sure we want to go with this approach before implementing a hue slider that shows when "custom" is selected, since that'll be a bit more work. We should consider moving that custom control into core when the theme is merged. I'll put that on my todo list.

@melchoyce can you design out the dark scheme in the meantime? Essentially a matter of selecting the dark scheme equivalent for each color.

[celloexpressions]

Iris doesn't seem to support a hue-only option currently, but it shouldn't be too difficult to add. We'd want that to work with numerical hues (0-359 degrees), but all of the UI is there and just needs to be separated out from the full color picker layout.

This piece will require a core patch for the Iris color picker, wpColorPicker, and WP_Customize_Color_Control, which would all add a mode called hue that shows a hue picker only. Is anyone from Automattic who has worked on Iris before interested in contributing here? If this is a go, I can make a core ticket for this to get the ball rolling.

The hue picker is definitely doable in 4.7, but better committed after the theme is merged into core. Can we clean up the dark color scheme, then merge this into the theme as a slider, with the addition of a description indicating that it'll become a hue picker after core merge? If we wait, it'll be much more difficult to keep the color files synced with style.css, and we'd also lose out on a lot of testing for the functional parts here.

[josephfusco]

Instead of the radios can we use a select like Twenty Sixteen? Thoughts?

[celloexpressions]

Radio feels better to me since there are only a few options, and requires fewer clicks/taps. Twenty Eleven takes this approach if we look all the way back to that, but Fifteen and Sixteen use select plus several (too many) individual color pickers. I think they're equally appropriate in terms of accessibility.

[kevinwhoffman]

@celloexpressions Nice work on the demo. One concern I have in regards to automating the color scheme is that many users will begin their site with their brand colors already defined. As a business owner, I want the ability to specifically set the hex value for the background color of the header.

I understand the merits of the automated approach. It prevents the uninformed designer from going off the rails. It generally ensures contrast is maintained for accessibility purposes. It is technically impressive. All good stuff.

However, it also takes a great deal of control away from the user or designer who does have a specific color scheme in mind. In that regard I feel this is a step backwards from Twenty Sixteen. I'm wondering if the following would be possible...

• User selects Custom color scheme.
• They enter hex values for their base color and accent color.
• The rest of the colors appear with values defined by your calculations.
• Here's the difference. Those colors can still be tweaked by the user.
  • For example, maybe I want my accent color to be red, but I don't want the text across my entire site to take on a red hue. I should be able to have red buttons without red text.

With this approach, we can still provide a great starting point for users with a custom color scheme, but they have control. I don't feel like this is one of those "decisions not options" scenarios. We're talking about the visual identity of the site—the outward projection of the user's identity. They should have control over it even if the theme guides them along the way.

[mattwiebe]

Does Iris have a hue slider we could borrow?

Not directly, but I can probably be convinced to introduced a hue slider-only mode. It wouldn't really make sense to use something else to me.

[melchoyce]

Here's what I'm thinking for a dark scheme:

#222 —> #fff
#333 —> #eee
#666 —> #aaa
#767676 —> #999
#999 —> #666
#bbb —> #555
#ddd —> #444
#eee —> #333
#fff —> #222

...With the exception of the header text, which should stay the same on the homepage (but change on interior pages).

That looks like this:

• Home mockup
• Post mockup

[celloexpressions]

Looks good, I've updated the PR accordingly for the dark color scheme. This should be ready to merge, then the hue picker can be implemented once core adds it in https://core.trac.wordpress.org/ticket/38263. @mattwiebe do you have time to work on the core/Iris part? I'm not familiar with the internals of Iris.

[davidakennedy]

For reference, #167 is where the colors are at currently.

Overall, I like where the colors are. This should give users some choices and eliminate the need for many schemes. I do think that with most color choices don't look as good as the default scheme or dark scheme. It just doesn't have the same punch.

It's fun to play with the slider. Its accessibility isn't bad, and I hope the hue picker is solid too.

I noticed a few inconsistencies:

Scroll down button: https://cloudup.com/cyLE98qc0OS
Hover color doesn't change. Should it? https://cloudup.com/cVzRVeNW6-X
Page title don't change: https://cloudup.com/caWXQ4B3SeD

I'm cool with moving forward on this, but leave the final call to @melchoyce since this is design related.

[melchoyce]

Some more color mis-matches:

Post excerpts on static front-page blog sections

Shadow overlaying the section featured images shouldn't be reversed

These pass color contrast but feel dark to me, can we lighten up the hover color to #bbb?

Can we try reversing input colors as well?

Hue slider

Pretty fun. How would you feel about desaturating quite a bit, though? Instead of 80% saturated, can we try 40% instead?

I also think we'll need to even further desaturate borders.

[celloexpressions]

I lightened the dark scheme colors, removed the inverted gradient, and fixed in inversion of inputs.

In terms of saturation, you can test by changing the number where it's defined at the top of color-patterns.php. It's filterable, but we can set the default to whatever you prefer. My only concern would be that the colors become too subtle beyond a certain point, especially for the lighter colors. 40% feels kind of... boring to me. 60% feels a bit better. If certain mid-range colors feel too saturated, we can take a percentage reduction off of the defined saturation for those.

For the bugs brought up, as I mentioned previously we need to re-sync everything that's changed in style.css. If we were to keep trying to do that before merging, we'd never merge, so I'd prefer to do it all at once after the initial merge is in. Don't bother looking for bugs like this in the meantime, though, as going through the commits and merging changes is the only way to capture everything. If someone wants to do that now, go for it, but I'd prefer to wait so there's a clear place to start from and go to.

[melchoyce]

In terms of saturation, you can test by changing the number where it's defined at the top of color-patterns.php. It's filterable, but we can set the default to whatever you prefer. My only concern would be that the colors become too subtle beyond a certain point, especially for the lighter colors. 40% feels kind of... boring to me. 60% feels a bit better.

Yeah, that's what I was editing when I came up with 40%. IMO, the body text is the biggest reason to decrease to 40% — it feels much too saturated higher than that. If we could decrease the saturation on the body text and on the borders, I'd be happy to leave the others around 50%.

Inputs look good. 👍

For the bugs brought up, as I mentioned previously we need to re-sync everything that's changed in style.css. If we were to keep trying to do that before merging, we'd never merge, so I'd prefer to do it all at once after the initial merge is in.

Cool — @davidakennedy how do you feel about getting this in as-is and iterating in new PRs?

[celloexpressions]

Added a quick commit to adjust saturation and reduce it further on #333. I won't be able to make any other changes here until tonight, but assuming that last commit didn't break everything I think this can go in.