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 6, 2014
The wrong way to build a Drupal site is to jump straight into Drupal and start building out content types. I’ve heard a lot of people praise Drupal for it’s usefulness in prototyping, and I’ve been guilty of doing this myself in the past, but this is not a good idea for many reasons.
In this first post of the series I explain why I prototype and then introduce some tools to help with prototyping. In future parts will look at the process of building a prototype in a way that supports effortless translation into a Drupal website.
I think the biggest danger of jumping straight into Drupal without a prototype is that you get locked into Drupal ways of doing things too early in the process and you’ll be naturally thinking in Drupal terms, and end up with a ‘drupaly’ solution. You miss out on other cool ideas or possible solutions that might be a bit harder to implement, but result in a much better product.
Also, if you start prototyping in Drupal, or building in Drupal straight away, then you end up bringing across elements from prototypes into your final site build. This big ball of mud grows and can become a maintenance nightmare. What you really want at the prototype stage is the freedom to throw things away. You shouldn’t feel tied to any idea, design, or solution, which will happen if you’ve invested time and effort in building it. Prototypes should be good to throw away at any point and start again.
The best way to prototype web sites is to simply build out some HTML and CSS. You can quickly mock up ideas, test it out on users, and iterate towards a final design. Lots of other developers and UX experts agree with me on this one.
There are short-cuts to building out flat HTML and CSS that, while not necessarily intended for prototyping, certainly speed up the process.
The benefits of using a framework like Twitter Bootstrap, Zurb Foundation, or Yahoo’s Pure CSS is that they give you building blocks you can use to quickly piece together a responsive website. Each of them have their own way of doing things, so you must be careful not to limit your thinking so you don’t end up implementing things a certain way just because that’s how the front-end framework does things.
Pure CSS offers a very minimal starting point so you have to do more of the work, but this will lead to more varied solutions. Twitter Bootstap is much more comprehensive, but without a lot of customisation you’re likely to end up with something that looks like it was built using Twitter Bootstrap.
I find that Zurb Foundation offers a good compromise, being a fully-featured front-end framework, but having lots of scope for customisation using SASS. There are settings variables to control lots of the default behaviour, and by using the SASS mixins you can easily use the features of Foundation with your own markup.
In the early prototype stages I tend to make more use of the pre-defined classes and styles from Zurb, replacing them with custom classes using the mixins as the prototype evolves.
When creating a prototype site in HTML you will end up repeating yourself and writing the same HTML code multiple times. Using a HTML preprocessor helps with this as you can include special tags in your HTML code which the preprocessor replaces with other HTML. This cuts down on the time taken to write the HTML in the first place, and speeds up the process of making changes to your prototype. For example, if you have a navigation bar that is common to all pages of your prototype you define it once and then just include it in every page. Your prototype is then built out of various components, which makes it easier to manage and quicker to iterate.
I’ve talked about a HTML preprocessor Middleman in a previous blog post where I discussed using one as a static site builder. Back then I came out in favour of Middleman, but since then I got turned on to Jekyll when I migrated my site to GitHub pages, and I’ve been in love ever since.
Just like a HTML preprocessor speeds up the creation of HTML for your prototype, a CSS preprocessor speeds up the creation of CSS.
There’s an excellent starting theme for Drupal called Aurora that provides a mechanism for incorporating SASS and Compass into a Drupal development workflow. But, we avoiding jumping straight into Drupal site building. From a prototyping point of view, the main reason I’m using SASS/Compass is so that I can make use of Zurb Foundation mixins.
In the next post of this series I’m going to show you how to create an all-in-one prototyping tool that will work for all stages of prototyping, from the throwaway early drafts, through later refinement stages, up to the final stages of prototype conversion to Drupal.