Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#26220 closed enhancement (fixed)

Twenty Fourteen: remove Accent Color feature

Reported by: thomasguillot's profile thomasguillot Owned by: lancewillett's profile lancewillett
Milestone: 3.8 Priority: normal
Severity: normal Version: 3.8
Component: Bundled Theme Keywords: needs-patch
Focuses: Cc:

Description

The accent color could be a great idea but if a user select a very light color it doesn't look right (see twenty-fourteen-accent-front.png). Also it adds a lot of inline CSS code and it's something we should avoid (see twenty-fourteen-accent-source.png).

How about we remove this functionality and create a Theme Option where you can choose between a few different colors (where green would be by default)?

Attachments (4)

twenty-fourteen-accent-front.png (269.1 KB) - added by thomasguillot 10 years ago.
twenty-fourteen-accent-source.png (167.9 KB) - added by thomasguillot 10 years ago.
twenty-fourteen-theme-options.png (19.3 KB) - added by thomasguillot 10 years ago.
26220.remove-accent-colors.diff (8.9 KB) - added by celloexpressions 10 years ago.

Download all attachments as: .zip

Change History (24)

#1 @celloexpressions
10 years ago

The reason for the single color picker is decisions, not options (less reading, more visual choosing, adapt their single choice to replace every shade of green in the theme instead of giving them multiple places to work).

We'd need all of that css output if we had preset colors as well. By doing the colorpicker, users have a much broader array of choices (we see Twenty Fourteen with a unique shade of color that matches a given site, rather than always seeing something preset that doesn't quite fit). And, at least initially, a lot of less savvy users will probably just use the default colors present on the bottom of the color picker (they all work, except for white and yellow, obviously).

I doubt that anyone would pick a color that clearly doesn't work, it's pretty obvious in the customizer that anything lighter than lime green is a bad idea. The accent color is tied to the link color also, so they'd quickly realize that they made all of their links invisible (it's like a text color colorpicker). Users that want further options for changing color patterns (inverting light/dark text/background, which making the search icon light would mean) can use custom css and/or child themes. The accent color is designed primarily for changing the hue, but maintaining a similar level of contrast with the surrounding elements, like a link color option, but more robust. I think we can trust the user to see when a color is too light (or dark).

The fundamental problem with this ticket is that a light accent color also makes links and text highlighting invisible; it simply isn't supported by the default design. Suggest wontfix.

#2 follow-up: @rachelbaker
10 years ago

I understand your point about allowing any color value for the "Accent Color" option allows users to make poor choices.

Which colors would you offer as choices if we were to limit the option to only a handful of choices? Do you feel that offering these choices would result in the best experience for the user?

#3 @lancewillett
10 years ago

  • Milestone changed from Awaiting Review to 3.8

I agree that limiting to a few pre-set color schemes would be a better experience, and we could put the color CSS in real CSS files and load them when needed versus using the huge selector list like we do now, in PHP.

#4 @celloexpressions
10 years ago

We also have to contend with the desire for theme simplification, which could mean pre-defined colors. There are a few fundamental issues with pre-set color schemes:

  • We set up the expectation that they change more than just the accent color. To do it well we would need to design more comprehensive alternates, changing the sidebar/header color, for example (like WordPress.com custom colors, but without all of the options). That would be better than just accent color, but we might actually make things more complex. We'd definitely have more files.
  • As rachelbaker said, what colors would we choose? We could create some schemes that are similar to some of the color schemes that were in MP6, or come up with something new. But fundamentally, the interaction for changing it would need to be visual, not text-based, so we'd need to implement something like (maybe borrowing from) the new admin colorscheme picker.
  • There would inherently be both more options and less flexibility (depending on how far we go with tweaking other things besides accent color). Each choice is another option to read through, and we won't have the ability for people to get "just the right shade". In other words, I think a colorpicker is a far more appropriate interaction for a single-color option (generated variants don't count), but if it's more of a colorscheme, then a visual dropdown is necessary.

So it might actually be more complicated to do this than the single accent color colorpicker, though it would both increase and decrease customization potential (truly custom but only by the accent color, versus much different from the original look but still using a preset template).

If we end up deciding that we do need to remove accent colors for code simplicity, I think I'd rather see this type of functionality moved to a more comprehensive plugin than changed to a colorscheme dropdown.

#5 in reply to: ↑ 2 @thomasguillot
10 years ago

Replying to rachelbaker:

I understand your point about allowing any color value for the "Accent Color" option allows users to make poor choices.

Which colors would you offer as choices if we were to limit the option to only a handful of choices? Do you feel that offering these choices would result in the best experience for the user?

Regarding the colors I think we should ask iamtakashi since he's the designer but red, blue, orange, purple and maybe grey could work. With pre-set color schemes yes we would reduce users' choices but at least:

  • The color will perfectly work with the theme
  • The code will be much cleaner

If a user wants a different color scheme he can always create a child theme, copy a pre-set stylesheet and replace it by his colors.

#6 @iamtakashi
10 years ago

We discussed this at the contributors day in London and I like the suggestion from Thomas: providing a few pre-set color schemes instead of the color picker.

The biggest issue I have with the color picker is that, like what Thomas pointed in this ticket, we are providing an option that a user can make his/her site visually dysfunctional by choosing a very light color. It might be obvious for some users not to pick a very light color but I believe a good tool shouldn't even provide users choices that they can make their site dysfunctional. Since the current implementation of the accent color is not like WP.com custom color where we can provide dynamic contrasted colors (if so it shouldn't even be in a theme), I think it is the best to provide only good choices to users so that they can't make bad choices, and the theme will have much much cleaner code.

I like the color suggestions from Thomas but once we decide to go this route I'll think about the exact color choices.

#7 @iamtakashi
10 years ago

  • Cc takashi@… added

#8 follow-up: @celloexpressions
10 years ago

I'm fine with going the route of re-defined color schemes, as long as they change more than just the accent color and have an appropriate UI (we'd need to build something visual that shows the colors instead of just naming them in a standard <select>, see the new admin color scheme selector for inspiration). One alternative worth mentioning is to reduce the color picker to a hue picker, which would allow a wide rage of colors but maintain the necessary contrast.

But do we really have time to address this before the hard (no commits) freeze in 6 days? I'm not sure if we're still planning on shipping Twenty Fourteen with 3.8, looking at our 21 open tickets, but if we are, we may need to just extract the accent color entirely to a plugin.

I'll attach a patch that removes the accent color feature. I've already started putting together a plugin that has that functionality and the ability to change the sidebar/header/footer color, with automatic inversion of the text color when the background color becomes too light (let me know if anyone wants to collaborate). We would want to market this, and a plugin that restores the social links feature, if that happens, to Twenty Fourteen users (maybe on the Codex page?), to help them understand the concept of using plugins instead of (or in addition to) child themes for smaller customizations.

If we do end up taking more time to polish Twenty Fourteen, I'd love to further develop both the color schemes idea and a smarter version of the color picker idea, potentially both in plugins first. Then, we could evaluate both and see which is the better candidate for inclusion in Twenty Fourteen, based on functionality and code weight/complexity. Since Twenty Fourteen is a more complex default theme in general, I think it deserves a more complex built-in customization solution, but I agree that it should prevent users from creating critically low-contrast (or no-contrast) choices.

#9 follow-up: @iamtakashi
10 years ago

Not directly relevant so I'm just noting here. Once we decide to remove the accent color option, let's put the header text option in custom header back. We've received a few feedback/complains of the lack of the option from WP.com users. As far as I remember, the reason why we removed the option was the text color option was redundant because of the accent color, and it was tricky to remove just the text color option while keeping the header text option. It makes sense to me to put the option back when we decide to remove the accent color.

Last edited 10 years ago by iamtakashi (previous) (diff)

#10 in reply to: ↑ 9 @iamtakashi
10 years ago

Replying to iamtakashi:

Not directly relevant so I'm just noting here. Once we decide to remove the accent color option, let's put the header text option in custom header back. We've received a few feedback/complains of the lack of the option from WP.com users. As far as I remember, the reason why we removed the option was the text color option was redundant because of the accent color, and it was tricky to remove just the text color option while keeping the header text option. It makes sense to me to put the option back when we decide to remove the accent color.

Filed a new ticket #26338 and added a patch to put the header text option back.

#11 in reply to: ↑ 8 ; follow-up: @iamtakashi
10 years ago

Replying to celloexpressions:

I'm fine with going the route of re-defined color schemes, as long as they change more than just the accent color ...

Why does it need to change more than the accent color?

#12 in reply to: ↑ 11 @celloexpressions
10 years ago

Replying to iamtakashi:

Replying to celloexpressions:

I'm fine with going the route of re-defined color schemes, as long as they change more than just the accent color ...

Why does it need to change more than the accent color?

Using a select UI, or some equivalent choice from a list, in place of a color picker (which is the standard way of displaying color options in WordPress), is an obvious sacrifice of usability and functionality. Additionally, loading the colors CSS from new files adds a lots of technical overhead (in a more visible way than the current approach, as we'll have more files, which will carry a certain importance).

Basically, there are two issues: an atypical, limiting UI, and the (mostly psychological) weight of adding new files. I think that we can justify these concerns only if we have more obviously changing color schemes, with something more robust than an accent color option.

We should think of the current accent color option like the link color option that was in Twenty Eleven, but slightly more powerful. Does it make sense to limit a link color option to a few specific options because we're worried that users will pick a color that doesn't show up well against the white page background? That's basically what this ticket is arguing.

I would prefer that the alternate color options retained the strong contrast between the sidebar and page content, since that's how the theme works best (and that design works very well with alternates for the green colors), but we'd need to provide some alternatives with color schemes.

I have come up with a couple of other approaches to resolve the concerns in this ticket while preserving the accent color option. We could switch the color picker out with one that only supports changing the hue, but not the intensity. Or, we could do some basic checks to flip the color of the search icon when contrast is too low. However, there is no elegant way to do such a flip to compensate for the fact that the link color is also the accent color. Because the link color is the accent color, I'm leaning towards thinking that this is really more of a wontfix, for the same reasons that link color options are typically implemented with color pickers.

#13 @lancewillett
10 years ago

  • Keywords needs-patch added
  • Summary changed from Twenty Fourteen: Light accent color makes search icon almost invisible to Twenty Fourteen: remove Accent Color feature

#14 @lancewillett
10 years ago

  • Owner set to lancewillett
  • Resolution set to fixed
  • Status changed from new to closed

In 26567:

Twenty Fourteen: remove Accent Color feature. Props celloexpressions, fixes #26220.

#15 @lancewillett
10 years ago

In 26568:

Twenty Fourteen: remove custom-colors tag. See #26220.

#16 @celloexpressions
10 years ago

Submitted the plugin replacement to the WordPress.org repository. Will be live at http://wordpress.org/plugins/fourteen-colors when it's approved. Suggestions/contributions welcomed!

#17 @markoheijnen
10 years ago

Didn't saw this ticket before but I don't really understand why it gotten removed and I would have loved to join that discussion in London. Not sure if it would have worked well enough with this theme but you could have selected a darker color when the color was to light.

#18 @kraftbj
10 years ago

Thanks @celloexpressions for the plugin. Works for me. I was wondering why my site changed colors on my last svn up :-)

#19 @celloexpressions
10 years ago

  • Version changed from 3.8 to trunk

Noting that the final decision was made in IRC here. As mentioned, something could potentially be added back here in a future version of the theme.

#20 @celloexpressions
10 years ago

  • Version changed from trunk to 3.8
Note: See TracTickets for help on using tickets.