Controlling color with Sass color functions

Sass comes with functions that can easily be applied to colors in your CSS properties. These functions, when used correctly, can be incredibly powerful. They take some of the sting out of choosing and manipulating colors. When used with variables, they can speed up development drastically.

Let’s start off with a creating variable for the color that we’re going to manipulate:

$base-color: #AD141E;

This is important for me for two ways:

1. It will allow color changes to be much more fluid and easy
2. Since I can’t be bothered to memorize hex values for each color, it helps me remember colors, eliminating the need to reference a photoshop mock every time I need a color.

Darken & Lighten

These two adjust the Lightness of the color’s HSL values. Sass will parse our hex color variable to hsl, then make the adjustments. You call them on the color with a percentage value between 0 and 100. I usually stay in the range of 3-20%.

darken( $base-color, 10% ) 
lighten( $base-color, 10% )

Saturate, & Desaturate

These will will adjust the Saturation of the colors HSL values, much like Darken and Lighten adjusted the Lightness. Again, you need to give a percentage value to saturate and desaturate. 

saturate( $base-color, 20% ) 
desaturate( $base-color, 20% )

Adjust-hue

This adjusts the hue value of HSL the same way all of the others do. Again, it takes a percentage value for the change.

adjust-hue( $base-color, 20% )

Adding Alpha Transparency

Using our hex color we can do a few things to get it to be a little transparent. We can call hsla, rgba, opacify, and transparentize. All of them accomplish the same thing, just in different ways. I stick to rgba as it comes most naturally to me which takes a color and a value from 0 to 1 for the alpha.

rgba( $base-color, .7 )

Tint & Shade

Our very own Phil LaPier has added to those base color functions. Both of these are accessible in Bourbon. They mix your color with a value of white (tint) and black (shade) and are similar to Darken and Lighten. They take the color and a % value for the change.

tint( $base-color, 10% )
shade( $base-color, 10% )

Getting more advanced

Once you have those down and you are looking for more control you can look into some more advanced color control with adjust-color, scale-color, change-color. These are for multiple changes in one color function. You can easily lighten the color and add some transparency all in one.

Some of the best places to use these color functions are for gradients, borders and shadows. When you need a slightly darker border and a slightly lighter inset shadow just adjust a color variable and let Sass do the rest for you. Buttons provide the perfect place to test out the functions. Check out some of the functions used on the thoughtbot buttons:

border: 1px solid darken($base-color, 20%);
text-shadow: 0 -1px 0 darken($base-color, 10%);
@include box-shadow(inset 0 1px 0 lighten($base-color, 20%));

Learn more about Sass, CSS and HTML during my Advanced HTML & CSS Workshop on December 8th and 9th.

Lazy man’s responsive web design

The Boston Globe recently raised the bar for responsive web design.

Please allow me to lower it.

For our playbook, I wanted to provide a pleasant reading experience for desktop and mobile web browsers. However, I’m lazy.

My answer to “what’s the simplest thing that could possibly work?” was a single-column layout with a maximum width that would also fit mobile devices:

margin: 0 auto;
max-width: 480px;

That makes the User experience section look like this on a desktop…

… and like this on an iPhone…

No media queries or other additional resizing tricks except for messing with the viewport a little and hiding the browser bar when possible:

It also means fewer conditional statements, which we aim to eliminate.

max-width isn’t supported in IE6 but we don’t support IE6.

Responsive web design is already very elegant in its simplicity. My thought is that for use cases like landing pages and content sites, it can be even simpler using a thin, vertical one-column layout.

I’ve heard landing pages convert better using a vertical, single-column layout. The premise is anything that distracts the user, including navigational elements and sidebars, will hurt conversion.

For the playbook, the average time on the site is 4:40. So, I’m feeling pretty good that the layout is working well to focus readers on the content.

My guess is other content sites like McSweeney’s Internet Tendency do similarly well keeping its readers engaged on their 400px-wide desktop version:

With the addition of one line of code…

<meta name="viewport" content="width=device-width">

…they could make their mobile web version immediately readable without zooming instead of presenting a garish request to download software for “optimized” reading:

It’s so easy, even a lazy man can do it.

Written by Dan Croak.

WIP it ♪♪♫♪ WIP it good

Our development process calls for a design component up front. Design is typically one or two weeks ahead of development so that by the time a developer is ready to implement the feature, there’s a pretty good idea of how the interactions will work, and even better, part or all of the markup has already been written. This introduces a problem where at any point in time there will be Work In Progress functionality that hasn’t been wired to the backend. This creates frustration and confusion for the product owner, who gets oh so excited to see a feature corresponding to the story they have just recently created, only to find out that it’s only a placeholder.

Displaying work in progress UI elements is also sometimes not an option, especially on an iterative development process where each week the app is shown to real users to gather feedback. Hiding .wip elements using CSS, commiting and redeploying to prime the app for user testing, followed by reverting the CSS commit in order to continue with development soon became old and cumbersome. There’s a better way to support the process.

You should go here on a new tab and click play. Also, here’s a picture of Devo. I’ve included a unicorn with a shining star to keep them company. Don’t worry, it’s Work In Progress.

What I present here is not ground breaking, but it is a well tested piece of code that you can drop into your app and will give your product owners the ability to view how the interface is shaping up. It still gives developers and designers the opportunity to continue implementing Work In Progress features on a live app without having to deal with too many feature branches, where keeping the markup and styles up to date with master at an early stage is an expensive moving target.

The idea is to have the ability to toggle visibility of Work In Progress elements of the app. For a developer or designer, it’s as simple as setting a CSS class of wip on any DOM element. For a user, pressing Ctrl-W reveals the WIP elements.

Let’s do this!

We practice Outside-In development, so let’s use Cucumber to specify this behavior:

Feature:
  As a product owner
  So that I can view what's work in progress
  I can press Control W

  @javascript
  Scenario:
    Given I visit the home page and the body is marked as wip
    When I press Control "w"
    Then the wip tags are visible
    When I press Control "a"
    Then the wip tags are visible
    When I press Control "w"
    Then the wip tags are not visible
    When I press Control "a"
    Then the wip tags are not visible

First, we use jQuery to set the wip class on the document’s body from within the step definition. Here’s the implementation:

Given /^I visit "([^"]*)" and the body is marked as wip$/ do |page_name|
  visit(path_to(page_name))
  page.execute_script("$('body').addClass('wip');")
  page.should have_css('body.wip')
end

Pressing Control W also evaluates javascript to trigger the event:

When /^I press Control "(\w)"/ do |character|
  code = case character
         when 'w'
           23
         when 'a'
           65
         end
  page.execute_script(<<-JS)
    var e = $.Event('keypress', { which: #{code}, ctrlKey: true });
    $('body').trigger(e)
  JS
end

Finally, checking whether the WIP elements are visible is a matter of checking the CSS classes:

Then /^the wip tags are visible/ do
  page.should have_css('.wip.visible')
end

Then /^the wip tags are not visible/ do
  page.should have_css('.wip')
  page.should have_no_css('.wip.visible')
end

I placed all of these steps definitions in features/step_definitions/wip_steps.rb

To make this pass, the jQuery implementation is simple:

$(document).ready(function() {
  $('html').keypress(function(e) {
    var codeForW = 23;
    if (e.ctrlKey && e.which === codeForW) {
      $('.wip').toggleClass('visible');
    }
  });
});

Here are some styles that handle WIP element visibility and give them a yellow outline:

.wip {
  outline: 1px solid #ff0 !important;
  visibility: hidden;
}

.wip.visible {
  visibility: visible;
}

When dropping this into your app, just remember that when a problem comes along, you must WIP it. Before the cream sets out too long, you must WIP it. When something’s goin’ wrong, you must WIP it. To WIP it, well, WIP it good.

Introducing Bourbon Sass Mixins

Bourbon is a library, and also a Ruby Gem, of sass mixins that are designed to be written as vanilla as possible—meaning, whenever possible, they should not stray from the original CSS syntax. The mixins contain vendor specific prefixes on all CSS3 properties for support amongst modern browsers. The prefixes also ensure graceful degradation for older browsers that support only CSS3 prefixed properties.

Examples

# Bourbon syntax
@include box-shadow(0 2px 2px 0 rgba(0, 0, 0, 0.3));

# Output
-webkit-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
   -moz-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
    -ms-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
     -o-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
        box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);


# Bourbon syntax
@include box(horizontal, start, stretch);

# Output
        display: -webkit-box;
        display:    -moz-box;
        display:         box;
-webkit-box-orient: horizontal;
   -moz-box-orient: horizontal;
        box-orient: horizontal;
-webkit-box-pack: start;
   -moz-box-pack: start;
        box-pack: start;
-webkit-box-align: stretch;
   -moz-box-align: stretch;
        box-align: stretch;


# Bourbon syntax
@include animation-basic( (fadein, slideup), (2.0s, 1.0s), ease-in );

# Output
-webkit-animation-name: fadein, slideup;
   -moz-animation-name: fadein, slideup;
        animation-name: fadein, slideup;
-webkit-animation-duration: 2s, 1s;
   -moz-animation-duration: 2s, 1s;
        animation-duration: 2s, 1s;
-webkit-animation-timing-function: ease-in;
   -moz-animation-timing-function: ease-in;
        animation-timing-function: ease-in;

The tools

Bourbon contains a number of commonly used CSS3 properties, such as linear-gradient and border-radius. We’ve also built in support for the latest CSS3 animation and transition properties. Bourbon has flex-box and a number of other CSS3 properties covered.

Our functions are pretty useful too. Like the golden-ratio function which can be used for calculating heading font-sizes based on the golden ratio. Modularscale.com is an excellent web-based tool for calculating font-sizes.

How Bourbon was born

The designers at thoughtbot are huge fans of Sass. We’ve been using sass on all our projects for over a year now. Previously we had two or three sass mixins that we used across all our projects (primarily linear-gradient and border-radius). As we began writing more CSS3 which included vendor specific prefixes, our mixin library eventually grew larger. With multiple designers working on various apps and client projects, it became increasingly difficult to distribute and update our small set of mixins across all these environments. Before the library was formalized on git, versioning was difficult too—if I made improvements to a mixin, there was no efficient way to inform the other designers about the changes. Eventually the library grew large enough that it became clear that the best way to manage the mixins was through git, and distribute them with a gem. And thus Bourbon was born.

Why vanilla syntax?

Part of our core philosophy when creating Bourbon was to keep the mixins as close to normal CSS as possible. There is already learning required with all the new CSS3 properties, and let us not forget Sass syntax. We thought the best way to learn proper CSS3 was to keep the mixins as syntactically similar to CSS3 as possible.

Why not compass?

Compass is a great toolset for anyone using sass. We initially solved our own problems using the toolset we created—Bourbon. Building our own tools allows us to have finer control of our mixins, functions and addons, which we are particularly keen on. We didn’t set out to build a public library of sass mixins, but over time it became increasingly difficult to not share these tools for other to use. Bourbon has been, and continues to be, a toolset for which we have been learning from. By creating our own set of mixins, we are pushed to continuously think of innovative ways to improve our front-end development knowledge and resources.

What’s with the name?

Bourbon Vanilla is the most commonly used variety of vanilla extract—I also have a nose for the sweet vanilla notes in a fine bourbon whiskey ;).

We look forward to building out Bourbon to support even more CSS3 properties, as well as building useful addons and functions for providing designers and developers with an even greater set of development tools. Keep an eye out for more blog posts covering Bourbon.

If your palate can handle the sophisticated flavors, try a glass of our fine Bourbon.

Recap: Design for Developers

We ran our first Design for Developers workshop this week. Kyle and I had a great time teaching it and were really pleased with the quality of the work the students were able to produce by the end of the workshop.

The main project the students worked on was a page for a fictional furniture company. We gave them a completely unstyled page and asked them to slowly transform it using grid systems, refined typography, and effective color schemes. The students sketched out their ideas on paper, then worked directly in HTML and CSS to implement their ideas. At the end of the last night, we had a group presentation of all the pages, where the students talked through their approach and we offered our critique.

We asked a few students to let us share their work with you.

This page was designed by Javan Makhmali (click for full-size image):

And this page was designed by Chuck Vose (click for full-size image):

At the end of the workshop, students walked away with a solid grasp of some fundamental principles of design along with practice building a well-structured, good looking web page.

If you’re a developer who wants to improve your design skills, consider taking our next Design for Developers workshop, which we’ve scheduled for Feb 21-23.