A Framework for Better Emails

07 Nov 2016 A Framework for Better Emails

Creating rich email templates can be a real pain, not only having to discard many best practices when it comes to writing HTML and CSS, but also needing to ensure your email renders correctly in all the commonly used email clients, many of which will throw away or ignore large portions of your carefully crafted styling.

To ease this development process, services like MailChimp and Litmus can be a good place to start as they provide some great boilerplate and pre-made templates for free, which already have a lot of style overrides in place that will help tame even the most intractable of clients like Outlook. These services also provide handy inlining tools for compiling your CSS into inline styles.

Developing emails this way is fine for small projects or one-off jobs, but what if you need to make a lot of templates? What if you need to maintain consistent branding and styling across them all? It quickly becomes a nightmare having to copy and maintain code between all these different files – even worse when you need to go back and update or refresh the styling! ZURB provides a solution to these issues.

ZURB Foundation for Emails

You may have come across ZURB before, but if you haven’t it’s a great framework for quickly developing responsive websites. ZURB Foundation for Emails does the same thing for your email templates as ZURB or Bootstrap does for your websites – it provides a robust framework for quickly creating responsive emails that have high compatibility with all the common clients in use today.

Like Litmus and MailChimp, ZURB has a heap of pre-made templates with style rules and overrides that will take care of a lot of the major quirks you’ll find in various email clients, but they separate these styles out to an external stylesheet – and the inlining tool they provide is designed to take style and markup separately. A good start towards more reusable and maintainable code, but not far enough! The real strength of ZURB is gained from using the ZURB Stack, running on NodeJS.

Install ZURB Foundation for Emails

With NodeJS already installed on your system, getting started with Foundation is easy, simply install the CLI globally;

npm install --global foundation-cli

Navigate to your working directory and start a new email project with:

foundation new --framework emails

Once you’ve completed the installation, navigate into the newly created project directory and run:

npm run build

While the docs say to use npm start or foundation watch, I’ve found that it is better to work with npm run build as you will get the benefit of discovering any quirks that arise from inlining in real time.

Once the project has started up, your browser will open at the default template and you’re all set to start working. BrowserSync will keep the view updated every time you save your changes.

Don’t Repeat Yourself

ZURB has made this framework all about bringing the D.R.Y. principle to email development, it aims to keep your code modular, clean and reusable. You may notice, once you’ve created a new project, that ZURB created a number of directories for your code under the src/ folder.

The assets directory is self explanatory, the interesting ones are helpers, layouts, pages and partials. Layouts is where the core of your email template resides, these files contain the boilerplate HTML document structure into which all your email content will be included. All your actual email content should be defined in Pages. This will allow you to keep your email code simple, neat, and ideally separate from any styling – as you could just change the Layout for a page to switch to a completely new look, while preserving all the content and structure.

ZURB uses Panini to handle page inclusions, variable insertion and custom functions. You can include one or more pages into your layout using the Handlebars syntax {{> page_name}}, this also works for Partials.

Partials are intended to be small snippets of reusable code. Any common elements that you want to include between different emails should be created as Partials, and simply referenced in your Page using the above Handlebars syntax.

Helpers is where you can create your own helper functions in Javascript for use in your templates. Panini already has a number of helper functions built in that will handle simple conditionals, but if you need more complex logic to structure your templates, or want to create your own shortcut syntax for common elements, this is the place to define it.

Templating with Inky

Defining structure in emails can require an absolute mess of nested tables, rows and cells – and all that extra syntax (and levels of indentation) quickly makes your templates difficult to read and maintain. The Inky templating language is ZURB’s answer to that, and a neat way of abstracting out much of the messy parts of table markup.

<container>
  <row>
    <columns>Inky is awesome!</columns>
  </row>
</container>

That tidy little bit of code above is Inky’s way of expressing:

<table align="center" class="container">
  <tbody>
    <tr>
      <td> 
        <table class="row"> 
          <tbody> 
            <tr> 
              <th class="small-12 large-12 columns first last">
                <table> 
                  <tr> 
                    <th>Inky is awesome!</th> 
                    <th class="expander"></th> 
                  </tr> 
                </table> 
              </th> 
            </tr> 
          </tbody> 
        </table> 
      </td> 
    </tr> 
  </tbody> 
</table>

These containers, rows and columns make up Inky’s grid system, providing the same responsive layout capabilities as modern web frameworks do for websites. You can easily specify the sizing and behaviour of the columns in your grid using the following syntax:

<container>
  <row>
    <columns small="12" large="6">First column</columns>
    <columns small="12" large="6">Second column</columns>
  </row>
</container>

And with no more code than that, you have a two column grid layout that will become a single column layout on smaller devices!

The values used here follow the same conventions as other frameworks; there are 12 columns to a row, and each column will be sized proportionally based on how many column widths you say it should span.

Further analysis

There is quite a lot more you can do with the Inky templating language but I won’t go into it all here, the official documentation explains it all very well and has good examples. There are some things worth mentioning, though.

If you need to reference any of Inky’s custom template elements in your CSS you must use class names, and not id attributes. When the template is compiled, only a select few attributes are preserved and transferred onto the underlying table structure – class is one of them, id is discarded.

This level of abstraction can also become an obstacle when attempting to style specific elements, as the table structure generated is more complex than what you might normally create when building an email manually – as you may have noticed above, where each row is it’s own table within a table, as is each columns. Using browser inspection tools to identify the the correct element names, hierarchy and sources of inheritance is frequently a necessity. That said, once you become familiar with the way Inky compiles templates, you’ll likely find the speed at which you can create and style your emails has increased dramatically.

Another thing not mentioned specifically in the docs is ways in which to handle or structure an email project that encompasses a large number of emails. Of course, this is something that can only be decided based on your needs, or that of the company you work for. In corporate settings, it is not ideal to be creating new foundation email projects for every email that needs to be created – your repository would quickly fill with multiple duplicate directory structures, not to mention the space taken up locally by node_modules in each.

Foundation’s workflow is designed so that for every Page you have created, a corresponding compiled email will be generated in the dist folder, and any directory hierarchy in pages will be preserved. This means that each page can be treated as an individual email, and based on this you can organise your pages to suit your project accordingly. For organising styles, by default the app.scss file is the entry point for all styles that get compiled, so you will either need to import all your custom styles (directly or indirectly) into app.scss, or you will need to modify the Gulp workflow to better suit your project.

Conclusion

Personally, since I started using Foundation for Emails, I’ve never looked back. It has saved a lot of development time, the ease of maintaining and modifying emails once the templates have been created is incredible, and the quality of the emails produced has also improved. While it can introduce some complexity into how you organise your code and can also throw some hurdles at you when trying to style things that the framework doesn’t explicitly cater for, these are minor trade-offs when compared to previous workflows of maintaining duplicated code and working with many flat file emails.