In part 1 of this series, I detailed how Behance maintains the CSS for our giant codebase (over 130 pages large!). I shared how we use Sass and Compass to organize, modularize and streamline code, as well as how we keep code consistent. In this part 2, I'm going to focus on the general “care and feeding” of your Sass codebase: how to use your modular Sass to create style guides, other tools to maintain code consistency, and ways to keep your team up-to-date on coding standards and guidelines.

Living Style Guide

As I described in part 1, Behance utilizes partials for every repeatable module, making it easy to include the styles for a component with just one line of Sass. We rely on the mustache template engine to create small blocks of markup that can be imported and reused in other templates (just like Sass partials). Having our styles and markup split into partials not only makes it easy to manage discrete sections of code, but also makes it easier for us to maintain consistency. Since we only have to update code in one place at a time, there is less danger of breaking or forgetting other parts of the site.

Not only do we use partials to make styling components across the site easy, we also use them to make a living style guide of these components. The style guide serves a purpose for both the designers and the developers by giving us a central place to see what modules already exist and what they look like. The Behance style guide is only available internally, but MailChimp and Starbucks have public ones that are great examples.

Here's an abbreviated look at the markup and Sass for our styleguide:

styleguide.mustache

<section>
  <h1>Buttons</h1>
  {{#buttons}}
    {{> form/button}}
  {{/buttons}}
</section>

<section>
  <h1>Inputs</h1>
  <h2>Text</h2>
  {{#texts}}
    {{> form/text}}
  {{/texts}}

<h2>Checkboxes</h2>
{{#checkboxes}}
{{> form/checkbox}}
{{/checkboxes}}
</section>

<section>
  <h1>Multiple Owners</h1>
  {{> components/_multiple-owners}}
</section>
…

styleguide.scss

@import '_global/*.scss';
@import 'partials/multiple-owners.scss';

// styleguide-specific styles
section {
  margin-bottom: 50px;
}

Since the style guide is built using the same exact partials as the rest of the site, any changes made to the individual pieces are reflected immediately in both the front-end of the website and the style guide.

Documentation

Let's say you joined Behance as a front-end developer today. How would you find out how we write our Sass? If one of our developers were abducted by aliens in the night, how easy would it be for another person to take over an existing feature or pick up where someone else left off? These are things we've spent a lot of time considering, since it's not just our website that grows, but our team as well.

Inline Sass Comments

To reduce the potential for problems, we document everything. We use a documentation style very similar to TomDoc and start every mixin, function and extend with a block of documentation (colloquially, “doc block”) explaining:

• what the following piece of code does
• what arguments it accepts (if any)
• an example for how to use it

We write them all in single-line Sass comments so that they do not get compiled into the generated CSS, allowing us to have documentation without worrying about bloating our code with unnecessary comments.

//
// Prints out the width and height of an element.
//
// $width - String or number representation of the element width
// $height - String or number representation of the element height
// false if it is the same as the width
//
// Examples
// @include size(10px);
// @include size(10px, 30px);
//

@mixin size($width, $height: false) {
  width: $width;
  height: if($height, $height, $width);
}

Having documentation inline in our Sass makes it easy to see at a glance what things do as we're working with our code. Although we mainly focus on commenting mixins and functions, it can also be very helpful to have doc blocks for classes, extends and anything else!

There are also third-party tools you can use to generate style guides based on comments like these. Knyle Style Sheets (KSS) is a human-readable documentation syntax that uses Ruby to parse these comments and generate a style guide. This makes it easy to show your markup, styles and documentation together in one place. Hologram is a similar tool with a different documentation syntax. No matter what route you go, any documentation is better than none.

GitHub Wiki

We also keep a wiki on GitHub containing information that doesn't fit into our style guide or inline comments. It contains information about our Sass that might also extend into our PHP or JavaScript, such as:

• how to enable or disable the responsive layout and different site footers
• how to customize the look and feel of various page headers
• If you use Sublime Text, use the Dependents package to easily navigate through Sass @import dependencies for any given file.

Where the style guide is meant to provide a visualization of different components — and inline comments are intended to provide information about how a small piece of code works — the wiki is used as a higher-level utility to provide more robust information about how all the pieces fit together, making it especially useful for new team members to jump into Sass and start using existing components.

Code Consistency

For as much as we are the keepers of consistency for the UI of the website, we are also the keepers of consistency for our code. But what does “code consistency” really mean? It's all about coding style and, at Behance, we place a high value on code consistency and cleanliness. Coding style encompasses many aspects of writing code, such as:

• how and when to use comments
• how and when to use whitespace
• naming conventions for variables, functions and mixins
• code grouping and organization

The list could go on and on and on. Every programmer has their own natural coding style, formed by any number of factors from how they learned to code originally to the editor they like to code in. But these individual styles are less important than consistency, explains Nicholas Zakas:

“I liken the situation to a group of musicians trying to form a band. Each one comes in believing that their way of doing things is best (their "method” or “process”). The band will struggle so long as everyone is trying to do their own thing. It’s impossible to create good music unless everyone in the band agrees on the tempo, the style and who should take lead during a song. Anyone who has ever heard a high school band perform knows this to be true. Unless everyone is on the same page, you aren’t going to accomplish much.”

We maintain a living wiki in Github of all the coding style standards that our team has agreed on for all of the languages we use (PHP, Sass/CSS, JavaScript and more). Since our standards grow and change over time as we acclimate to new tools, best practices, etc., everyone is a contributor to the coding style guide, and we discuss all changes or additions as a team.

We've set up hooks in Github to run scss-lint on any Sass code we push before it can go to master, which runs checks on our coding style (or “lints” it) to make sure the code abides by our standards. There are many other popular linting and code quality tools for other languages (such as JSHint, JSCS and PHPCS — all of which we use. And for “vanilla” CSS, there is CSS Lint.

These tools mean that our pull request reviews — the process by which a team member gets their code into master in Git — are more meaningful, since we can focus on the integrity of the functionality and ideas behind the code, rather than on code style.

Onwards to Scalable Sass!

If you've read part 1, you now know how to use Sass to organize and optimize your code using partials, how to utilize powerful Sass and Compass features, and how to create your own custom frameworks. With this part 2, you learned various ways to document and share knowledge of your codebase with other developers, maintain style guides for consistency and transparency, and how to keep code healthy with coding standards and tools. Using these starting points, you and your team can be writing and maintaining healthy code for a big website in no time!

Writing CSS for a giant, expanding, ever-evolving website is hard. Writing maintainable CSS that is consistent, easy to understand, simple to reuse and hard to break is even harder! At Behance, our website reaches over 130 pages, many of which exist in multiple states (e.g. logged in or out) and in a wide range of ages (some pages are brand new, some are over a year old, and one or two persist from over 3 years ago!). We’re continuously adding, changing or even slimming down features. And with the constant evolution of the site — and the team that builds it — we face many challenges in keeping the site and its codebase organized. Over the years, our process has changed and grown, and Sass has made a tremendous impact on our workflow, how we write code, and how we tackle all of the challenges of maintaining a huge codebase.

Keepers of Consistency

As front-end developers, I like to say that we are the “keepers of consistency” — the ones responsible for making sure shared UI elements and components are consistent across the entire site for a cohesive look and feel. Sass aids us in ensuring consistency in several ways:

• We maintain a list of variables for global values, mixins, and functions that are reusable across the site.
• We use partials for file management and code organization.
• We use some extra techniques for boosting our responsive code

Defaults and Overrides

All popular CSS pre-processors today let you use variables out of the box, something CSS developers dreamed of for years! For this, we keep a _variables.scss file in our root /sass folder which gets imported into every Sass file (along with a _mixins.scss and a _functions.scss).

Additionally, sometimes we create smaller _variables.scss files inside page-specific folders if a section of the site needs to share a set of variables that the other parts of the site don’t care about. For example, our root _variables.scss contains stuff like this:

// colors
$brand-color: #005cff;
$base-color: #3d3d3d;
$alt-color: #ededed;

// input dimensions
$input-height-small: 25px;
$input-height-normal: 31px;
$input-height-large: 34px;

// general-use breakpoints
$medium-upper-limit: 1024px !default;
$small-upper-limit: 603px !default;

$break-large: ($medium-upper-limit + 1);
$break-medium: ($small-upper-limit + 1) $medium-upper-limit;
$break-small: 0 $small-upper-limit;
$break-small-and-medium: 0 $medium-upper-limit;

The !default flag on some of our variables lets us define default values. That is, if the variable has already been assigned, it won’t be reassigned. But if it doesn’t have a value yet, it will be given one. We sometimes use this to override global values that we want to modify for specific situations.

Many of our reusable components calculate dimensions based on these global variables. For example, one of our reusable components is a grouping of project covers that can appear 1, 2 or 3 images wide depending on our breakpoint values. The reusable component’s partial, _gallery_projects.scss automatically outputs the styles needed for the breakpoints defined above.

Any time we want to change the breakpoints for this component, we need to override the global values that the mixin is using like so:

$medium-upper-limit 1200px;
$small-upper-limit: 0 699px;
@include '_variables.scss';
@include '_gallery_projects.scss';

Since the $medium-upper-limit and $small-upper-limit variables are defined with the !default flag, the $break-medium and $break-small variables are calculated using the new values. and the Sass will compile using the newly defined variables.

Managing Files

The first major impact Sass has for us is in terms of the structure and management of our CSS (Sass, that is) files and folders. There are two components to this:

• How we structure top-level files
• How we structure and use smaller reusable chunks of code

Our top-level Sass files compile directly into CSS and are loaded on the page via a normal link element, and our modular code lives within partials. Here’s an abbreviated look at what our folder structure looks like:

Top-level Files

Our top-level files all sit in the /sass folder root. Every page loads our base files, normalize.css and global.css, and then each individual page additionally loads its own CSS file(s). Here’s an example snippet of what the head of a user’s profile page:

<link rel="stylesheet" href="http://webstandardssherpa.com/normalize.css" />
<link rel="stylesheet" href="http://webstandardssherpa.com/global.css" />
<link rel="stylesheet" href="http://webstandardssherpa.com/profile.css" />

In production, we minify and concatenate our CSS files so they are as small and as few as possible. Our build scripts and PHP framework handles this for us.

Smaller Chunks of Code

The second way we use Sass for file management deals with smaller chunks of code. We use Sass partials, files that do not compile directly to a CSS file on their own, in two ways:

• Reusable components
• General code organization

We often split up particularly large page-specific Sass files into into smaller partials, even if they will not be re-used, to help clearly delineate where code is. Here’s our abbreviated view of our file structure, with the folders from the previous example expanded:

Global and Reusable Components

Our global.scss file contains Sass for standard things like the site background color, font stacks, etc. We use partials to compartmentalize the code for global elements such as buttons, dialogs, tooltips, icons and much more, which are in a folder called /_global. Then, in our global.scss file, we use the sass-globbing extension to import them all at once:

@import '_global/*.scss';

The sass-globbing extension lets us import everything in our /_global folder in one line, and the contents of each partial end up in the compiled global.css file. Using this technique, we are free from having to manage a long list of imports, avoiding something like:

@import '_global/_buttons.scss';
@import '_global/_dialogs.scss';
@import '_global/_icons.scss';
@import '_global/_tooltip.scss';
@import '_global/_warnings.scss';
...

In addition to the /_global folder, we keep a top-level /_components folder for components that can be used on any page, but that are not used on every page. The difference here is that the partials in the /_global folder are automatically included in our global.scss file, and the files in the /_components folder can be imported by any individual file that needs it. Having two separate folders make it easy to know at a glance which ones are okay to cherry-pick and which ones are already available on every page. The underscore in the folder name makes it clear that those folders only contain partials.

Partials for Code Organization

For page-specific partials (things that will not be re-used and are only for code organization), they live within a folder named for that page. For example, the imports in our project.scss file look like so:

@import '_components/_multiple-owners.scss';
@import 'project/_comments.scss';
@import 'project/_sidebar.scss';

The _comments.scss and _sidebar.scss partials style specific parts of the project page, so they live inside the /project folder. Though they are not re-used on other pages, the code is complex or lengthy enough to warrant a separation from the main project.scss file to make the code is easier to navigate. (Our project.scss file would be over 600 lines long if we didn’t split it into smaller pieces!)

Overall, we have over 40 general-use partials in our /_components folder, each one used in two or more places around the site. We also have at least 15 global partials in our /_global folder. Sass partials and the sass-globbing extension help us structure our code in a way that makes managing and using it infinitely easier and more clear than if we tried to attempt this in vanilla CSS. In fact, I can hardly even imagine a vanilla CSS solution to this! Without partials, our giant CSS code base would be much bulkier and incredibly difficult to manage.

Responsive Breakpoints

In the same way that our CSS is responsive, our JavaScript must be as well. Some interfaces and interactions change depending on browser size, so both sides of the code must use the same breakpoint values in order for the user experience to be seamless. To prevent having to hard-code values in two separate parts of the code, we use a technique that allows us to store our breakpoints in a JSON file and retrieve them from both the Sass and the JavaScript side.

For example, we can define our breakpoints in a JSON file:

{
  "phone"  : "all and (max-width: 603px)",
  "desktop": "all and (min-width: 1025px)",
  "tablet" : "all and (min-width: 604px) and (max-width: 1024px)"
}

Then, using a custom Ruby function to load and parse the JSON file, we can access those values in our Sass:

$break-desktop: get_breakpoint(desktop);
$break-tablet: get_breakpoint(tablet);
$break-phone: get_breakpoint(phone);
 
@media #{$break-desktop} {
  body {
    background: red;
  } 
}

Since the breakpoints are stored in JSON, you can use something like require.js to load the JSON file into your JavaScript and use those values there as well.

Similarly, Viget Labs created a simple JSON importer to @import a .json file directly into your Sass, translating JSON objects into variables. When Sass 3.3 was released, a new data type called maps was introduced, which has a structure similar to JSON objects.

The Sass JSON Vars plugin will translate your JSON object into a Sass map if your version of Sass is high enough, or just standard variables if not. This technique can be useful for any number of other things in addition to responsive breakpoints!

Special Sass Peripherals

In addition to built-in Sass features, we also use some external libraries to supercharge our code. We’ve already mentioned sass-globbing, but one that has made the biggest impact on us is Compass. It’s popular for its utility mixins that generate verbose code like gradients or remove the need for you to type vendor prefixes, which we often make use of. Compass also has very powerful sprite generation tools that have made a huge impact on how we create and use sprites on our website.

Sprites

Behance makes use of many icons throughout the site, and although we recently converted many to use an icon font, there are still a large number that come from a sprite sheet. In the past, these sprite sheets were built manually by organizing many small images into one big image by a designer. Then, a developer would closely inspect the image to determine coordinates and dimensions for every image, and then manually type all that information into a CSS file … a process very time consuming for everyone involved.

But Compass sprite generation makes the process about a billion times easier. Just drop your individual images into a folder, write a few specific lines of Sass, and Compass will stitch your images together into one sprite file and generate all the CSS for you: classes, dimensions, coordinates and all. You can even choose to take a more hands-on approach and use Compass’ sprite helpers for more fine-grained control over how your sprite CSS is generated.

In just a few short lines you can make a sprite with CSS for each icon’s class, background position and dimension:

$icons-layout: horizontal;
$icons-sprite-dimensions: true;

@import "compass/utilities/sprites/base";
@import "../images/icons/*.png";
@include all-icons-sprites;

“Magic” variables exist to set various options for the sprite. They’re called “magic” because they exist based on the name of the folder holding your individual images, which in this example is /icons. The last three lines of code generate the sprite and CSS based on a combination of default options and the ones defined above.

These tools also make it very easy to create and use high pixels-per-inch, or high pixel density, sprites. By separating your 1x and 2x sprites into separate folders and setting the orientation of both sprites to be the same, only a few lines of Sass are needed to define high PPI sprite:

$icons: "icons/*.png";
$icons-2x: "icons-2x/*.png";

$icons-sprite-dimensions: true;

$icons-sprite: sprite-map($icons, $layout: horizontal);
$icons-2x-sprite: sprite-map($icons-2x, $layout: horizontal);

.icon {
  background: sprite-url($icons-sprite);
}

@include pixel-ratio {
  .icon {
    background-image: sprite-url($icons-2x-sprite);
    background-size: image-width(sprite-path($icons-sprite)) image-height(sprite-path($icons-sprite));
  }
}

In this example, our 1x icons are in the folder /icons and the 2x icons are in /icons-2x. We set our 1x sprite as the background image for the .icon class. The pixel-ratio mixin prints out a pixel-ratio media query that overrides the .icon class’ background with the 2x image. The use of background-size shrinks the 2x image down to the dimensions of the 1x sprite, giving it a higher pixel density.

As an added bonus, the Photoshop plugin Slicy quickly exports assets from a single PSD into individual images, simplfying the initial process of saving images out of mockups too. If you are using the latest version of Photoshop CC, the built-in export assets feature can help with this, too.

Overall, Compass sprite generation has been invaluable in its ease of use and the amount of time it has saved us.

Coming Next

In part 2, we’ll explore the knowledge sharing aspect of writing Sass for a huge website. We’ll go over living style guides, documentation and tools to keep all your developers on the same page and make onboarding new team members to your codebase easy.

Every design process starts with “discovery” or something to that effect. For web builders, discovery allows us to dive into the waters of our client’s new world to observe, study and understand as much as we can before proceeding with solutions.

How do we decide where and how to explore, set our course, and move forward? And how does a new responsive web, without constraints of device widths, affect that exploration? These are the tricky questions that need to be answered at the beginning of a project.

Before You Weigh Anchor, Consider Your Charter

The first task is to discuss the true problem your client is trying to solve. Of course, this may or may not be the problem they originally state. Essentially, “what you want to discover” is one of the earliest — and most critical — activities of the project. At Sparkbox, we prefer to do this with initial engagements. We offer clients small, introductory projects to establish our charter. The entire goal is to explore the problem, identify limits and opportunities, and map out a course.

Discovering the true problem together shows a client how powerful a collaborative relationship can be for the project moving forward. The path to truly meaningful work requires the voice and perspective of all relevant project players and relies on collaboration to guide a team through project twists and turns.

Set Your Course

Once we know the overarching problem we are trying to solve, we can begin to explore the space and factors around the problem.

Below are tools we use to set course on projects, but keep in mind that this is not a one-size-fits-all list. You have to pick and choose what makes sense for a project. Client size, budget, timeline, experience and personality all must be considered. Choose tools that will allow you and the client to dig directly into the core problem and take informed steps toward a solution. It doesn’t have to all come from one activity, and it doesn’t have to be super formal. It all comes back to improving it as you go.

Tool #1: Content Audits

This is nothing more than an exhaustive look at all of the information that exists on a site today. You then evaluate that content and propose what content should exist on the site going forward. There are a million types of content audits out there. Just look at this “content audit” Google image search which shows just some of the approaches you could take:

• You can include the Audience(s)
• You can rank it based on Voice & Tone, Usefulness, Clarity, Engagement, and Findability
• Say whether you should Keep, Edit or Delete

The best approach is to start with the basics and add when you see something relevant to track for a particular client.

Tool #2: Discovering the Brand

Kate Kiefer Lee came up with the idea for a brand voice and tone guide, and shared MailChimp’s Voice & Tone Guide publicly. The guide is intended for all the people who are talking and writing on behalf of your brand to keep things consistent, but it’s great for even more than that. A simple voice and tone guide is a great way to not only help your client write copy later, but also to make sure you and your client are on the same page about who they are. FORGE also offers a free brand workbook that is a great discovery tool for understanding your client’s brand. This step is often most useful for smaller clients who don’t already have very detailed brand documents.

Tool #3: Design Comparisons

Dan Mall came up with a great exercise to help capture the essence of what a site should look like. Design Comparisons are a presentation of opposite design options (light or dark, modern or traditional, etc.) that you show your clients, and have them pick which style is more appropriate and share why that choice is more appropriate.

Tool #4: Style Prototypes

Samantha Warren created Style Tiles, which she describes as:

A design deliverable consisting of fonts, colors and interface elements that communicate the essence of a visual brand for the web.

While Style Tiles are a static design tool, we’ve adapted the idea to create Style Prototypes, which have all the same elements as Style Tiles, but live in the browser. Moving these early design elements into the browser means your client can review in multiple devices and browsers, which allows you to remind them (early and often) of the realities of responsive web design: There is no one site experience.

Ben Callahan has a detailed post that covers how we work through design in more detail.

Tool #5: Content Priority Guides

Working through a full content audit helps you identify what pages will need to exist on a new site and which of those require unique templates. Our Content Priority Guide takes the unique pages of a site and breaks them down into what content will need to appear on those pages in priority order. This step gives us a really good understanding of the content on the site and how it all lives together (awesome for both design and development). And it gives whoever is writing copy a great guide to get moving early. It can even get you most of what you need to plan the content management system, as well.

Tool #6: Visual Priority Guides and Wireframes

Our Visual Priority Guide is a single deliverable that provides direction for content-focused design and mobile-first development in something resembling a wireframe. It is similar to the content priorities mentioned previously but a bit more visual. For content-heavy pages without much functionality, a content priority guide can typically replace the need for a visual priority guide/wireframe. However, these are a great enhancement of the content priorities when you start to get into interactions, such as special filtering and searching.

Be Willing to Adjust Course and Revisit Scope

Remember to be humble and adjust as you need to. Budget, timeline and personalities might force you to change course or tools during discovery. That’s okay — it’s honestly the point of this project stage. Having a toolkit and project plan to pull from is great, but you will still have to make it up as you go in order to serve your client well. And don’t be afraid when you spot something that needs to change as you navigate the project. New discoveries are not bad things.

Corrections should be a welcomed sign that you are visiting the right places, and getting honest feedback and details to improve the project. Don’t hide them out of embarrassment that you weren’t able to predict the future (or read the collective mind of your client’s organization). State the facts and make your case for a project shift. Good clients crave partners who legitimately have their best interest in mind — not just “yes men.”

Being rigid to an initial plan will hurt you. Because even a successfully executed project can become a business failure if it only achieves the goals of an out-of-date and less-informed hypothesis.

Get Moving

The goal in discovery is to get a project moving, not to outline the entirety of the project. Instead, discovery should establish a cadence that echoes throughout every client meeting and line of code. Real discovery reveals itself throughout each step of the process, so move forward as soon as possible — and keep moving.

Flexibility Is the New Norm

In case you haven't heard, the web is not fixed width. While most of us have accepted this as truth for a while now, we haven't really figured out how to embrace this flexibility in the way we work. Our workflows should be as flexible as the stuff we're trying to build. In order to do this, we need to start building collaboration into our culture. We need to inspire our people to prove this idea in their everyday work with each other and with our clients.

Over the past few years, this thinking has infiltrated almost every part of how I work in my role as President of Sparkbox — from writing estimates to writing code. It requires approaching everything with an eye toward collaboration, inviting others into the conversation and demonstrating that the sum of the parts is truly greater than the whole. In this piece, I hope to share a glimpse of how we encourage these ideals at Sparkbox.

Why Collaboration?

Every project, every timeline, every budget, every client, every team member, every unforeseen factor combine to create a unique set of constraints within which you are expected to do amazing work. Trust me when I tell you that there is no one way to do this stuff.

In order to build great stuff in an ever-changing environment, we need to start investing in our people instead of our process. Thinking in this way has allowed my team to build better products, spread critical knowledge throughout our team, and encourage great increases in individual skill and confidence. Who doesn't want that?

A Collaborative Environment

Truly timeless work can only be created when individuals relinquish their egos and are willing to put the good of the group above themselves. It also requires an environment where teams are encouraged and expected to find a better way. Here are some concepts that have stuck with me as I push to make our environment more collaborative.

The Rigidity of Your Process

There was a time when I spent a solid three weeks writing a 15-page explanation of my web design and development process. I thought I had it all figured out. Each step had specific deliverables that my client would approve, and each step moved us a little closer to the end goal. My customers loved it — I was very proud.

What I learned, very quickly, is that each new project I tackled required changes to this “perfect process.”; Each project was different. So different that, eventually, I stopped trying to force my 15-pager onto innocent, unsuspecting clients. Instead, I embraced the idea that I would know more about the project tomorrow than I do today. I started letting the evolution of learning carry the project forward, always focusing on the actual deliverable.

Because I tend to be a guy with a fairly extreme personality, I took this pretty far pretty fast. I've been speaking and writing about this idea of Group Improvisation, with the hope that people will let go of their rigid process and start to trust their people. Here's the thing, it's not quite so simple. Consider this diagram:

Moving from left to right on the x-axis, it charts your team's growth of experience. Moving from the bottom to the top, it charts the rigidity of your process, from very rigid to improvisational.

I believe the goal is to reach the top right quadrant, where your team is highly experienced and the process very fluid. This helps cultivate a culture of trust where regular innovation is happening and excellent work is created. Allowing an inexperienced team to work in an improvisational way results in terrible work and missed deadlines and budgets. You can see this illustrated in the top left quadrant.

In order to take your team from the top left to the top right, you need to first put a somewhat rigid process in place, which moves you to the bottom left quadrant. It's a more structured process which allows your team to gain experience. Only then can you slowly remove some of the structure — forcing more collaboration — and allow your team to truly flourish.

It's important to note that teams working in that top right quadrant do have processes. The major difference is that they don't have something prescribed to them. Instead, they're allowed to experiment and decide — as a group — what the best approach is. It's this level of trust that empowers them to do great work and allows them to feel the ownership needed to truly put the project above themselves.

This model requires the leadership of an organization to keep a pulse on the experience of the team and adjust expectations around the rigidity of the process accordingly. This presents some challenges. For example, if your organization struggles with employee retention, they may never gain the experience together needed to reach that top right quadrant.

Writing and Speaking

When I first started to be more intentional about writing and speaking, it dawned on me how much I personally benefitted from the teaching experience. If I'm going to put something out there in an attempt to share my knowledge, I want to make sure I've read other writings on the topic. I need a very good awareness of what's currently happening around the subject matter in the community. For every article I write, I read 20.

It didn't take long for me to begin encouraging the same with my team. At first, this was very difficult for some — it's human nature to feel you don't have much to offer. The truth is, there's always someone smarter than you, and there's always someone a little behind you.

From a policy standpoint, this requires putting your money where your mouth is. At Sparkbox, we lowered our expectation about the amount of time our employees do billable work in an effort to provide them with the time to learn. We also give our employees time off for events where they are speaking. And, to continue encouraging the culture of learning, we have a “Send a Friend” policy. This means we will send another Sparkboxer to an event where one of our team members is speaking.

While policies and procedures can help, I believe this kind of approach requires leading by example. And, don't expect it to be easy. Even now, we struggle with it. Trust me when I tell you, creating a policy that everyone writes is not enough. In fact, I would suggest that you not force your team to do this stuff. Instead, let your people find the ways they are willing to contribute back to the community. For some, that may be open source side projects, for others it may be in-depth case studies. All of this is valuable — the point is to allow your team time to learn.

Mentoring and Apprenticeships

In the same way that writing and speaking can make you smarter, teaching in a more intimate setting is a great way to question your previous assumptions. To provide more teaching opportunities to our team, we run a six-month apprenticeship each year. This brings motivated, hungry, passionate people into our space for an extended time where their primary goal is to learn. We provide a curriculum for them to dig into, and a large part of their time is spent pairing with our full-time people. This one-on-one time is an incredibly powerful way for both student and teacher to grow. If you've ever had the opportunity to teach, you know that teaching truly makes you better understand your subject matter.

In addition to the apprenticeship program, we also look for opportunities to cross-pollinate inside our own team. This happens in many ways, but the most common occurs when a natural leader emerges and collaborates with those on her team to help them improve. This works best when it happens organically, but we occasionally take a more structured approach. Typically this is when there's a specific need for one individual to grow in an area where someone else has great experience. Simply encouraging them to work together on something is usually enough.

Regardless of how it happens, there's no arguing that teaching makes you smarter. I can't express enough how helpful this has been for our team in creating a collaborative environment.

Tooling and Workflows

There are also plenty of ways to incorporate more collaborative tooling into your team's daily work. While these things alone won't create collaboration, they can certainly make it easier.

Google FTW

We use Google Drive extensively because of the real-time collaboration it allows. All content documentation is either done in Drive or in HTML. The ability for our clients to directly edit, suggest, comment on the priorities of content and functionality makes this an invaluable part of our tooling. Additionally, most clients completely understand how to use these tools, whereas more industry-specific tools (Omnigraffel, Visio, Balsamiq, etc.) create a barrier to entry for your customer.

Opt-In, Whole-Team Communication

We recently made the switch to using Slack for real-time communication. It allows for channels (think, “topics”) which our team can opt in or out of, private groups (invite-only), direct messaging, and (most importantly) custom emoji. It also has some excellent integration with tools like Google Hangouts and Screen Hero and it is all archive-able and searchable. Our team lives in Slack all day, every day.

Source Control and Issue Tracking

I would be incredibly remiss if I didn't mention Github here. All of our people use Git on pretty much every project. We rely heavily on the issue tracking, often times even inviting our clients to participate. We also follow a very simple collaborative workflow which employs git branching and pull-requesting.

Almost any task is created as an issue on the repository. An individual creates a branch from master to work locally. When the task is complete, they push to github and pull request their branch. Another team member reviews the code, tests it locally, and makes comments. Once the branch is in good shape, it's merged into master and work continues.

This branch/pull-request/merge workflow builds collaborative code review into our development process. Rarely does a pull request get merged into master without changes. Many times, we catch simple issues before they're ever merged and deployed. Another great benefit of a workflow like this is that more people understand more of the code. Spreading the knowledge around the team only makes us all smarter, and better prepares the team for inevitable time off, etc.

We've also been experimenting with Huboard lately as a way to better organize and see progress on Github issues. This tool provides an excellent dashboard view of the work currently in progress and next to be tackled.

Collaborative Space

We've tried a lot of things to encourage collaboration in our space. Firstly, we have a lot of different kinds of space available for people to use. A good portion of what we offer is a large open room with three long desks. These desks are capable of seating six people each (three per side), but we generally have four people at each, leaving the middle seat on each side open for pairing.

At the end of each of these desks, and in various other places through the office, we have televisions mounted to the wall, each with an Apple TV. This allows all of us to quickly and easily Air Display their our screen to any TV in the building. Newer version of iOS allow us to send mobile device output to these as well. It makes for great demos and keeps the barrier of entry for getting feedback on something very low.

Because of the amount of people in our space, we decided to remove phones from the big room. Instead, we created some small phone booths with sound absorbent materials just off the main room. These, combined with a small conference room and video conference room, give ample options for communicating with remote teams, employees or clients.

We're also huge fans of whiteboards. Almost every wall in our space has been painted with whiteboard paint. It's not cheap, but it's much less expensive than buying whiteboards to cover the space. We also chose conference room tables that are glass with a white frosting on the bottom. This means we can write on all of our meeting room tables as well — something that happens in just about every meeting.

Our space also offers a full kitchen and an area where we can all sit to eat together. It may sound trite, but enjoying food together is one way we try to create a comfortable environment. I believe it's critical to know your co-workers in more than just a working context. We find cooking and eating together each Friday is a great way to encourage this.

Collaborative Org Chart

A lot has been written about the benefits and challenges of a flat organizational structure. I'm not here to tell you that flattening the org chart is the only way to foster collaboration, but I do believe that our flat structure encourages it.

Flat org charts only work if your team understands why you make the decisions you do. When that happens, individuals are empowered to lead organically in a way that aligns with the vision of the company. Empowered people aren't threatened by collaboration. There's no competition to climb the ladder, instead there's a true desire to improve the whole. This is what I want from my team and what benefits our clients the most.

Our org chart has two boxes: one is the people who work on the business and the other is the people who work in the business. Most folks are working 100% of their time in the business. Inside this box, leaders emerge and naturally take on more responsibility. Again, this may not work for everyone, but it seems to be working well for us.

The Ever-Changing Way

For us, these concepts have been almost accidental. We didn't start out to build a place where collaboration and learning were the “secret ingredients.” Instead, we simply wanted to build things the right way. What we've landed on, at least for now, is the only way we know how to operate at the level we desire given the constant curve balls this industry throws.

I am certain we're far from done. So far, I can tell you that this approach requires a strong belief in your people and a demonstration of humility from the top down. It takes a long time, and it's not something you can fake. However, I believe it's necessary to stay relevant in this ever-changing industry.

Every now and then, it's good to take a critical eye to the work you've done and look for ways to improve it, so this review is going to turn the microscope around and focus on the Web Standards Sherpa site. It's a tough thing to make time for on a largely volunteer project when your team is pretty much flat-out on client work, but we carved out some time in the first few months of this year to revisit this site and make some changes that would help our content go further.

Best Practices Change

We launched Web Standards Sherpa on March 13, 2011. At the time, CSS Media Queries were relatively new and, though we put a lot of thought into how we could use them, we hadn't really put much collective thought into how we should use them.

As such, our approach for this project ended up tracking Ethan Marcotte's concept of Responsive Web Design (RWD) — fluid grids, flexible media, and media queries — but it did so from a ”desktop-first“ perspective, using primarily max-width-based media queries:

@media screen {
    /* Desktop Rule Sets (universal) */
}
@media screen and (max-device-width:480px) { 
      /* Small Screen Rule Sets */
}
@media screen and (min-device-width:481px) and (max-device-width:1024px) {
    /* The Squishy Middle Rule Sets */
}

At the time, it just made sense to take that approach: We had been designing, prototyping, and building the site for several months before media queries even became a viable option, and we had no interest in maintaining a separate mobile site. So we added RWD into the project in the final month and made it work.

The result was decent. If you used it on mobile, the site worked, but it was clear that the mobile experience was an afterthought. You could use the site in all the then state-of-the-art mobile browsers — Safari, Android, Dolphin, Opera Mini, and Opera Mobile — but interactions were more than a little clunky.

Fast-forward two years and the mobile experience was falling apart. Browsers had gotten a little more savvy — or picky, depending on how you look at it — in how they were handling media queries and viewport-sizing instructions, and Web Standards Sherpa just looked haggard. It needed a makeover.

From "Mobile Friendly" to "Mobile First"

Design-wise, the site is still pretty amazing: Dan Cederholm crafted a timeless look and feel for the site and Steph Troeth's and Kelly McCarthy's information architecture was still quite solid. All we needed to do was make mobile a first-rate experience from a styling and interaction perspective.

I wrote on the Easy Designs Blog about making the switch from a “mobile-friendly,” desktop-first site to a “mobile first” one. In it, I discussed how looking at a site from the mobile perspective first is a great way to integrate progressive enhancement:

“[Y]ou optimize your site for use in a mobile context, and then layer on extra styles, JavaScript and content as you find you have more real estate to work with or a more capable device.”

In practice, that lead to quite a few changes:

We Swapped Pixels for Ems

We adjusted our media queries to use em units) instead of pixels to provide the most appropriate reading experience based on the user's font-size preference. That means if my aunt has her font size increased to 2x, but is on a larger screen, she will get a more linear layout more akin to a tablet view at 1x.

Min-width Instead of Max-width

We migrated most of our media queries to reference min-width rather than max-width so that they would start with the smallest screen first and build up from there:

/* Mobile-first Base Rule Sets */

@media only screen and (min-width:20em) {
    /* 20em and up media query-aware browsers */
}

@media only screen and (min-width:30em) {
    /* 30em and up media query-aware browsers */
}

/* And so on… */

We did not throw out a lot of the original CSS, but instead broke it apart and moved rule sets (or parts of them) into the new queries as appropriate. That saved us a lot of time.

We Have Lots of Breakpoints Now

Whereas the original site only had three breakpoints, the current incarnation has a whopping nine. Some follow somewhat typical conventions (20em, 30em, 48em), but others are pretty site-specific (34.375em, 42.5em, 51.25em, 61.25em). The reason for the change is pretty simple: we wanted to provide a solid reading experience across the board. We tweak the design a fair bit in the squishy middle between small screens and large ones.

We are More Touch Friendly Now

Dan's original design had some pretty chunky buttons, so they were quite easy to tap with your finger. Links, however, not so much. We needed to increase the tappable size of the links and the spacing around many of the navigational links to improve tap accuracy. In particular, the links in the footer are quite small and narrowly spaced on desktop. We corrected that on smaller screens where tapping is the more likely interaction model.

We Put CSS and JavaScript on the Same Page

A major headache in most responsive designs is getting CSS and JavaScript to work together. It's easy to swap styles using media queries, but adjusting JavaScript-based functionality is a little more complicated.

Sure, you could use matchMedia to determine if certain conditions are met before generating or destroying a given JavaScript-based user interface. However, doing that requires that you duplicate your media queries in your JavaScript code, and keep them updated along with any CSS changes you make. To avoid that potential maintenance headache we chose a different solution.

Back in 2012, I had written a little JavaScript called watchResize to track the browser window dimensions (and changes to them) to simplify the authoring of screen-size dependent JavaScript. A few months later, taking a cue from Jeremy Keith's post about using clever CSS to inform JavaScript of breakpoints, I built a little jQuery-based helper called getActiveMQ to generate a hidden div and then track the font-family CSS property that was set on it. That meant that on the CSS end, all we needed to do was assign each breakpoint a name:

#getActiveMQ-watcher {
      font-family: "break-0";
}
@media only screen and (min-width: 20em) {
      #getActiveMQ-watcher {
            font-family: "break-1";
    }
}
/* And so on… */

And we could get the currently applied value back via JavaScript:

var current_mq = window.getActiveMQ(); // break-X

Combining watchResize with getActiveMQ, it became simple to track the current media query in a global variable that any JavaScript in the site could reference:

// Create a global Sherpa JS Object
if ( !( 'WSS' in window ) ) { window.WSS = {}; }

// capture the current breakpoint to WSS.screen_size
window.watchResize(function(){
    window.WSS.screen_size = window.getActiveMQ();
});

// Use that value in a lazy-loading images script
window.watchResize(function(){

    var $img = $( '' ),
        $els = $( '[data-image]:not([data-imaged])' ),
        curr_break = window.WSS.screen_size.replace( 'break-', '' );

    // loop through all elements with a data-image attr
    $els.each(function(){

        var $el = $(this),
            // do they have a min-breakpoint set?
            // if not, use break-4
            bp = $el.data('image-min-breakpoint') || 'break-4';

        bp = bp.replace( 'break-', '' );

        // if the current breakpoint is >= the one
        // we are testing for, lazy-load the image
        if ( curr_break >= bp )
        {
            $img.clone()
                .attr( 'src', $el.data('image') )
                .prependTo(
                    $el.attr( 'data-imaged', '' )
                 );
        }

    });

});

Done and done.

Getting Serious About Performance

With our styles working a bit better and our JavaScripts able to follow CSS' lead on the breakpoints, we focused our attention on download speeds.

As I'm sure you can guess, most of our page weight comes from image content. We optimize every image on the site before it even get onto the server, but each one adds up. We didn't want to sacrifice the rich visual design of the site or the helpful screenshots in the articles, so we looked for other ways to speed things up.

We Migrated to SASS

In the years since we built this site, our team has moved over to using SASS to speed up our CSS authoring. On smaller, less complicated sites like Sherpa, we've found Jake Archibald's respond-min/respond-max mixin set quite useful.

Jake's mixin allows us to identify media query blocks but also gives us the ability to strip the rules out of the media queries for older browser that don't understand media queries (like IE 8 and below). We combined those mixins with a set of variables that defined our breakpoints to ensure consistency across our CSS. Here's a sample of what that looks like:

$break-1: 20em;
$break-2: 30em;
/* And so on… */

#getActiveMQ-watcher {

    font-family: "break-0";

    @include respond-min($break-1) {
        font-family: "break-1";
    }

    @include respond-min($break-2) {
        font-family: "break-2";
    }

    /* And so on… */

}

We were using a similar technique for concatenating JavaScript files via the CMS, so we opted to abandon that as well. With the move to SASS, we'd become pretty familiar with running build commands via the command line, so we decided to use Uglify to perform the concatenation and minification. And we employed Grunt to orchestrate all of that and to bring our other build step — image optimization — under one roof.

We Moved our CSS and JavaScript into the CDN

With actual static CSS and JavaScript files, we finally had the opportunity to move these files into the CDN (which we were already using for article images). That meant users around the globe would get these files faster.

If you are not familiar with CDNs, they are a great way to skirt browser limits on parallel connections.

We Got Lazier

In the original version of the site, we were using a technique called “lazy loading” to inject the markup for the homepage carousel only when the user was using a large screen and had JavaScript support. We opted to take that route because, while we wanted the carousel to enable a user to move backward and forward in time to see every article, we didn't think the carousel would provide a good experience on small screens, we knew loading all of that content would not be very bandwidth-friendly, and we also knew that without JavaScript the carousel would not actually work.

In the interest of being more bandwidth friendly throughout the site, we opted to use lazy loading for more pieces of content.

We rolled article comments, which were once in their own section of the site, into the article pages themselves to provide a more integrated experience. As supplementary content, though, they were a great candidate for lazy loading. We did want to keep the comments available to non-Javascript users too though, so we used a slightly customized version of Scott Jehl's anchor-include pattern to turn a direct link to an actual, separate comments page into a trigger for loading the comments asynchronously:

<a href="http://webstandardssherpa.com/reviews/curing-the-jetblues/comments/#comments"
    data-include-on-tap
    data-replace="http://webstandardssherpa.com/comments/curing-the-jetblues/"
    data-include-size="5">View comments on 
    this entry and add your own</a>

The data-* attribute-based instructions here tell JavaScript to replace this link with the HTML retrieved from /comments/curing-the-jetblues/ if the breakpoint is “5” or larger or if the user is on a smaller screen and taps on the link.

We chose a slightly different tactic for managing images. Since article images are fairly useful for illustrating points made in the prose, we felt they were first-rate content important enough to have available to users even if JavaScript was not available. For that reason, we chose to implement Sebastiano Armeli's jQuery Asynchronous Image Loader (JAIL).

The JAIL markup pattern is pretty simple:

<img class="jail"
    src="data:image/gif;base64…"
    data-src="http://webstandardssherpa.com/r/5-3.png" alt=""/>
<noscript><img src="http://webstandardssherpa.com/r/5-3.png" alt=""/></noscript>

The markup includes the data URI version of a 1x1 alpha-transparent GIF with a data-* attribute indicating the location of the real image. JavaScript will load that image asynchronously when they user scrolls to within a certain (configurable) distance of it in the flow of the document. This means you don't actually download an image unless we're pretty sure you're going to see it.

The noscript is there to provide a non-JavaScript alternative.

We Removed the Share Widgets

Well, that's not totally accurate. We didn't remove links to share our content on your favorite social and professional networks, but we did jettison the JavaScript code provided by these networks and went with good old fashioned links instead. We did so for a two primary reasons:

1. Using third party widgets allows those third parties to track your users and regardless of whether they admit to doing anything with the knowledge that you are viewing our content, we don't like the fact that they could.
2. Even though CDNs deliver these widgets, they are an additional resource to download and, moreover, an additional JavaScript to execute. Numerous sites have seen third party widgets drastically slow page rendering and we wouldn't want that.

The Numbers

You're probably wondering the overall impact of these changes. The table below has the details, but the changes generally dropped the page size by a third or more.

And then there's the added benefits of fewer asset requests overall and better use of the CDN and caching. So in addition to better serving mobile users from a visual design standpoint, we are also improving things when it comes to experience design. And we're making it cheaper to read our content for those of you on a metered internet connection.

Author's Note: Credit where credit is due, Jeff Bridgforth implemented the vast majority of these changes. Thanks for all your hard work Jeff!

In Part 1 of this series, I introduced you to CodeKit and Sass basics like partials, variables, comments and errors. In Part 2, I showed you how to achieve vertical rhythm using variables and math operators, and demonstrated how the Sass nesting syntax makes media queries easier to maintain.

In this Part 3, I'm going to explore mixins and placeholders, and demonstrate how to use frameworks to import useful mixins and make development faster.

Mixins

Mixins are another key element of Sass, and they can be very powerful. Mixins are essentially formulas of different CSS or Sass rules grouped together. The same mixin can be used in multiple places throughout a stylesheet. If the mixin rules are changed, the output CSS will be changed wherever that mixin is used, which can save a lot of time and repetition.

You define a mixin with the @mixin directive, followed by a unique name of your choice. The curly brackets contain the style declarations for that mixin:

@mixin mixin-name {
  margin: 0;
  padding: 0;
}

You can then reference the mixin in your Sass by including it in a rule:

ul {
  @include mixin-name;
}

Which compiles to the CSS:

ul {
  margin: 0;
  padding: 0;
}

Mixins with Variables

You can use variables in mixins to create reusable chunks of CSS that can vary slightly each time they appear. Consider these navigation buttons, which share some fundamental styles with a few variations:

With traditional CSS, the button rules might look something like this:

.button {
  border-radius: 10px;
  padding: 0 15px;
  text-decoration: none;
  text-transform: uppercase;
}

.active-button {
  background: #637a3d;
  color: #c0d0aa
}

.inactive-button {
  background: #3f5526;
  color: #f9f9f9;
}

And the HTML would reference two classes in order to have both the base and variant styles:

<a class="button active-button" href="">Button</a>

With Sass mixins, you can bring these common rules together in one mixin, specifying their different text and background colors using variables. First, define the mixin with a name, then list the variables that the mixin will use, separated by commas, inside parenthesis:

@mixin button($text, $background) {
}

Next, within the curly braces for the mixin rule, add the common properties and values:

@mixin button($text, $background) {
  border-radius: 10px;
  padding: 0 15px;
  text-decoration: none;
  text-transform: uppercase;
}

For the styles that will vary, use variables for the property values:

@mixin button($text, $background) {
  background: $background;
  border-radius: 10px;
  color: $text;
  padding: 0 15px;
  text-decoration: none;
  text-transform: uppercase;
}

Then apply the mixin to each unique button rule using the @include directive, replacing the $text and $background variable names with the actual values you'd like to use, which can themselves be variables defined elsewhere in your Sass. Here I'm using the color variables I defined in Part 1:

.active-button {
  @include button($green-mid, $green-light);
}

The values must occur in the same order as they are defined in the mixin so Sass can apply them in the proper order when it compiles the CSS. Here, the first value is for the text color and the second value is the background color. Our two button variations can now use the same mixin with different color values:

.active-button {
  @include button($green-mid, $green-light);
}

.inactive-button {
  @include button($grey-light, $green-dark);
}

Which compiles to:

.active-button {
  border-radius: 10px;
  background: #637a3d;
  color: #c0d0aa
  padding: 0 15px;
  text-decoration: none;
  text-transform: uppercase;
}

.inactive-button {
  border-radius: 10px;
  background: #3f5526;
  color: #f9f9f9;
  padding: 0 15px;
  text-decoration: none;
  text-transform: uppercase;
}

Mixins vs. Placeholders

In the Web Talk Dog Walk site, I might use a mixin to hide content visually but allow screen readers to access it (screen readers won’t read content hidden with display:none):

@mixin hide {
  height: 0;
  margin: 0;
  overflow: hidden;
  padding: 0;
}

The hide mixin is a handy set of rules, and not specific to any HTML element. This means I could use it for many elements on the site:

.site-title {
  @include hide;
}

.skip-link {
  @include hide;
}

Unfortunately, this results in the same set of declarations output twice:

.site-title {
  height: 0;
  margin: 0;
  overflow: hidden;
  padding: 0;
}

.skip-link {
  height: 0;
  margin: 0;
  overflow: hidden;
  padding: 0;
}

Not only is this is unnecessarily repetitive, it adds bloat to the CSS file. This is where placeholders come in handy.

Placeholders

Placeholders are much like mixins, but they don't work with variables. Most importantly, placeholder output is grouped together into one rule in the compiled CSS. Define a placeholder with a % followed by a unique name. The curly braces contain the style declarations for that placeholder:

%hide {
  height: 0;
  margin: 0;
  overflow: hidden;
  padding: 0;
}

To include the placeholder's styles within a rule, use the @extend directive:

.site-title {
  @extend %hide;
}

.skip-link {
  @extend %hide;
}

This approach is very similar to including the mixin, but the difference is that the %hide placeholder CSS will be compiled as one rule:

.site-title, 
.skip-link {
  height: 0;
  margin: 0;
  overflow: hidden;
  padding: 0;
}

Sass collects all the selectors for every rule where the placeholder appears and puts them into one rule, applying the placeholder's styling to all of those elements. This results in less repetition than using a mixin, giving you a smaller, faster stylesheet.

Using Mixins for Prefix Support

One popular use of mixins is to automatically include vendor prefixes. There are many properties in CSS3 that will only work in some browsers with the correct prefix. CSS transitions, for example:

a {
  background-color: #ff3000;
  -webkit-transition: background-color 1s ease;
  -moz-transition: background-color 1s ease;
  -ms-transition: background-color 1s ease;
  -o-transition: background-color 1s ease;
  transition: background-color 1s ease;
}

a:hover {
  background-color: #ff9500;
}

Staying up-to-date with the changes in all modern browsers is a lot of work. There's loads of prefixes to remember, subtle differences in the prefix syntax, and a lot of repetition. Luckily there are Sass frameworks and libraries that keep up with the changes browsers are making. Sass libraries are collections of mixins that you can use in your stylesheets. Two of the most well-known Sass libraries are Compass and Bourbon.

Adding Bourbon to a Project

You can install Bourbon as a Ruby gem with a few commands, but if you’re using CodeKit it’s already included. It's easiest to add Bourbon to a project in CodeKit; all you need to do is import it:

@import "bourbon";

I usually include Bourbon above my partials in my main Sass file:

@import "bourbon";
@import "mixins.scss";
@import "variables.scss";
@import "reset.scss";
@import "fonts.scss";
@import "base.scss";
@import "header.scss";
@import "illustration.scss";
@import "layout.scss";

When Bourbon is imported, you can make use of all the mixins found in the Bourbon Docs, such as CSS transitions:

a {
  background-color: #ff3000;
  @include transition (background-color 1.0s ease);

  &a:hover {
    background-color: #ff9500;
  }
}

Which compiles to:

a {
  background-color: #ff3000;
  -webkit-transition: background-color 1s ease;
  -moz-transition: background-color 1s ease;
  -ms-transition: background-color 1s ease;
  -o-transition: background-color 1s ease;
  transition: background-color 1s ease;
}

a:hover {
  background-color: #ff9500;
}

Start Small, But Start!

Sass is very powerful, and there are new features being added frequently. But it's very easy to start small and get used to how it works, before exploring more complex functions and features. I recommend that you start by adding color variables (Part 1) or nesting your media queries to make your styles easier to read (Part 2). Soon you'll be writing your own mixins like a pro.

By the end of this year, there will be almost three billion people using the Internet, with two-thirds of them in developing countries. It’s time for us to look outside ourselves and our borders, because we really are writing for the worldwide web.

So if we’re writing in English, how do we prepare our content for international readers? How can we make sure our friends and neighbors from around the world can read our work? We can start by honing our language and sentences so they’re easy to translate. Then we can focus on the localization process itself and refine our content to suit different audiences.

Case Study: The Internet Archive

Let’s work through these concepts with a proper example: The Internet Archive, a nonprofit digital library. Their mission is to provide universal access to all knowledge — to archive everything on the Internet and everything that should be on the Internet. Founded in 1996, the Archive provides free and open access to a huge collection of websites, videos, audio files, books and texts, educational resources, and software (including old Atari games, if you're interested). They also have a wide variety of content in other languages like French, German, Spanish, Chinese, and Arabic.

Between their universal mission and their multilingual content, the Archive is a good example of a site that should be written for global readers. But they’re a nonprofit with limited resources, so how might they go about that?

Set the Stage for Translation

Michael Shubert, a certified translator, says:

The single best thing your business can do to make the translation process smooth and successful is to lovingly craft and refine your text before sending it out for translation.

If your content is clear, brief and accessible, you’re already doing most of the work of preparing it for translation. But we all forget to use plain English from time to time, so let’s examine a few changes the Archive could make to prepare their content for international readers.

Use Short, Complete Sentences

Pay attention to the structure and length of your sentences. Are they all the same length? Is anything longer than it needs to be?

These rules of thumb may help you keep your sentences short and sweet:

• Aim for about 20 words or less. If you find your sentences going over that, read them aloud to keep them as brief as possible.
• Adverbs and adjectives are optional, and best used sparingly.
• Try to find the simplest way to express each idea.

Consider this example from the Archive:

Thank you for your interest in the Internet Archive. We would love to host your digital artifacts. In order to access this page, you will need to [log in] to our website. (https://archive.org/create/)

To make this more suitable for a global audience, the Archive could cut the unnecessary words and repetition, and focus on what the reader needs:

Thanks for your interest in the Internet Archive. To upload a digital artifact, please [log in] or [create an account].

Check the Basics

Once your sentences are appropriately concise, make sure everything makes sense and reads well in English. Each sentence should have a subject, a verb and appropriate punctuation.

Also, be sure to proofread your copy before you send to your translator. Spelling and grammar mistakes may cost you extra time and money.

Avoid Idioms, Colloquialisms & Regional Metaphors

Different people have different ways of seeing the world. Don’t assume lingo or pop culture references will work for everyone. For example, 311 and 911 make sense for Americans, but most countries use their own system for emergency services, so any reference to those numbers may be lost on international readers.

Whenever possible, choose common words to say what you mean. Avoid jargon, fancy phrases and Latin abbreviations. The Archive does a nice job of using plain language on their donation page.

Be Careful with Icons & Colors

Along with jargon and regional phrases, be careful with symbols and imagery. For example, you may need to localize mailbox, magnifying glass or shopping cart icons, because those visual metaphors don’t always translate. This is also true for photography.

Color can also make a difference. For example, red means life in some places, and death or danger in others.

Be Consistent with Spelling & Capitalization

It’s also important to use the same spelling and capitalization as you write. This not only makes it easier for your readers to follow along, but also minimizes translation costs because your linguist can reuse the phrasing in their software. As a quick example, the Archive uses American English, so they should avoid British counterparts like colour, behaviour, and neighbour.

A simple style guide can help you standardize spelling and terminology. And if you have voice and tone guidelines, share those with your translation team so they understand your brand guidelines and higher level goals for the content.

Make a List of Common Words

If you have unique product or feature names, list those out for your translation team so they’re reflected correctly. You may also want to include specifics about the meaning of each phrase or even associations you want to avoid. As a minor example, the Archive has several names for videos including movies, moving images and films. While I personally appreciate the language choices there, having multiple terms for the same thing can cause confusion and cost you money.

Keep in mind that some names won’t translate well, so be ready to talk with your linguist and your marketing team about alternatives.

Format Numbers Correctly

Numbers are a small detail that make a big difference for your readers. Whether you’re writing about an event or sharing contact information, you can show how much you care by using the appropriate formatting and spelling for:

• Names
• Dates (e.g., MM/DD/YYYY, DD/MM/YYYY)
• Times and timezones
• Phone numbers
• Prices and currencies (e.g., USD vs. AUD)

These details are especially important for retail sites and corporate contact pages.

Make Sure It Fits

English phrases are often shorter than their global counterparts, so you should avoid truncating your text as much as possible. If your design template has character limits for descriptions, titles or navigational elements, keep those length limits in mind. This is especially important for mobile readers.

It may be tempting to chop long descriptions off to a specific character or word count, but that creates confusion for readers in any language. For example, the main modules on the Archive's homepage (Web, Video, Live Music, Audio and Texts) highlight a curator’s choice piece and a recent review:

The description text is interrupted halfway, leaving the content behind that click up to the reader’s imagination. While the description on the left is clear and easy to read, it doesn’t match the formatting of the description on the right. And the one in the middle is in Arabic, so it’s lost on an English reader like me.

This is a great example of a design opportunity: the Archive could make minor adjustments to their description modules to accommodate longer text. If you’re facing a similar challenge, work with your design team to make your content fit within your templates in a logical way, both before and after translation. As a general note, if something is hard to follow before translation, it will only be more confusing after.

Don’t Bury Important Information

When you’re designing your site, make sure your navigation supports your global readers. Too many sites hide their localized content in a PDF or bury it behind several clicks. But Wikipedia does a great job of featuring language links on the homepage and their sidebars. Give your global audiences the same level of attention and respect that you give your primary audience.

Build a Global Practice

After you've done the foundational work of cleaning up your content, you’re almost ready to translate it. But translation may not be what you need. Localization and translation are often used interchangeably, but they’re different processes and yield different results.

Web translations, like the output from Google Translate, are typically word-for-word text replacements. By contrast, a professional translator will take your content, analyze it and revise it to fit a particular market. Localization (or L10n) requires time and consideration from someone who understands the implications of your writing and the cultural needs of a particular place. Take some time to learn about the differences between translation and localization to decide what’s right for your project.

Find a Localization Specialist

When you're ready to localize your content, do your research. Unions and translation associations like the American Translators Association often publish a directory of licensed translators and linguists. oDesk also has a community of freelance translators available for hire. Since the Internet Archive is based in San Francisco, they could find a translator through one of these services or the Northern California Translators Association.

Look for a translator that's familiar with the types of content you write. You wouldn’t want to hire a fiction translator to revise your terms of service. Most linguists specify which content types and subjects they’re familiar with, like legal documents, marketing, software, and patents. And much like hiring a lawyer or designer, you may find it useful to ask people you know for referrals.

Plan Your Budget & Workflow

Along with finding a localization specialist, you’ll need a budget for paying them (unless you find volunteers) and system for managing your files. For smaller projects, it may be as simple as emailing HTML back and forth to each other and then mailing a check.

For hefty sites, you may want to plan out different phases and use a localization platform to keep everything in order. Check into Smartling and Shuttle to see if they’re worth your time.

Make Time for Translations

When you’re planning a project, factor in translation time. A lot of companies put off translations until weeks or months after a launch. But this work should be part of your writing and design process:

• Keep your global readers in mind as you make design decisions.
• Coordinate with your localization specialist regularly so they have time to ask you questions.
• Factor translation time into your launch schedule.
• Don’t forget about content after the launch.

Incorporate time and resources for that work into your editorial calendar and publishing workflow.

Start with Your Largest Secondary Audience

Another part of your workflow planning is prioritizing languages. If you already have hundreds of pieces of content like the Archive, you may want to pick one secondary audience to design the process around. The Archive could start with French, Spanish, or Chinese, because those three languages are common in both their content and the city of San Francisco, where the Archive is based.

After cleaning up the English content and working to translate it into one other language, the Archive could take that same approach and introduce new languages over time.

Keep Your Localized Content Up-to-Date

Lastly, localization is an ongoing process because your content will change from time to time. When you make edits in English or add new English pages, remember to get those translated too. Check in with your localization expert periodically and consider including translation time in your editorial calendar.

Start with Your Foundation

Translation and localization are great investments for your readers. But you can start with the basics, especially if your resources are limited. As you can see from the Archive examples, there are a number of simple changes you can make to your own content to prepare it for international audiences.

Focusing on clear, concise and user-focused content will get you more than halfway to your goal. Here again is the classic editorial challenge of keeping things updated and consistent. Give yourself a solid foundation of good content. When you’re ready to invest in translations and broaden your readership, everyone will get the most from that investment.

In Part 1 of this series, I introduced you to Sass, a CSS pre-processor. I showed you how to set up a project using Codekit to compile Sass files, and got started on the basics of the Sass syntax with partials, variables, comments and errors.

In this, Part 2, I'm going to take a deeper look at variables and using maths with variable operations to achieve vertical rhythm. I'll also discuss Sass nesting syntax to make CSS easier to read and maintain.

Vertical Rhythm with Variables

The text and layout elements in my design align to a 10px base grid that I’ve set in Sketch. Ideally, I want to replicate the grid alignment in my CSS to establish a vertical rhythm that creates a consistent pattern down the page.

I can achieve this type of consistency with Sass variables, which can contain numbers, not just the text-based values detailed in Part 1. By creating a variable base unit of 10px, I can align all elements to a 10px grid:

$unit: 10px;

Then I can apply this in my paragraph selector to give all paragraphs a bottom margin of 10px:

p {
  margin-bottom: $unit;
}

Which compiles to the CSS:

p {
  margin-bottom: 10px;
}

Math Operators

To make the most of my new base $unit variable, I can use math operators to specify all sizes I may need. For example, the body text font size on Web Talk Dog Walk is 15px, which is the 10px base unit multiplied by 1.5.

The syntax includes the variable, the multiplication symbol * and the value to multiply the unit by:

font-size: $unit*1.5;

Which compiles to the CSS:

body {
  font-size: 15px;
}

Addition (+), subtraction (-), division (/) and percentage (%) operators can also be used on variables to convert units in Sass.

This base $unit variable with math operators can then be applied to a whole load of selector rules. Any rule with a measurement can take a variable, including margins, padding, font-size and line-height:

body {
  background: $grey-mid-light;
  color: $grey-dark;
  font-family: "Adelle Sans", Helvetica, Arial, sans-serif;
  font-size: $unit*1.5;
  line-height: $unit*2.5;
}

h1,
h1 a {
  color: $green-bright;
  font-size: $unit*2.4;
  line-height: $unit*3;
  margin: $unit 0 $unit*2 0;
}

…

Which compiles to the CSS:

body {
  background: #eee;
  color: #474747;
  font-family: "Adelle Sans", Helvetica, Arial, sans-serif;
  font-size: 15px;
  line-height: 25px;
}

h1,
h1 a {
  color: #97C459;
  font-size: 24px;
  line-height: 30px;
  margin: 10px 0 20px 0;
}

…

In these examples, the font-size and the line-height are being defined together. Many web developers prefer to use a unitless line-height on the body, ensuring the line-height scales proportionally to the font-sizes declared throughout the style sheet. Eric Meyer explains the benefits in his post on Unitless line-heights. I want to keep tight control over the vertical rhythm, so I'm defining both the font-size and the line-height wherever I change the font-size. When declaring line-heights with a fixed unit like px, you'll need to adjust the line-height every time you change the font-size. Otherwise there's a risk of ending up with a dispropotionately large or small line-height compared to the font-size.

Changing Many Rules Across the Stylesheet

Though my mockup used a 10px grid, text inevitably renders slightly different in browsers than in mockups:

I want to increase the font-size globally while retaining the vertical rhythm and consistency I've already established. This is where my base unit variable is magic.

By simply changing the $unit variable to 11px, every instance of $unit will be updated across the Sass files. Where math operators are used, it will be compiled again using 11px as the variable unit:

$unit: 11px;

When the Sass is recompiled, we get:

body {
  background: #eee;
  color: #474747;
  font-family: "Adelle Sans", Helvetica, Arial, sans-serif;
  font-size: 16.5px;
  line-height: 27.5px;
}

h1,
h1 a {
  color: #97C459;
  font-size: 26.4px;
  line-height: 33px;
  margin: 11px 0 22px 0;
}

…

With just a single variable change, everything updates and scales together, not just the font-size. This keeps the relative proportions of the design intact.

Nesting Syntax

Sass offers a number of ways to keep your CSS organized, including nesting. Web Talk Dog Walk's navigation:

With ordinary CSS, the rules for this navigation might look something like this, with the rules in order of specificity:

.site-navigation {
  …
}

.site-navigation ul {
  …
}

.site-navigation ul li {
  …
}

.site-navigation ul li a {
  …
}

You might indent your CSS to make it easier to understand the parent-child hierarchy at a glance:

.site-navigation {
  …
}

  .site-navigation ul {
    …
  }

    .site-navigation ul li {
      …
    }

      .site-navigation ul li a {
        …
      }

But Sass takes this even further. Rules can be nested inside the parent selector. This means the .site-navigation class doesn't have to be repeated for every selector:

.site-navigation {
  …

  ul {
    …
    
    li {
      …

      a {
        …
      }
    }
  }
}

Sass knows .site-navigation is the parent because the ul rule is nested inside .site-navigation's curly brackets. It’s much easier to read, less repetitive and outputs exactly the same CSS:

.site-navigation {
  …
}
.site-navigation ul {
  …
}
.site-navigation ul li {
  …
}
.site-navigation ul li a {
  …
}

The CSS output from the Sass in this example makes the Sass easier to read, but has exactly the same results as the ordinary CSS. It unnecessarily repeats the <ul> and <li> selectors, even though it's unlikely there'll be different <ul>s and <li>s in the site navigation that requires different rules. This results in overly specific descendent selectors that can be harder to override with more CSS in the future. When nesting selectors in this way, try to avoid unnecessarily nesting selectors. The ideal Sass and CSS for this example would look something like:

.site-navigation {
…
  ul {
    …
  }
  li {
    …
  }
  a {
    …
  }
}

Which would result in the CSS:

.site-navigation {
  …
}
.site-navigation ul {
  …
}
.site-navigation li {
  …
}
.site-navigation a {
  …
}

Nesting with Parent Selectors

For this navigation, I want the selected link to stand out from the other links, to help the user understand where they are on the site:

Fortunately, the nesting syntax allows you to specify a combined selector within the hierarchy by prefixing the nested selector with an ampersand (&). The ampersand represents the nested rule's immediate parent, so this nested rule generates a selector combined with its parent rule rather than descending from it.

On Web Talk Dog Walk, the .selected class is added to the li element. So in the Sass, the &.selected rule is nested inside the li selector:

.site-navigation {
  …

  ul {
    …

    li {
      …

      &.selected {
        a {
          background: $green-dark;
          color: $grey-light;
        }
      }

      a {
        …
      }
    }
  }
}

Which compiles to:

.site-navigation {
  …
}

.site-navigation ul {
  …
}

.site-navigation li {
  …
}

.site-navigation li.selected a {
  background: #3F5526;
  color: #f9f9f9;
}

.site-navigation li a {
  …
}

Nesting with Pseudo Selectors

You can also use & to include pseudo classes and elements in nested Sass:

• &:hover
• &:active
• &:focus
• &:before
• &:after

I used this approach for the hover and active states of the Web Talk Dog Walk navigation:

a {
  …

  &:hover, &:active {
    background: $green-bright;
    color: $green-dark;
  }
}

Which compiles to the CSS:

a {
  …
}

a:hover, a:active {
  background: #97C459;
  color: #3F5526;
}

Nesting and Media Queries

In a narrow viewport, Web Talk Dog Walk's “Brighton” header text and navigation sit neatly one above the other. But when the viewport is about 530px wide, the navigation doesn't line up with the “Brighton” header text:

Media queries can change the layout depending on the width of the viewport, and Sass nesting makes writing (and reading) media queries so much easier than traditional CSS. In ordinary CSS, the media query would need to go after the base styling with a new rule for the modified styling, repeating the entire selector:

.site-header h2 {
  margin: 0 11px;
}

@media only screen and (min-width: 530px) {
  .site-header h2 {
    margin-top: 16.5px;
  }
}

With Sass media query nesting, the media query can be nested inside the selector without duplicating the entire rule, simply adding the new property and value (once again using our $unit variable):

.site-header {
  h2 {
    margin: 0 $unit;

    @media only screen and (min-width: 530px) {
      margin-top: $unit*1.5;
    }
  }
}

This compiles to:

.site-header h2 {
  margin: 0 11px;
}

@media only screen and (min-width: 530px) {
  .site-header h2 {
    margin-top: 16.5px;
  }
}

Sass writes out the repetative CSS we've avoided in our source file. Nesting media queries makes it much easier to make little breakpoint tweaks to different selectors. It can be less repetitive and takes up less room, too, making it far more readable.

Coming in Part 3!

In Part 3, we're going to look at mixins, including using variables in mixins. To become power users of Sass, we'll understand the difference between mixins and placeholders, and how to use other people's frameworks to import useful mixins that make our development faster.

@media only screen and (min-width: $unit*53) {
  …
}

@media only screen and (min-width: 583px) {
  …
}

Sass is a CSS pre-processor. When you write in the Sass language, you use a compiler to convert your Sass files – usually written in the .scss file format – into CSS. Sass adds handy functions, variables and other script-like helpers that make CSS quicker to write and easier to maintain.

At first, I avoided Sass because it seemed to be aimed at programmers (the documentation was full of programming terminology). But after taking the time to learn Sass, I found it isn't all that complicated. There are fancy operations and functions that will satisfy the programmers, but there are also loads of cool things that just make writing CSS quicker and more efficient for the rest of us.

The other reason I didn’t want to try Sass was the command line. I can never remember the right thing to type, and I’m terrified I’m going to accidentally type some “command of death” that wipes my computer out. Sass works using the command line, and it needs Ruby installed before it can do anything. But we don't need to know anything about the command line, installing Ruby, or Ruby itself, to use Sass. Fortunately, there are GUI tools with easy-to-understand visual interfaces that make it easier to write Sass.

In this three-part series, I'm going to give you an introduction to Sass based on the process I followed when building the the Web Talk Dog Walk site using Sass.

Setting Up a Sass Project With Codekit

CodeKit is my preferred GUI tool for writing Sass and I will use it in my examples below. It compiles Sass files and is only available for Mac OSX. CodeKit is free to try, but costs around $30 to buy. If you’re a Windows user, Prepros and Mixture are both similar to CodeKit in function and price, and Koala is a free, cross-platform alternative.

Adding a Project

In order for CodeKit to compile the Sass correctly for the project, you need to add the project folder to CodeKit. When you do this, you can see all the files from our project listed in CodeKit.

You don't need the HTML compiled by CodeKit, so you should hide those files. This makes it easier to see the Sass and CSS files when they're created.

Creating a Sass Folder

Next, create a folder to contain the Sass files. When the Sass files are compiled, CodeKit will create a folder called /css alongside the /sass folder which contains the compiled CSS.

Creating a Sass File

Once your project and folders are setup, you are ready to write Sass. First, create an empty file in the /sass folder and call it style.scss.

You can even change the extension of a .css file to .scss, and it would be valid Sass that CodeKit can compile. This is handy if you want to take advantage of a few Sass features in an existing CSS file.

Writing and Compiling Sass in CodeKit

The first thing I recommend adding to the newly-created style.scss file is the CSS reset:

html, body, div, span, applet, object, iframe,h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code,del, dfn, em, font, img, ins, kbd, q, s, samp,small, strike, strong, sub, sup, tt, var,b, u, i, center,dl, dt, dd, ol, ul, li,fieldset, form, label, legend,table, caption, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, figcaption, figure, footer, header, hgroup, menu, nav, section, summary, time, mark, audio, video, svg, hr {margin: 0;padding: 0;border: 0;font-size: 100%; font: inherit; vertical-align: baseline; font-weight: normal;} …

The reset is ordinary CSS, but that doesn't matter because a .scss file can understand both Sass and CSS, and CodeKit compiles them together. When you save style.scss, it will display in CodeKit's list of files:

Next, you can confirm that CodeKit is compiling as expected. Select the style.scss file from the list to see the path where CodeKit will compile the style.css file. Then, select “Compile” to compile the .scss file to .css:

You should now see a new /css folder in the CodeKit project your compiled CSS:

html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, figcaption, figure, footer, header, hgroup, menu, nav, section, summary, time, mark, audio, video, svg, hr {
  margin: 0;
  padding: 0;
  border: 0;
  font-size: 100%;
  font: inherit;
  vertical-align: baseline;
  font-weight: normal; 
}
…

A nice feature of CodeKit is once a file has been compiled the first time, you only need to save your .scss file to automatically compile CSS. This is because CodeKit is now “watching” your file.

Also, if you would prefer that your compiled CSS is minified, select “Compressed” from the “Output Style” menu:

Lastly, keep in mind that only the final, compiled CSS files need to be uploaded to the server. And these are referenced just like any other CSS file in the head of the HTML:

<link rel="stylesheet" href="css/style.css">

Partials

Now that you know the basics for setting up a project and Sass files in CodeKit, let's focus on some of the specific benefits Sass offers, starting with file organization. Sometimes CSS can become messy and difficult to read, like the CSS reset styles above. It is far easier to maintain when the CSS can be organized in separate files.

Sass partials let you tidy your CSS into different files without having any impact on loading. With standard CSS, you can split your styles into multiple files, and link to each of them from your HTML page, or via @import in another CSS file. However every time you request a file from another location, you're creating another server request. Many server requests can make a page load very slowly, even if the files themselves are very small.

Partials are separate files containing chunks of CSS and/or Sass. These partials are referenced in a primary Sass file with the @import directive:

@import "partial";
@import "another-partial";
@import "partial-name";

When that primary file is compiled, all the CSS and Sass in the partials are compiled as well. The compiler pulls all of your styles into a single CSS file for the browser to download.

Organizing Partials

Organize your partials in a way that suits your development process. I like to follow a modular structure like SMACSS

• Base HTML selectors (base.scss)
• Layout styles (layout.scss)
• Separate out any dependencies, such as reset styles or web fonts, into their own partials (e.g. reset.scss)

I include these partials in my primary style.scss file using @import syntax

@import "reset.scss";
@import "base.scss";
@import "layout.scss";

In CodeKit, you can see the partials in the same folder as style.scss. However, the partials are greyed out because they’re not compiled directly, they’re included as part of the style.scss file:

Also, in the /css folder, you can see that CodeKit hasn’t created any new CSS files for the partials because everything was compiled in the single style.css file:

Variables

Variables are the simplest and most instantly useful part of Sass. I use variables for repeating global values such as colors and fonts. A variable is defined with a name prefixed with a $, followed by a value:

$grey-light: #f9f9f9;

In my mockup for Web Talk Dog Walk, I have a palette of all the colors in the design:

To define all of these colors in my Sass, I created a new partial, variables.scss, which contains my color variables:

$white: #fff;

$grey-light: #f9f9f9;
$grey-mid-light: #eee;
$grey-mid: #ccc;
$grey-darker: #474747;

$green-dark: #3F5526;
$green-mid-dark: #44632B;
$green-mid: #637A3D;
$green-mid-light: #759845;
$green-bright: #97C459;
$green-light: #C0D0AA;

These variables could have any name you want, but I try to give them sensible names so they’re easy to remember. I also tend to group them by color and order them by shade, so it’s easy to see which is the next lightest and the next darkest.

The variables can be applied to different elements in the base.scss file. The variable goes where the hex value would usually be:

body {
  background: $grey-mid-light;
  color: $grey-darker;
}

h1,
h1 a {
  color: $green-bright;
}

h2 {
  color: $green-dark;
}

…

When the Sass file is saved and compiled by CodeKit, the CSS output is:

body {
  background: #eee;
  color: #474747;
}

h1,
h1 a {
  color: #97C459;
}

h2 {
  color: #777;
}

…

Variables can be used in this way throughout the stylesheets, and if I suddenly decide that one of my greens isn’t quite dark enough, I can just change the hex value of the variable, and that change will be applied throughout the style sheet.

Comments

Comments are an important part of writing CSS whether you're leaving notes for your team or just for your future self. They can be used as flags or headings to organize the stylesheet or to explain complicated CSS.

There are two types of comments you can use in Sass. Using the CSS /* comment */ syntax at either end of the comment means the comment will show in the compiled CSS.

With Sass, using the // syntax at the beginning of a line will mark the whole line as a comment, but the // comment will not show in your compiled CSS.

/* This comment will be compiled to the final CSS */
// This comment won't be compiled to the final CSS

For Web Talk Dog Walk, I commented the description of my Sass color variables with the // syntax because the variables won't show in the compiled CSS, so the comment would be irrelevant:

// Color variables

$white: #fff;

$grey-light: #f9f9f9;
$grey-mid-light: #eee;
$grey-mid: #ccc;
$grey-darker: #474747;

Errors in CodeKit

If there's an error in your Sass or CSS, the Sass won't compile. Fortunately, CodeKit has an error feature that takes focus from your Sass file and directs you to the error listed in the project's Log:

In this example, CodeKit is telling me that I haven't defined the variable $grey-dark. To fix the error, I simply add $grey-dark to my color variables and save again:

// Color variables

$white: #fff;

$grey-light: #f9f9f9;
$grey-mid-light: #eee;
$grey-mid: #ccc;
$grey-dark: #777;
$grey-darker: #474747;

Coming in Part 2!

In Part 2, I'll dive further into Sass variables, focusing on using math with variable operations to achieve vertical rhythm. I'll also introduce Sass's nesting syntax to make it easier to read and maintain, especially with media queries. Stay tuned!

h2 {
  color: saturate($green-dark, 100%);
}

h2 {
  color: #5F8516;
}

Putting it off doesn't make it go away. Getting it done does.

— Ned Hallowell, Driven to Distraction

You get out of the meeting with your client, full of ideas and energy about what you're going to do next. You commit to a deadline for ideas, a proposal, designs — some kind of deliverable to move the project forward. In your mind, at that moment, it's all crystal clear and you can't wait to work on it.

But as the date looms closer, something changes. You want it to be amazing, fantastic, flawless. Even though your vision is clear and your ideas solid, you keep delaying the start of the process. The excitement that you initially felt begins to feel like dread. “I have to do more research, gather more information, find more sources of inspiration before I start so it can be really good. I'll get started tomorrow — I've got time,” you tell yourself.

Finally, it's the day before the due date. You're now kicking yourself for putting it off and your sense of self flags along with your motivation to act. And then it's the due date. You're now not only beating yourself up for potentially messing up a big opportunity, but also panicking and stressing to pull it together by the end of the day.

I'd like to introduce you the twins that just wreaked havoc upon your nerves and your work: perfectionism and procrastination.

Perfection Is Good?

Everyone knows that procrastination is bad. But perfectionism is fine, right? Wrong. Both are fraught with difficulty, and they tend to appear together, forming an infinite loop that can destroy your productivity and your psyche.

Of the two, perfectionism seems to be more subtle and difficult to identify. How do you determine whether you are of the perfectionism persuasion?

• Perfectionists tend to focus on product to the exclusion of the process, and those results better be successful.
• Despite often being high achievers, perfectionists' feelings of satisfaction about achievement are temporary because they believe there is always more to do, be and accomplish.
• Perfectionists are their own harshest critics, frequently berating themselves over any small things that went wrong.
• Perfectionists tend to do things in fits and spurts, starting off gangbusters, only to collapse in exhaustion.

This unreasonable striving for perfection stems from attempts to preserve a sense of self-worth that hinges on the expectations of others. It is often referred to as "the highest form of self-abuse" because perfection simply doesn't exist. More importantly, perfection is rarely necessary in day-to-day working and living (unless you are a brain surgeon).

The most pernicious reality of being a perfectionist is that perfectionists procrastinate.

The Procrastination Hangover

Procrastination is often a symptom of perfectionism. Because perfectionists fear being unable to complete a task perfectly, they put it off as long as possible. This stems from the fear that not meeting the goal means that there is something bad, wrong or unworthy inside of them. Further, perfectionists fear that failure will invoke criticism or ridicule either from internal voices or external authorities and peers. The higher the fear of failure and ridicule, the more perfectionists procrastinate.

To clarify, procrastination is not laziness. It's more a misguided sense of activity based on a low tolerance for frustration and failure. When people perceive a higher challenge than they feel capable of, they sidestep the discomfort through diversion. Studies reveal a cognitive aspect as well: people procrastinate when they view concrete tasks in abstract terms. For example, when you delay completing a task that seems like it will take a really long time, only to realize that it took less time to do it than to think about it repeatedly.

Procrastination is easy to spot: Are you doing what you want to be doing or are supposed to be doing, or are you surfing the web/reading Facebook posts/filing papers/doing laundry/running errands? If you answered yes to the latter, then you are procrastinating. While it is amusing to figure out what form of procrastination you're engaged in, it's more important to determine the cause of your procrastination.

There are several common causes of procrastination, including:

• Complicated task anxiety
• Fear of imperfection
• Lack of self-confidence
• Priority confusion
• Lack of focus
• Indecision
• Boredom from minutiae

This can be further simplified to three reasons why people procrastinate: either they don't know what to do, they don't know how to do it, or they don't enjoy doing it.

Why Break the Loop?

Despite the negative repercussions of perfectionism and procrastination, it is a cycle people return to simply because it is what they know. But it is critical to break the loop. For one, you waste valuable time beating yourself up mentally by putting off tasks that you signed yourself up to do. And by "valuable time," I mean it in the grandest sense that you have a finite amount of time on the planet. Do you really want to look at all your friends' Facebook posts instead of writing the proposal for a potential new client?

Another reason to break the loop is that perfectionism (and the procrastination that results from it) is the enemy of creativity, productivity and sanity. Because perfectionists are so concerned with the outcome being just right, they are victims of risk-averse thinking, which inhibits innovation and creativity. Ironically, successful perfectionist-procrastinators are actually successful in spite of their behaviors, not because of them.

Finally, both perfectionism and procrastination have longer-term tolls on both mental and physical health. The dysfunctional thinking of perfectionism can be toxic, often leading to discouragement, self-doubt and mental exhaustion. Procrastination is equally damaging. Not only do procrastinators squander their precious resources of time, attention and focus, but the constant stress caused by procrastination eventually leads to problems like compromised immunity, digestive problems and insomnia.

I Want a New Drug

Because perfectionism and procrastination are products of fears gone wild in the brain, methods to break the infinite loop are bait-and-switch tactics that distract the brain from the fears long enough to focus on what needs to be done. The thinking that promotes procrastination exaggerates the scale of tasks involved, and these tricks work to shrink them back down to normal size. When you make efforts to break the cycle, you'll be shocked at how much easier the tasks are and how little time tasks actually take compared to your looming mental image of them.

Shift Perceptions

Here are some tips to beat perfectionism-based procrastination that stems from fears about how you will be judged or perceived by others:

• Get in touch with the value of what you're doing. When you find yourself back on Facebook (again) instead of doing something that will move you forward, take a moment to think about how the tasks ahead fit in the grand scheme of your life. The more meaningful the task is in terms of forward movement, the less likely you will be to procrastinate.
• Be aware of unrealistic expectations, and break your brain out of black-and-white thinking about expectations. Consider the Best/Worst/Real exercise: whatever tasks you feel compelled to do perfectly (and thus are procrastinating on), write down what you believe could be the Best Case Scenario, the Worst Case Scenario, and what is most likely the Realistic Scenario, which will be neutral.
• Remember that no one else cares and no one else matters. Most people are so wrapped up with themselves that they won't notice any "slip" on your part. Let your desire to impress others go, and decouple your performance from your sense of self-worth.
• Understand the difference between excellence and perfection. Excellence stems from enjoying and learning from an experience, and developing confidence from it. In stark contrast, perfection fosters negative feelings from any perceived mistakes made, regardless of the excellence of performance.

Go for Good Enough

When your fears center on whether what you produce will be “good enough,” here are some tips to entice your brain into thinking differently:

• Don't wait for conditions to be perfect to get started. Trust that you have everything that you need to get going on the task, and that you will discover any additional resources that you need once you get started.
• Accept that it will never be perfect by “satisficing.” When you satisfice, you aim for satisfactorily sufficient results and nothing more. This is especially useful if you, your team or your company struggles with the “it has to be perfect before we launch” attitude. Keep in mind that you have to start somewhere. Many ridiculously successful ventures have had humble beginnings, and your project is no different. Keep the directive of Make. Do. in mind. You can always iterate upon your creation later, but get it out the door — don't wait until it's flawless. By then, it may be too late.
• Geek out by applying Design Thinking principles to your compulsion for perfection. With design thinking, the process is as important as the product. Instead of focusing on (and fearing "failure" around) the outcome, focus instead on the five steps of design thinking: discovery, interpretation, ideation, experimentation/testing and evolution/iteration.

Doing any or all of the above will start to help you break perfectionistic tendencies, but these next suggestions will more directly dismantle the foundations of procrastination.

Analyze your Anxiety

To get to the source of your resistance to getting to the task, you may need to do some analysis. Consider two exercises that can help:

• Action-anxiety rubric:
  Take a sheet of paper and draw a line down the middle. In the first column, list the tasks that you are blocked on and are putting off. In the second column, write down the anxiety, concerns, worries or fears you have about doing that task. Start anywhere and write down as much as you can.
• Task/steps > Anticipated Problems:
  Another version of this is to list the task and the steps involved with each task, and the problems you anticipate encountering when executing the task or step.

Eliminate Distractions

Pruning away the unnecessary can mitigate the overwhelming thoughts and feelings that lead to procrastination:

• Clear your space of distractions, and delegate, drop and delete anything that doesn't contribute to your goals.
• Sequester yourself. Gather only what you need to work on the task, take yourself out of your normal work environment and go to a conference room, another office, the library, a co-working space, a friend's house — anywhere where you will not be distracted by your normal routine and people that you know.
• Firewall technology. Use one of the great apps or browser extensions that block you from the lure of distracting websites. Turn off your phone's ringer or put it in airplane mode to block out all notifications.

Trick Your Mind

If you're procrastinating because of fears of failure, you can use action to cure fear with some of these action-based mind tricks:

• Pretend you're not going to do it by “getting ready” to do it. Instead of writing the proposal, just get ready to write it by jotting down a few ideas. While you're at it, you might go ahead and get ready for writing it by doing a relevant web search for supporting information. And so on. Eventually, the line will blur between the getting ready for doing it, and actually doing it.
• Practice structured procrastination: put the most important thing at the top of the list and other important things that need to get done under it. Even if you don't do the top thing and go to the others, you're still getting important items done.
• Another version of structured procrastination can be to leverage the power of what I like to call “white space creativity”. Good ideas often come when engaging in mindless activities like washing the dishes, gardening and organizing. The trick is to use these activities as tools for generating ideas, not as ways to escape tasks.

Put Time on Your Side

One major contributor to procrastination is uncertainty: having a hazy sense of how long the task will take usually makes it seem larger and more involved than it turns out to be. Establishing a better sense of time can help thwart procrastination.

The first step is to take the seemingly insurmountable task and break it into smaller pieces or steps. The next step is determine the time of the task yourself by assigning it a set time or giving yourself a quota:

• Give yourself five minutes or ten minutes of focus. You can shoulder through anything for 5-10 minutes, right? Devoting even a small amount of focus will break the siren call of pushing it off and get you on track to completing the task.
• Employ the pomodoro technique or Merlin Mann's (10+2)*5 . Both employ having a set amount of time with one segment being a “sprint” and the other a rest. Pomodoro uses 30m with 25m for the sprint, and 5m for the break. (10+2)*5 is 10m sprint, a 2m break done 5 times to equal an hour.
• Fill a quota by running dashes. Here, you can build in your own breaks, but the important part is determine your quota and stick to it. Maybe it's responding to 10 emails, or doing a 15m sprint, or working until a certain time. Determine your quota, stick with it, and reward yourself at the end.
• A single day for a single task: schedule doing the task, and only that task, for a certain day. Put it on your calendar. Pro tip: combine this with sequestering yourself (above).

Ready, set, GO!

Once you recognize a problem, you can start to solve it. While perfectionism and procrastination may have plagued you in the past, you now have the tools to create a new future — not tomorrow, but today.