Skip to content
This repository has been archived by the owner on Nov 9, 2022. It is now read-only.

Color Strategy

Jump to bottom
atsengucla edited this page Jan 10, 2013 · 29 revisions

References Ticket #33 (https://github.com/ucla/WebBlocks/issues/33). Use this page to flush out color categories.

Definition

The semantic color strategy for WebBlocks will be as follows:

/**************
Branding
  - Used mostly as the basis for the other colors
***************/

.default {}
.primary {}
.secondary {}
.tertiary {}
.neutral {}

/**************
Scaffolding
***************/

.background {} /* Default background color */
.foreground {} /* Default body copy color */
.accent {}
.focal {}

/**************
Moods
  - Alert: Styles the background of the alert
  - Buttons: Styles the background of the button
  - Links: N/A
  - Table: Can be used to style rows, columns, or the entire table
  - Text: Styles the font color
***************/

.default {}
.info {}
.important {}
.success {}
.warning {}
.danger {}
.inverse {}
.required {}
.highlight {}

/**************
States
  - Alert: N/A
  - Buttons: Styles the button
  - Links: Styles the link's text color
  - Table: N/A
  - Text: N/A
***************/

.default {}
.hover {}
.active {}
.selected {}
.disabled {}
.focus {}
.visited {}

/************* 
Tables
*************/

.even {}
.odd {}

This is based on the problem rational and proposal discussion below.

Problem Rational

The general idea is that colors for the library should be named with more robust and semantic names than something like 'red'.

In the Twitter Bootstrap library we see 2 type of color classes -- those that reference Actions (i.e. "warning", "highlight" etc.), then a set that are named (red, green, blue, etc.) that are referencing re-usable accent colors that don't necessarily have a pattern that is tied to an action -- they instead have a pattern that is tied to visual design.

We're thinking that in most websites, these non-action patterned visual treatments are most likely tied to some type of brand/marketing guideline.

Proposal: Actions vs. Brand Color Categories

One proposal is that we distinguish between the "action" context and "branding" context to tease out 2 common patterns we see when dealing with colors.

On the one hand we'll specify some common contexts where color is a signifier of state changes.

The other will be related to branding/aesthetics for a site.

One idea for the the brand patterns is to follow the hierarchy that is already established in graphic identity guidelines: such as "primary", "secondary", "tertiary" colors. If following this logic, the branding elements, instead of "blue" as a class, we can have class "primary-color" (in the case of UCLA, assigned a value of the ucla blue). Thus, the library is nicely abstracted: when dealing with another set of brand colors where say their primary color=green, can still work.

In theory, this can be an organizing principal -- in practice, we'd need to speak with some marketing/branding folks to see if this approach will fulfill their needs.

In our meeting, we've agreed to start building the Actions section and get feedback from some of the marketing folks to see what they think.

Actions

Branding

Color Strategy Worksheet:

From 9/17 Meeting Team proposed as a way to move forward all members put forth ideas for consideration so color strategy can get resolved. Please post below with your name/date:

###9/18 Alice: Overview Rational: Proposal is 2-tier strategy; A) Marketing/branding to describe asethetic patterns and B) Action-based to describe color used by the system for user feedback, alerts,etc. to communicate state changes.

Below is a set of definitions based on the above rational:

/**************
Branding and Aesthetic/Stylistic Treatments: determine look and feel / visual vocabulary

**************/

/**************
Color Pallets -- determined by Brand Guidelines; vars will be needed to accommodate the various 
colors that guidelines have for each category: primary, secondary, tertiary
***************/
.primary-1 {}
.primary-2 {}
.primary-3 {}
.primary-4 {}

.secondary-1 {}
.secondary-2 {}

.tertiary-1 {}
.tertiary-2 {}
.tertiary-3 {}
.tertiary-4 {}

.neutral-1 {}
.neutral-2 {}


/**************
Color Hierarchy Values -- use to modify composition; useful for color varients that 
are used for composition and depth
***************/

.background {}
.foreground {}
.focalpoint {}
.accent {}

/**************
Color Value Modifyers -- use to modify true color values (from palletes) based on variables 
of lightness (white=tints) and darkness (black=shade); a var should be used with Compass's 
color functions.
***************/

.tint-1 {}
.shade-1 {}


/**************
Surface Treatments and Effects -- not color but usually stipulated as part of a brand's guidelines
***************/
.matte {}
.gradient {}
.glow {}
.shiny {}
.raised {}
.embossed {}
.overlay {}
.flat {}
.transparent {}


/**************
Container Edges -- not color but usually stipulated as part of a brand's guidelines
***************/
.corners-sharp {}
.corners-beveled {}
.corners-round {}

/**************
Line Weights -- not color but usually stipulated as part of a brand's guidelines
***************/
.line-hairline {}
.line-light {}
.line-medium {}
.line-heavy {}


/**************
States and Action-based Colors and Styles: these communicate changes in the states and 
feedback to a user
**************/

/************* 
Link States
*************/
.link-default {}
.link-hover {}
.link-active {}
.link-selected {}
.link-disabled {}
.link-focus {}
.link-visited {}
.link-inverse {}

/************* 
Buttons & Button States
*************/

.button-default {}
.button-primary {}
.button-secondary {}
.button-large {}
.button-small {}
.button-mini {}

.button-info {}
.button-important {}
.button-success {}
.button-inverse {}

.button-hover {}
.button-pressed {}
.button-released {}
.button-disabled {}

/************* 
Forms
*************/
.form-required {}
.form-highlighted {}
.form-default {}
.form-disabled {}

/************* 
Tables
*************/
.light-stripe {}
.dark-stripe {}
.highlight {}
.hover {}
.selected {}

/************* 
Text
*************/
.text-muted {}
.text-warning {}
.text-error {}
.text-info {}
.text-success {}

/************* 
Dialogues & Messages
*************/
.alert-info {}
.alert-warning {}
.alert-error {}
.alert-success {}
.tooltip {}
.progress {}
.progress-striped {}
.complete {}

/************* 
System Status
*************/
.status-update {}
.status-saved {}
.status-logged-in {}
.status-logged-out {}
.status-published {}
.status-pending {}
.status-submitted {}
.status-private {}
.status-share {}
.status-edit {}

###9/18 Logan:

Nice work, Alice! I had a few questions/suggestions (open to everyone for review):

####Clarification

Could you explain how accent and focal point will be used?

####Utility Classes

Are we defining utility classes/functions (.tint-1, .shade-1) at this stage? I would vote to leave them out of this discussion although we should definitely discuss them at some point (maybe soon).

####Surface Treatments/Effects

I would vote to leave these out as well; they could be wrapped into a later discussion about effects.

####Container Edges

I would also vote to leave these out of this current discussion.

####Line Weights

I would vote to leave this out as well, but I think we should probably open an issue for defining typography now as that will be critical.

####Inverse Link Color

I'm not personally a fan of Bootstrap's use of "inverse", so I would vote to leave this out unless there's it has a critical value to the User.

####Button Size Classes

As far as the color discussion, I don't think there's a need for differing colors based on size, so I would vote to remove the button size classes (again, in regards to the color discussion).

####Button "Released" State?

Does the button "Released" state differ from the button's default state?

####Button "Inverse" Style

I still can't get comfortable with Bootstrap's "inverse" (as it's a strange, relative, non-semantic CSS class), but I'm willing to be convinced of its usefulness and value.

9/18: Eric

First my thoughts in response to Alice's proposal:

  • Color Pallets: Why are there only 2 options for secondary and neutral but 4 options for primary and tertiary? If we look at the .span-X classes in Bootstrap, they have a configurable way to generate X different versions. Maybe we provide a way to set a collection of primary, secondary, tertiary and neutral colors. However, I'm not completely sure I like numbering them either because that's not really semantic. Maybe an alternate approach is to allow them to be utilized in combination with other modifiers like .tint, .shade, .accent, etc.?
  • Hierarchy Values: I'm on the same page as Logan here, except I don't really understand foreground either. Could we get a bit more description of how these would be used?
  • Color Value Modifiers: I'm seeing these potentially being very hard to implement in any reasonable sort of way. If I'm an end user and I discover that I can use .tint-X and .shade-X, I might start using them on all sort of elements - but unless we've accounted for them in all element definitions, then their behavior will be inconsistent. If we do account for them everywhere, meanwhile, we end up bloating the CSS file significantly.
  • Surface Treatments and Effects: Similar problem here to what I describe in "Color Value Modifiers" about implementation - either it being partial (and thus inconsistent) or being full (and thus bloated). I like the ideas of things like .transparent [opacity: 0] and .flat [no border stylings to create an embossed effect], but other ones are trickier as described above.
  • Container Edges: I disagree with Logan to a point here because I think the implementation is trivial (at least for .corners-rounded and .corners-sharp). However, I'd be interested in understanding more why we want to leave this one out. It's a utility helper like .float-left and .hide, but not really a part of color par se.
  • Line Weights: This isn't color either - maybe we should drop Container Edges and Line Weights from this discussion since its not about color and this is color strategy.
  • Entity Color Types: For the dialogs, text, buttons, and links, I think we should hunt for a single naming convention. This was discussed a bit in #33. We should also drop sizes from this discussion.
  • Inverse Color: I do like inverse colors. If find them useful. However, we need to answer if inverse is just a single style in the same way we have something like .info or .success or if it's a modifier on all color types that switches their style.

As for Logan's, I like that he's tightening up the full list some.

I will post more later today about my own thoughts on a strategy (just don't have time to right now).

9/18: Logan

Finishing up from earlier:

Light Stripe/Dark Stripe

I'm suggesting we switch these out with primary/secondary (or default/alternate, etc.).

Statuses

I'm voting to pull out the status classes as well since I think they can be consolidated/combined with the state colors.

Here's updated CSS based on the (pending) suggestions above:

/**************
Branding
***************/

.primary-1 {}
.primary-2 {}
.primary-3 {}
.primary-4 {}

.secondary-1 {}
.secondary-2 {}

.tertiary-1 {}
.tertiary-2 {}
.tertiary-3 {}
.tertiary-4 {}

.neutral-1 {}
.neutral-2 {}

/**************
Scaffolding
***************/

.background {}
.foreground {}

/************* 
Links
*************/

.link-default {}
.link-hover {}
.link-active {}
.link-selected {}
.link-disabled {}
.link-focus {}
.link-visited {}

/************* 
Buttons
*************/

.button-default {}
.button-primary {}
.button-secondary {}

.button-info {}
.button-important {}
.button-success {}

.button-hover {}
.button-pressed {}
.button-disabled {}

/************* 
Forms
*************/

.form-required {}
.form-highlighted {}
.form-default {}
.form-disabled {}

/************* 
Tables
*************/

.row-primary {}
.row-secondary {}
.highlight {}
.hover {}
.selected {}

/************* 
Text
*************/

.text-muted {}
.text-warning {}
.text-error {}
.text-info {}
.text-success {}

/************* 
Dialogues and Messages
*************/

.alert-info {}
.alert-warning {}
.alert-error {}
.alert-success {}
.tooltip {}
.progress {}
.progress-striped {}
.complete {}

9/18: Logan

I just want to clarify from earlier that when I say "leave it out", I mean "leave it out of this discussion", not "leave it out of Web Blocks." I think the rounded edges, effects, and typography could all be very important.

Based on Eric's suggestions about consolidating, here's an attempt at consolidation:

/**************
Branding
  - Used mostly as the basis for the other colors
***************/

.default {}
.primary {}
.secondary {}
.tertiary {}
.neutral {}

/**************
Scaffolding
***************/

.background {} /* Default background color */
.foreground {} /* Default body copy color */

/**************
Moods
  - Alert: Styles the background of the alert
  - Buttons: Styles the background of the button
  - Links: N/A
  - Table: N/A
  - Text: Styles the font color
***************/

.info {}
.important {}
.success {}
.warning {}
.danger {}
.inverse {}

/**************
States
  - Alert: N/A
  - Buttons: Styles the button
  - Links: Styles the link's text color
  - Table: N/A
  - Text: N/A
***************/

.default {}
.hover {}
.active {}
.selected {}
.disabled {}
.focus {}
.visited {}
.required {}
.highlight {}
.warning {}
.error {}

/************* 
Tables
*************/

.row-primary {}
.row-secondary {}

###9/18 Alice, follow-up to Questions: ####Hierarchy Modifiers:

When designing a page, I'm using certain params like size, contrast and color to visually convey information hierarchy in a visual composition. Rule of thumb - bigger + bolder = more important; more subtle + smaller = less important. The "visual vocabulary" provide subtle cues that I use to lead a person's eyes across a page. Often times, with color I need to be able to create a composition where there is a focal-point (~ to a call-out -- "look at me item"), accent colors (are less dominant to the focal point but still need to "pop" and stand in contrast to the main background), and finally background/foreground colors are used to produce depth and tension/balance.

These visual patterns are real, but they don't map literally to content types. They enhance content {mood, psychology, feel} rather than equal content.

Also, they usually aren't the literal primary/secondary/tertiary colors as these need to respond/contrast against primary/secondary/tertiary colors and won't lead to pleasing results if just directly mapped. These modifiers are often either a tint or shade created from primary/secondary/tertiary colors or a contrasting value.

If you look at ucla.edu ( http://www.ucla.edu ) you'll notice that the top utility bar is actually not a primary/secondary/tertiary color that was defined in the Style Guide. I'd consider that bluish hue an "accent color" that was derive from the "primary" pallate. If it was an exact match to the Primary blue, it wouldn't have the right amount of contrast to the header (which is actually what makes the utility nav "pop" visually away from the header so you can see it easily).

Typically, an accent color is either another shade of a primary color or a contrast to a primary color. You can see here: http://blog.crazyegg.com/2011/11/16/accent-colors-increase-web-conversions/

The focal point is a more dominant and narrower case. Typically it is a special color (may/may not be a Primary color) that draws attention to itself and is used very sparingly (think big fat call-to-action button on a marking landing page) - there should be only 1 focal point per page; if using color the focal point color should remain the same throughout the site for all "super important look at me" content. Of course, this doesn't have to be color but color is a very wide-spread pattern.

Also, since the primary (brand) colors tend to make up the majority of a site's design -- often the focal point color may/may not be the same as the primary color. If your color-scheme is mostly blue/golds since your Primary/Secondary brand colors are blue/gold -- often you'll need a contrasting color (not blue/gold) to serve as your focal point in order to make it "stand out".

Thus, it's best to leave these classes as variables that a specific designer can assign to their preference.

Are they implementable in a practical way? Not sure. Are they useful definitions to designers - yes. As these colors are part of an organized color system, they are always repeated in patterns and not singletons. And there is always a "logic" to their pattern of use.

####Non-color Modifiers: @loganfraken and @ebollens you're right; I simply included them in model to show how they would fit into the macro of "branding" vs. "action." So, surface, edge, line-weight, button size -- these all have nothing to do with color but they do fit into this 2 prong approach for organizing/clarifying aesthetic/design classes from action/state/alert classes.

It may not be practical to implement so that would be a case to strike them. But for css3, implementing these effects/treatments are sometimes rather non-trivial and as a designer I'd be so happy to have something I can define as a SASS var or helper function and not have to retype these again and again. The surface/edge/line-weight all have to do with box properties and not typography ; line-weight has to do with the border (perhaps it would be better named border-thickness but the common design term is "line-weight".

Also, often these treatments are strictly defined by the Style-guide; so define once and apply many would help with consistency.

####Vars/Tints etc.: @ebollens there's no reason why Primary has 4 and Neutral has 1; just my cryptic shorthand that these are Vars. I guess using X would've been clearer. I'm unsure still how these would be implemented but from working with Brand Guidelines I know the groups are stable while the instances all differ. There's always Primary, Secondary, Tertiary, Neutral ... but the number of children depend from case to case.

Tints/Shades would be so, so, so useful -- again this would be a function; I think Compass already does this ( see: http://compass-style.org/reference/compass/helpers/colors/ ). 99% of branded websites use a tint/shade + Primary/Secondary/Tertiary colors to establish their color scheme. I just don't know how this would work with webBlocks and I still don't know what the difference is between function/ SASS var/ and regular css so I just put them in the css model to say ... "this would be useful to designers."

Right now it's a painstaking thing - I take Primary/Secondary/Tertiary colors from guidelines and go in Photoshop to create a color pallet (finding tints/shades) that works with my content strategy and stays true to brand. Then I hand define hex values to css classes -- this would be a huge win to designers using WebBlocks.

####Inverse: Very useful. Here's a use-case that I encounter all the time. Link colors & Title colors are established by Brand Guidelines and fairly strict and limited. What happens when I have A) complex UI for an APP with 4+ hierarchy of UI or B) heavy information sight with deep info hierarchy?

Only way I can make UI consistent to brand bu convey everything I need to in terms of functional difference is color/size/placement/treatment. There's many times when I need to create an inverse of the standard default to distinguish between information hierarchy or functional difference. And, if I've done my job -- the inverse should not be arbitrary but follow a strong pattern/logic so when I apply it -- in all cases I should be able to repeat it in a predictable way.

9/18: Eric

I like Logan's current proposal for the classes with a few changes:

  • Instead of .row-primary and .row-secondary, I'd like to support the branding and moods. So you'd simply set a tr. primary or tr.info or tr.inverse. I think this would be very useful, and it improves the consistency of our palettes.
  • I'd like to drop .warning and .error in the states list and instead allow buttons and links to have moods as well. I think .danger is better than .error anyways, and .warning is in both. Maybe .success doesn't make so much sense here, but I think we still need a "success"-oriented button, so why not? This would allow us to drop some of them.
  • It might make sense to make .required and .highlight moods instead of states. I could definitely see styling something with alert.error.required, meaning that the error is required to be diagnosed. Of course, that might be the definition of an .error anyways (as opposed to a .warning), but I'm just thinking out loud here.
  • Lets add .accent and .focal back into the scaffolding classes. I think Alice makes a great point on both of these. We should make sure people understand that support for these on our UI elements is optional. Some things like buttons in the header might support .accent but other contexts in the system might not - like buttons and tables, where .highlight is plenty, so the understanding would be that the scaffolding only applies in some scenarios (whereas moods apply to all contexts of the elements where they're allowed).

As for Alice's points:

  • I agree with Hierarchy Modifiers (as reflected in my above comment about Logan's proposal).
  • What would you think about having a function that you can call to generate these? I don't think it's reasonable from the CSS implementation to build them in by default, but if there's a function that can generate primary with some offset of tinting, that's definitely a win in terms of our development, as well as the development of your final SASS sources as well (probably take advantage of Compass to do this, but encapsulate the functionality within our own functions as well).
  • For inverses, please see my question above: is an inverse like the Bootstrap inverse, or is it an inverse of whatever you're applying it too? An example: if it's a .primary blue button with white text, is the inverse still a black button with white text (like in Bootstrap), or is it a white button with blue text? I don't think this latter approach is right, because background and foreground colors don't always flip well - it's also far harder to implement than the inverse concept that Bootstrap uses.

9/18: Email from Howard Kim

From: Kim, Howard
Sent: Tuesday, September 18, 2012 6:18 PM
To: Watkin, James
Subject: RE: [WebBlocks] WebBlocks: Color Strategy

I think the semantic approach makes the most sense and they seem to have a decent handle on that part. There isn’t a lot of time to mull through the possibilities, so I don’t have too many comments.

One thing I would add is a “theme” class may be useful. If a theme class is added to the body element, then that can provide a nice way of grouping the visual definitions of the semantic classes (e.g., primary, secondary, error, etc.). I could see the theme used for institutions (e.g., ucla, dark, modern, etc) and then the rest of the classes could be defined or overridden based on the existence of the theme (e.g., #ucla .primary-1{} could mean something different than #dark .primary-1{}). Obviously, there would have to be a default theme as well for all the styles to fall back on if a custom theme did not redefine one of the classes.

~Howard

9/19: Eric

I agree with Howard that we should look at possible ways to theme this. However, I propose that, like with some of the other elements we've dropped from the discussion, we should make this a separate action item.

Also, it is of note that anyone could pull down the WebBlocks source (or ideally fork it) and then tweak their color variables to get the theme they want for their version of the build (since everything is compiled into static CSS/JS eventually anyways). However, this could still be useful in some scenarios. I've created a separate issue https://github.com/ucla/WebBlocks/issues/82 for this so that it doesn't drop off the radar.

9/19: Alice

re the inverse: I agree with @ebollens; the twitter method is much easier to control and implement. Color contrast is a huge issue for the usability/accessibility of links and text -- leaving that to some automatic inverse could prove problematic.

re a function for tints/shades: sure that would be fine; like I mentioned before -- the differences in implementations css vs. sass vars vs. functions are still fuzzy for me being so new to this way to approach stylesheets. Any helpers would be an improvement to the current manual approach.

9/19: Logan

Future Discussions

Just to keep track, here are the issues that we have decided to discuss separately from this discussion:

  • Tint/Shade
  • Surface Treatment/Effects
  • Container Edges
  • Line Weights
  • Button Size Classes
  • Theming Support

Updated CSS

And here's updated CSS based on our discussion so far (although I think I might be missing some of your finer points, Alice, so please let me know where I've missed it):

/**************
Branding
  - Used mostly as the basis for the other colors
***************/

.default {}
.primary {}
.secondary {}
.tertiary {}
.neutral {}

/**************
Scaffolding
***************/

.background {} /* Default background color */
.foreground {} /* Default body copy color */
.accent {}
.focal {}

/**************
Moods
  - Alert: Styles the background of the alert
  - Buttons: Styles the background of the button
  - Links: N/A
  - Table: Can be used to style rows, columns, or the entire table
  - Text: Styles the font color
***************/

.default {}
.info {}
.important {}
.success {}
.warning {}
.danger {}
.inverse {}
.required {}
.highlight {}

/**************
States
  - Alert: N/A
  - Buttons: Styles the button
  - Links: Styles the link's text color
  - Table: N/A
  - Text: N/A
***************/

.default {}
.hover {}
.active {}
.selected {}
.disabled {}
.focus {}
.visited {}

/************* 
Tables
*************/

.row-primary {}
.row-secondary {}

Some further areas for discussion:

Row Colors

I like the idea of supporting the branding/moods over the rows, but don't we also need to define what will be used as the defaults for zebra striping? Or is that a separate discussion?

9/19: Eric

Concerning row colors, how about we use primary/secondary for zebra but support the use of all moods as row coloring as well?

9/20: Alice

I agree the default for table should be simple zebra stripes (usually its a neutralish color range so not to distract the user from data). Also supporting additional moods are good for the cases when the table is used to output system communications for users. I think we might want to re-think our vocabulary to clarify between row-primary vs primary -- in the first case where saying "some color default used for a table row" in the second were saying "this is a primary color pallet for branding" ... seems like a confusion of terms. Could we say row-even row-odd instead? I'm also concerned that since this is data, where users are expecting some form of hierarchical meaning that saying "primary" and "secondary" will confuse the issue to mean that one is more informationally hierarchical when in fact that isn't the case. Thus, even and odd would be truer to the relationships these rows have to one-another.

9/20: Eric

Makes sense to me. Except, instead of tr.row-even and tr.row-odd, how about just tr.even and tr.odd. The semantics are established by context as is, so having tr and a .row- prefix is superfluous.

9/20: Logan

Sounds good to me!

/**************
Branding
  - Used mostly as the basis for the other colors
***************/

.default {}
.primary {}
.secondary {}
.tertiary {}
.neutral {}

/**************
Scaffolding
***************/

.background {} /* Default background color */
.foreground {} /* Default body copy color */
.accent {}
.focal {}

/**************
Moods
  - Alert: Styles the background of the alert
  - Buttons: Styles the background of the button
  - Links: N/A
  - Table: Can be used to style rows, columns, or the entire table
  - Text: Styles the font color
***************/

.default {}
.info {}
.important {}
.success {}
.warning {}
.danger {}
.inverse {}
.required {}
.highlight {}

/**************
States
  - Alert: N/A
  - Buttons: Styles the button
  - Links: Styles the link's text color
  - Table: N/A
  - Text: N/A
***************/

.default {}
.hover {}
.active {}
.selected {}
.disabled {}
.focus {}
.visited {}

/************* 
Tables
*************/

.even {}
.odd {}
Clone this wiki locally