Warning: You are viewing old, legacy content. Kept for posterity. Information is out of date. Code samples probably don't work. My opinions have probably changed. Browse at your own risk.
Feb 7, 2014
In this series of posts I’m talking about my website prototyping processes. Starting from early throwaway draft prototypes, through to clean, efficiently coded, designs that can be easily translated into Drupal websites.
The first post in this series explained why I prototype, and introduced some useful tools for website prototyping. In this post I combine all the tools previously mentioned into one simple prototype tool.
##All you need is a hammer…
In April last year I purchased a Mac app called Hammer that promised to “Super-charge” my web development. What I got was a fairly basic HTML preprocessor with a snazzy GUI and limited support for SASS.
Hammer doesn’t work for me as it doesn’t easily support Foundation because of it’s lack of support for Compass. The developer has made a bold statement as to why they believe “Compass is not … the right approach for the web industry” and that they “think you’ll be better off without Compass”.
Their main objection to Compass seems to be that it uses RubyGems as they call that an “Outdated installation process”. That’s quite clearly misinformed rubbish, as any real developer can testify to the importance of dependency management.
Anyway, the great news is that you don’t need Hammer if you’ve got Jekyll because you’ve got a much more powerful HTML preprocessor, and you can easily add support for Compass into Jekyll so you don’t need to run the two separately.
##The Amazing All-in-one Prototyping tool!
With a bit of tweaking Jekyll can be configured to do all that Hammer does and more, using just open-source tools.
###Jekyll, Compass and Foundation
Here’s how to get Jekyll, SASS/Compass, and Foundation all running together nicely.
First, install Jekyll:
gem install jekyll
Make sure you’ve got Foundation installed, following the instructions for installing via the SASS page on the Foundation docs website. Assuming you’ve already got the prerequisites, this is essentially just:
gem install foundation
You can then create a new Foundation project with
foundation new my_prototype cd my_prototype
Jekyll will compile everything into the site unless
you specifically tell it not to. So, create a configuration file
(Jekyll expects this to be called
_config.yml) in your prototype folder
with the following content:
name: My Prototype exclude: [README.md, bower.json, config.rb, scss]
If you run Jekyll now with the serve command you can preview what you’ve done in
the browser. By default Jekyll will run a server locally at
for you to preview the
site as you’re building it. Add the
-w option and it watches the files and automatically
regenerates the site when any of the files change.
jekyll serve -w
You can also see what is generated by looking in the
You will notice that the site doesn’t have any CSS yet, because we’ve not compiled the SCSS from Foundation down to CSS. You could at this stage just run Compass to do this, but let’s add the Compass compilation step to Jekyll so that it can take care of this for us, and automatically recompile when we edit any of the source files.
This turns out to be very easy. I originally found the code to do this from this Gist, but I have adapted it to work with the file structure of a generated Foundation project.
All you need to do is create a folder called
_plugins and create a file
generator_scss.rb that contains the following code:
require 'sass' require 'pathname' require 'compass' require 'compass/exec' module Jekyll class CompassGenerator < Generator safe true def generate(site) Compass::Exec::SubCommandUI.new(%w(compile)).run! end end end
Now when you run
jekyll serve -w you should notice that it compiles the SASS
source down to CSS and includes it in the site. I had to run
jekyll serve -w twice
as Jekyll didn’t copy the stylesheets folder into the build on the first attempt because it
hadn’t been created yet. After running it the second time the site showed up
fine with all the compiled CSS and automatically refreshed when I edited any files.
In the next post of the series I’m going to jump ahead to the final stages of prototyping when designs start to get real. I’ve got some recommendations for refactoring the code from a high-def prototype (i.e. final-ish designs) that will simplify the conversion to Drupal, and result in a better end product.