In order to rapidly build pro­to­types for new fea­tures, we’ve started using a totally new process in Emma’s UX group. Where we would nor­mally spend hours craft­ing an inter­face in a wire­frame app such as OmniGraffle, we’ve gone straight from paper to the browser.

To avoid feel­ing con­strained by the look of pix­els to begin with, we start by draw­ing ideas on graph paper. After that’s been worked out sat­is­fac­to­rily, we move on to HTML, CSS and JavaScript. We’ve found a really nice rou­tine that’s easy to pass off to the team that will go on to build the fea­ture. It’s called Frank. (Yes, Frank is actu­ally a soft­ware and not a person.)

While it’s neat to be able to throw some tem­plates together and reduce the amount of repet­i­tive HTML we use to build out click-able pro­to­types, the main time­sav­ing fea­ture of Frank is the abil­ity to use Sass (with­out rely­ing on a TextMate plu­gin or run­ning sass --watch from the com­mand line). You can also use Haml, which is terse, but the ben­e­fit of that is some­what dubi­ous IMO.

Sass is awesome

Ever wanted to put vari­ables in your CSS? Name your col­ors so you don’t have to remem­ber hex val­ues or lit­ter your HTML with un-semantic color names? Write your CSS as if you were writ­ing Python? All but that last one? That’s what I thought.

Sass is a sys­tem that com­piles fancy, indention-based syn­tax into nor­mal (ver­bose) CSS. Here’s a taste:

#container
    width: 960px
    margin: 10px auto
    a
        font-size: 20px
        color: #f00

Which would com­pile to:

#container {
    width: 960px;
    margin: 10px auto; }
    #container a {
        font-size: 20px;
        color: #f00; }

The Sass is not much less code ver­sus the CSS in this sim­ple exam­ple, but note that the inden­ta­tion auto­mat­i­cally cre­ates nested selec­tors like #container a. That makes for very spe­cific CSS that’s easy to maintain.

Now, look what else is pos­si­ble. You can define named vari­ables (tech­ni­cally con­stants) and assign color val­ues to them.

$pale_blue: #EAF5FC

Then you can use them like this:

#container
    background: $pale_blue

Taking that idea a step fur­ther, you can do things like:

#container
    background: darken($pale_blue, 20%)

Not too shabby, eh?

Now for Mixins. Once you get to the con­cept of these, you see how Sass gives you CSS super­pow­ers. Observe.

Define a Mixin like so:

@mixin rounded($radius)
    -webkit-border-radius: $radius
    -moz-border-radius: $radius
    border-radius: $radius

Then you can use it like this:

#container
    @include rounded(10px)

Bam. You just rounded the #container’s cor­ners with­out hav­ing to trip­li­cate your work by includ­ing all the browser-specific prefixes.

Here’s another incred­i­ble time-saver:

@mixin clearfix
  *display: inline-block
  &:after
    content: " "
    display: block
    height: 0
    clear: both
    visibility: hidden

No more adding non-semantic clear­ing classes in your markup, or, heaven for­bid, extra markup (you don’t really do that any­more, do you?) just to have a con­tainer clear its floated content.

#container
    @include clearfix

And if there’s ever a new tech­nique needed for a new browser, just add it to this Mixin, and it’s auto­mat­i­cally used every­where you’re call­ing it.

Here’s what all of that fanci­ness looks like together:

#container
    background: darken($pale_blue, 20%)
    @include rounded(10px)
    @include clearfix

Frank

So Frank is great because you can use Sass. Frank is also great because you can build site struc­tures with pretty URLs with­out any configuration.

A folder struc­ture like this…

/about/
    index.haml
    /mission/
        index.haml
    /people/
        index.haml

… will auto­mat­i­cally cre­ate URLs like /about/, /about/mission/ and /about/people/ as well as pars­ing out the dynamic Haml and Sass. And this is all done with­out hav­ing to con­fig­ure Apache and Virtual Hosts. You’re always just a $frank up away from brows­ing the site locally. (If you do have a need to mess with Virtual Hosts in gen­eral, check out VirtualHostX.)

Using Frank in production

We’re in good com­pany. Our friends over at MailChimp are using Frank to power their mar­ket­ing site. If you don’t have need for a CMS and all your site con­trib­u­tors are cool with edit­ing source code, I can’t think of a bet­ter way to power a web­site (with the excep­tion, maybe, of Jekyll).