Front-end Process - Flat Builds and Automation, Part 1: Introduction
Matt Bailey / +Matt / June 12, 2013

terminal grunt

*Update

I recently released a Yeoman generator called generator-bones. It's a simplified version of generator-webapp and includes the two Grunt tools I talk about later on in the article - Assemble and Grunticon.


 

Due to the rising popularity of responsive web design over the past few years we have been actively adapting our design and front-end processes to tackle the unique challenges it raises. We are no longer designing full page comps in [insert design app of choice] to cover every context/screen-size, and have instead been experimenting with ways to combine design and development into a more iterative and optimised workflow.

As part of our design process we have started coding style guides or pattern libraries (Barnard Levit for example). This is a nice way of giving the client a feel for the design before the whole site is finished, and it is also a great resource for the developers working on the site. On our last couple of projects I created the style guide in the CMS itself. While this was pretty successful - our developers really liked it because effectively a lot of the front-end design integration was already done - it took a long time in the first instance to set up the CMS ‘environment’. I basically ended up doing a lot of things that it would have made more sense for a developer to do. It’s not just about optimising code, but also about ‘optimising’ the people who do the tasks - In a team it is important to recognise where an individual’s strengths lie. The other concern with the feasibility of this way of working, is that it will become harder the ‘bigger’ and more complex our projects become.

So, for these reasons I’ve started looking into coding my design assets as ‘flat’ resources, and this is where the ‘flat build’ comes in.

A flat build is basically the process of coding a static page (or pages) in HTML and CSS. The idea is to supply our developers with design assets such as style guides, pattern libraries or prototypes, including assets such as images, fonts, css, and javascript, as flat builds. A big benefit of flat builds is that they can be packaged up and viewed in any browser, anywhere, without the need for a local hosting set-up such as MAMP.

However, working with static files and assets can be time consuming, so to help speed up the process I have been looking into tools such as Grunt to automate parts of the ‘build’. For example, using the node package assemble you can build your static HTML files from templates and data - this helps to avoid repetition of common blocks, such as header, footer, nav and so on - a bit like using php includes. You could also use grunticon to automatically optimise/convert SVGs and output them to CSS in different data URI formats with fallback pngs.

An automated front-end process is reasonably complex to set up, but pays dividends in terms of an optimised workflow.

I am now going to go through how I have set up my automated front-end flat build process, and because there is quite a lot to cover I am going to split the article up as follows, with this article forming part one, the introduction:

Article Index