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.

Design for Developers

I’ll be teaching the next session of our Design for Developers workshop on December 7th & 8th at our Boston offices.

The workshop is aimed at developers (as well as non-developers) who know HTML and CSS, but feel like they don’t have the graphic design skills to make something that looks good enough to show customers and clients. I want to ease the pain of developers who feel like this:

I’m a developer who is a HORRIBLE at design so I don’t even know where to start.

I have the technical skills but my designed sites and interfaces are always awful, I know how to build a site technically and I know when a site  looks bad, but I’m rarely able to do anything about it.

The workshop is heavily focused on hands-on instruction, so that you can start to see immediate improvements in your ability to layout pages, pick and use typefaces, and work with color.

Visit the workshops site to learn more and register.

On the Monday and Tuesday before this workshop, we’ll also be running our Advanced HTML & CSS workshop. This workshop provides a solid foundation in HTML and CSS fundamentals. We’re running these workshops back to back to give folks the opportunity to get a crash course in the full stack of skills you’ll need to design and build great pages.

If you’d like to find out more about either workshop and figure out which one might be right for you, drop us a line.

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.

Designing Menu Icons for Android Devices

Recently we took on a client project which entailed building an Android app. The client delivered to us a set of sixteen 30x30 pixel PNG icons for use in the app. The icons displayed well on low-density screen devices, such as the Samsung Moment, but they were not large enough to accurately retain detail on higher density screen based devices, e.g. HTC G1 and the Nexus One. The solution was to redraw the icons in vector format and size them for the various screen densities.

Android uses a number of resource directory qualifiers for controlling which density-specific icon will be displayed for each device. In this case I focused on creating icons for low-density (ldpi), medium-density (mdpi), and high-density (hdpi) screens. Effectively, this means three specific sizes of each icon are needed—36x36 pixel, 48x48 pixel, and 72x72 pixel icons. It is worth noting that the new icon document resolution should remain at 72 pixels/inch for all icons, including high-density screen icons (don’t be fooled by the android density numbers).

The Process

The process began by importing all sixteen icons onto a single document in Adobe Fireworks. I used Fireworks’ vector tools to retrace each icon. Rather than using the merging tools on the vector paths, I used Rogie King’s Alpha converted vector groups technique to preserve a high amount of editing for the icons. The new vector paths can be seen in the icons below.

After vectorizing all sixteen of the original icons, I then set out to resize them. The Android developer docs contain useful guidelines for creating menu icons with consistent visual weight across all devices.

To maintain pixel perfect appearance, tweaks will often need to be made when vectors are resized up or down. The alpha converted vector groups helped facilitate the tweaking process. The icons below are sized for their respective screen densities.

After all the icons are resized and exported as transparent PNG images, they must be placed in their respective folder in the resources directory—drawable-ldpi, drawable-mdpi, drawable-hdpi. The filenames must remain the same for each icon, but be stored in the mentioned density-specific resource directories. Android devices will load the proper resources according to the screen density of the device.

Below are a few ‘before and after’ views of a few icons that went through the process. The icons appear much crisper, have sharper edges, and are now fully transparent. The end result provides a much more professional looking Android App, whereas the icons enhance the menu navigation by providing the user with a clearer interpretation of each graphic symbol.