Rapid prototyping with HAML, SASS and Ruby

Hey! It's me!

Rapid prototyping with HAML, SASS and Ruby

Posted on February 28th 2010

For the past few years, I’ve been doing a lot of prototyping as part of my autodidacting manner of learning. Doing so made me create a process that I have now polished and proven to work very well in most cases.

Take a good hard look at your design

… and slice it mentally. This skill is mainly acquired with experience, being able to see how a design is going to be cut out even before you do so is important to a coherent integration. A few things to focus on while designing or looking at a design:

  • Recognizing the basic semantic elements: lists, tables, headings, etc.
  • The elements' position in relation to each other. That’s just how it works with CSS positioning, most elements influence each other in terms of position: floats, absolute, float breaks, etc.
  • Stuff that doesn’t need cutting: solid color backgrounds, borders, semi-transparent backgrounds, etc.
  • CSS3 is your friend for speed: drop shadows, inner shadows (FF only), rgba, text shadows, multiple backgrounds, etc.

Use HAML and SASS, please.

You’d be surprised at how much time this can help you save. It makes your code so DRY and reusable when you get used to it (yes, there’s a small learning curve).


It has already proven to me and many other developers that coding a frontend can still be enjoyable. It completely removes the HTML hassles. Goodies include:

  • No need to close tags, the syntax is based on indentation;
  • By default it assumes you’re going to be using a <div>, because that’s just usually the case;
  • Looks much more like CSS (and SASS) so it’s much less of a dissonance to your mind;
  • Simple integration of Ruby code.



    - 3.times do
      %li Something


<div id="some_div">
   <ul class="navigation">

I’m not going to brag about the shorter length of the code or its beauty, because I don’t care. All I care about, in the end, is that code has been written in an efficient manner and it wasn’t a pain.

A note on Zen-Coding

Zen-Coding is a plugin supporting many IDEs and text editors, it enables a user to write something in the form of div#content>h1+p, then by pressing a shortcut it expands the syntax to regular HTML.

Sure, it’s much faster to code with zen-coding… the first time around. With HAML, it’s easy and fast to code the first time and then it’s maintainable in that same readable form. Much more “zen” if you ask me.

Yes, there is a Zen Coding filter for HAML. It’s not much of an advantage to me, the syntax Zen Coding uses is almost identical to HAML. The main difference: with HAML you have to press return a few times — oh noes!


I couldn’t possibly be grateful enough for this simple piece of software which makes my life (when I do frontend coding) oh so easy. A few goodies:

  • No need for curly brackets anymore;
  • By indenting your code, you’re automatically creating more specific rules, without extra typing. No need to repeat all the previous statements;
  • Variables. Need I say more?
  • Mixins are extremely useful for the DRYest possible code. Probably my favourite feature.

Ruby aids to put your mockups into prototypes very easily

So, I’ve been using the StaticMatic gem for quite a while now and I’m loving it. Simply enables you to create a static website in HAML/SASS with basic routing. There’s also Serve which is worth mentioning, but I haven’t tried it much, just check it out, looks cool.

If Ruby is your language of choice, the one you use by default, and you’re also a frontend coder, then you’ll love StaticMatic. Apart from making the routing on your site “automatic”, it has one real advantage over statically coding your site: Ruby helpers. Akin to the well-known = link_to from Rails, it comes with = link, = stylesheets, = javascripts… you can create your own too. How’s that useful in any way? If you’re used to reusing the same structures over and over or if you know you’re going to reuse those often on the same project, ie: navigation, breadcrumb, header, you can simply create a helper accepting parameters to fit your needs.

Once you’re satisfied with the result your get in your browser (by starting the preview server, on localhost:3000), then you can staticmatic build site_name to generate static HTML/CSS and you’ve got yourself a drop-in fully functional prototype. Use your favourite FTP client (or git) to deploy your satisfying integration experience onto the interwebs.

Data seeding with Ruby blocks

There’s a Ruby structure that helps a lot in putting data into your prototypes. For instance, I really don’t want to copy and paste 100 rows of a table, with the same syntax over and over. Let’s DRY it out a little:

- 100.times do |n|
  %tr{:id => "row#{n}"}
      Data 2
      Data 3

Creating your standard navigation? Use a simple hash (Ruby 1.9 to keep the right order) and iterate with it.

- {"Menu item name" => "/section/page", |
  "Menu item name" => "/section/page", |
  "Menu item name" => "/section/page", |
  "Menu item name" => "/section/page"}.each do |name, url| |
    %a{:href => url}= name

Note: the | character in HAML is to specify multiline statements, I’m only using it so the code example doesn’t need to be scrolled.

My Prototyping Workflow

  1. Code one full page with no regards to modularizing the integration any further than StaticMatic already does for you;
  2. Once a full page is coded, modularize the code just enough so that the next pages won’t require as much code. More on this in a future post;
  3. Create another page;
  4. Further modularize with the new elements in play. Using mixins and helpers == modularization;
  5. Repeat step 3 & 4 until everything is integrated;
  6. Add in the javascript for more interactions in your prototype (it’s worth it, big time);
  7. Deploy/commit your prototype.


I’ve success with this workflow and these techniques over the last year or so. I immediatly noticed an improvement in the products I was delivering, not only was it much quicker to release, HAML and SASS helped me think in a completely different way about how I could organize my code.

A lesson learned: Simplicity is more enjoyable, less mistake-prone. (“simplicity” as in: the removed, and evidently useless, complexities of HTML and CSS)