Color Strategy

[ebollens]

We need to come up with a strategy for color.

In Twitter Bootstrap, buttons are defined with the likes of:

• $btnPrimaryBackground[Highlight]
• $btnInfoBackground[Highlight]
• $btnSuccessBackground[Highlight]
• $btnWarningBackground[Highlight]
• $btnDangerBackground[Highlight]
• $btnInverseBackground[Highlight]

The same is true for forms:

• $warning[Text|Background|Color]
• $error[Text|Background|Color]
• $success[Text|Background|Color]
• $info[Text|Background|Color]

I would consider these as sentiment-driven colors (made the name up on the fly, so don't quote me on this). It allows me to decide that success gets the color green, warnings get an orange, danger/error gets a red (discrepancy having two different names for it though), and info gets a gray. Ideally, though, we wouldn't define them each individually like Bootstrap does, though, but instead use SASS/Compass to generate the colors of forms, buttons, etc. from a single set of colors that are viewed as the sentiments.

However, Bootstrap uses a very different method for accents:

• $blue
• $blueDark
• $green
• $red
• $yellow
• $orange
• $pink
• $purple

I don't like these as much because they're not semantic - what am I going to do, change $blue so that it's #f00 instead? That makes no sense, because now it's red. If possible, I'd like to escape this sort of naming for colors, and instead focus on sentiments.

Thoughts? If we like the idea of sentiments, we should try to decide what our sentiments are. We can then map our definitions back over Bootstrap through the adapter (don't want us to necessarily be forced into Bootstrap's sentiments).

PS. Their use of the gray scheme is also weird. They should just use SASS to generate different grays amongst the different variables by interpolating to different degrees between black and white. However, this isn't a big deal. Just something to define in variables and leave it be.

[parthms]

I definitely like the idea of sentiments.

Success, Go, Confirm --> Green
Warning, Caution --> Yellow
Danger, Exit, Cancel --> Red
Info --> Gray

In addition to sentiments, can we also have basic colors defined, like
blue, green, yellow, red, etc (just a few common ones)?

Best,
Parth Shah

On Fri, Aug 3, 2012 at 2:53 PM, Eric Bollens <
reply@reply.github.com

wrote:

We need to come up with a strategy for color.

In Twitter Bootstrap, buttons are defined with the likes of:

• $btnPrimaryBackground[Highlight]
• $btnInfoBackground[Highlight]
• $btnSuccessBackground[Highlight]
• $btnWarningBackground[Highlight]
• $btnDangerBackground[Highlight]
• $btnInverseBackground[Highlight]

The same is true for forms:

• $warning[Text|Background|Color]
• $error[Text|Background|Color]
• $success[Text|Background|Color]
• $info[Text|Background|Color]

I would consider these as sentiment-driven colors (made the name up on the
fly, so don't quote me on this). It allows me to decide that success gets
the color green, warnings get an orange, danger/error gets a red
(discrepancy having two different names for it though), and info gets a
gray. Ideally, though, we wouldn't define them each individually like
Bootstrap does, though, but instead use SASS/Compass to generate the colors
of forms, buttons, etc. from a single set of colors that are viewed as the
sentiments.

However, Bootstrap uses a very different method for accents:

* `$blue`
* `$blueDark`
* `$green`
* `$red`
* `$yellow`
* `$orange`
* `$pink`
* `$purple`

I don't like these as much because they're not semantic - what am I going
to do, change $blue so that it's #f00 instead. That makes no sense,
because now it's red. If possible, I'd like to escape this sort of naming
for colors, and instead focus on sentiments.

Thoughts? If we like the idea of sentiments, we should try to decide what
our sentiments are. We can then map our definitions back over Bootstrap
through the adapter (don't want us to necessarily be forced into
Bootstrap's sentiments).

PS. Their use of the gray scheme is also weird. They should just use SASS
to generate different grays amongst the different variables by
interpolating to different degrees between black and white. However, this
isn't a big deal. Just something to define in variables and leave it be.

---

Reply to this email directly or view it on GitHub:
#33

[alicetseng]

+1 on not using specific color descriptors (i.e. "red") and leaning towards the usage context (i.e. "primary-branding" "warning"). This will be more robust and re-usable.

The main point with "visual semantics" is just to convey enough information for designers/devs so they know what they are applying.

If items are decorative i.e. not tied to an action (warning, highlight, etc.) they usually are related to branding purpose -- I know all brand guidelines dictate the following in some sort of regular fashion: primary, secondary, tertiary colors -- would this work for the "decorative" colors to help specify a use context that isn't patterned by actions ... I'm wondering what the branding folks think of this?

@modernrockstar @mtakahashi

[mtakahashi]

@alice can you show some examples?

[erutan]

You could define $pri, $sec, $ter at the top (for UCLA blue, yellow, oddly vibrant green) and then those would be used in classes. So the body could have background: $pri; a secondary div could have background: darken(20%, $sec); etc. Then for elements that are meant to stand out (sucess is green, warning is red, caution is yellow, etc) those are named semantically and you can pick colors that fit with the branding.

The problem could come with primary, secondary, and tertiary colors not working with a set design, but it seems like a solid approach.

[alicetseng]

right @erutan ... that's along the lines of what I was thinking.

In many cases background colors are a great example -- say the primary brand color for a site I am working with is blue -- most likely, a lot of my colors on the website will be patterned off some varient of this blue. Now in a traditional sense -- I have a hard choice: either a) I can reuse the blue pattern all over the place (regardless of content) and give it a generic (un-semantic) name like "blue" -- or I can assign the blue value to all the semantic content components (i.e. .sidebar, .footer, etc.) at a cost to the visual pattern I can reuse. Using SASS vars like $pri or an abstracted color class like .primary -- I could try to attempt both reuse of the color pattern and have a decently named class that will be more re-usable and robust to changes.

But again, this is something that sound's OK in theory but would need folks who work with setting brand guidelines to think about this a little more to see if in practice this has any legs. I started a child wiki page so we could flush this out more: https://github.com/ucla/WebBlocks/wiki/Color-Strategy

As per today's meeting - we agreed to start working on the "actions list" -- those seemed more straight forward and see what the marketing folks think of RE organizing color for branding elements.

[erutan]

I'd lean much more towards including a SASS var in existing semantic class names than littering the markup with .color classes. It also makes it easier to back out of specific elements if/when they don't make aesthetic sense in a general branding scheme.

Aside from pri, sec, ter, you'd want a 'neutral' (greyish), and possibly accent for borders, etc.

[allankim]

Primary/secondary/tertiary colors work for us. Definitely lean toward semantic color names as certain colors are reserved for special uses (e.g. red for campus alerts only).

[ebollens]

@erutan @atsengucla from the beginning, my intent was that we define these as variables in SASS. We then apply them where they fit elsewhere too (both for action-based sentiments and for brand-based sentiments). So you'd have a .success class, for example, but it would use a SASS sentiment variable (action-based in this case).

[loganfranken]

I just want to make sure that I fully understand: per Alice's wiki article updates (https://github.com/ucla/WebBlocks/wiki/Color-Strategy), we are not choosing actual colors, we are choosing types of colors that will be mapped to appropriate colors from each base framework. Yes?

[ebollens]

Logan,

That's right - the goal is to choose types, so just like in my earlier post, we're interested basically in the variable names and css classes not the hex combos.

On Sep 18, 2012, at 10:47 AM, "Logan Franken" <notifications@github.commailto:notifications@github.com> wrote:

I just want to make sure that I fully understand: per Alice's wiki article updates (https://github.com/ucla/WebBlocks/wiki/Color-Strategy), we are not choosing actual colors, we are choosing types of colors that will be mapped to appropriate colors from each base framework. Yes?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-8663409.

[loganfranken]

Just wanted to note that there is an ongoing discussion here: https://github.com/ucla/WebBlocks/wiki/Color-Strategy (Please join in!)

[alicetseng]

Thanks for the head's up. Added some follow-up to answer questions to the best of my knowledge:
https://github.com/ucla/WebBlocks/wiki/Color-Strategy

-alice

From: Logan Franken <notifications@github.commailto:notifications@github.com>
Reply-To: ucla/WebBlocks <reply@reply.github.commailto:reply@reply.github.com>
Date: Tuesday, September 18, 2012 1:23 PM
To: ucla/WebBlocks <WebBlocks@noreply.github.commailto:WebBlocks@noreply.github.com>
Cc: Alice Tseng-Planas <atseng@it.ucla.edumailto:atseng@it.ucla.edu>
Subject: Re: [WebBlocks] Color Strategy (#33)

Just wanted to note that there is an ongoing discussion here: https://github.com/ucla/WebBlocks/wiki/Color-Strategy (Please join in!)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-8668934.

[ebollens]

Posted some more comments back - looks like we're starting to come to a consensus of sorts.

[jwatkin]

Sorry, clicked by mistake.

[loganfranken]

I think we're heading towards the end here; some additional comments:
https://github.com/ucla/WebBlocks/wiki/Color-Strategy

[alicetseng]

One more point, please take a look. Yes. We're getting close: https://github.com/ucla/WebBlocks/wiki/Color-Strategy
-a

From: Logan Franken <notifications@github.commailto:notifications@github.com>
Reply-To: ucla/WebBlocks <reply@reply.github.commailto:reply@reply.github.com>
Date: Wednesday, September 19, 2012 3:28 PM
To: ucla/WebBlocks <WebBlocks@noreply.github.commailto:WebBlocks@noreply.github.com>
Cc: Alice Tseng-Planas <atseng@it.ucla.edumailto:atseng@it.ucla.edu>
Subject: Re: [WebBlocks] Color Strategy (#33)

I think we're heading towards the end here; some additional comments:
https://github.com/ucla/WebBlocks/wiki/Color-Strategy

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-8710806.

[loganfranken]

Added in Alice and Eric's points:
https://github.com/ucla/WebBlocks/wiki/Color-Strategy

I think we're good to go unless anyone else has any other input?

[ebollens]

I'm going to close this as complete. An implementation ticket #109 has been created and assigned to me with milestone of 0.1.01 (due in two weeks). My target is to complete it sooner than that.