How to Never Worry About Email Templating Again

Email Template Source Code

At POP, we’re always on the hunt for cleaner solutions to existing problems. Part of our recent website redesign efforts included new email messaging and design. As a seasoned developer, I’ve experienced the hell that is email templating dozens of times over. The overarching problem is the fragmentation of how each mobile, web, and desktop email client display email. They each have their own quirks as to what HTML tags are allowable, which CSS style tags are allowable, and how you need to go about structuring the HTML for viewing. At POP, we set out to address these quirks and other common pitfalls in email design. Read on to learn how you can do the same!

A Battleground of Clients

When you style an email, you need to make sure it displays correctly in all major clients that account for the largest possible percentage of your user base. This means you need to focus on not only web clients such as GMail, Yahoo, and Outlook, but also desktop and mobile clients such as Thunderbird, Apple’s Mail, and Android’s Email. At first glance, there appears to be little interoperability between the development teams of all of the mail clients. In contrast to modern web development, creating email templates is more like frontend development on an IE6 compatible website. Because of this fragmentation, you’re best to stick with a framework if you’re in the market of writing your own templates from scratch. An email framework will give you not only a productivity boost and scaffolding for your project, but also help you avoid common pitfalls that occur when starting with nothing. There are a few common frameworks and bootstraps out there which I can recommend.

  • Zurb’s Ink – Quickly create responsive HTML emails that work on any device & client. Even Outlook. Includes a responsive, 12-column grid and sample templates.
  • HTML Email Boilerplate – This website and its sample code creates a template of sorts, absent of design or layout, that will help you avoid some of the major rendering problems with the most common email clients out there — Gmail, Outlook, Yahoo Mail.
  • Emailology Email Boilerplate – A template void of design and loaded with code samples for developing HTML emails
  • BootstrapForEmail – It is what it says. Uses Bootstrap 3 LESS under the hood and compiles to inline header styles on view. The resulting HTML is suitable to run through an inline CSS tool
  • ModernMail – Grunt-based email-writing system. LESS, Bootstrap, Grunt, Zip archives.
  • Antwort – Responsive layouts for email.

For POP, we chose to go with Zurb’s Ink. The main selling point for us was a responsive grid system and accompanying documentation. Ink is lacking in a few key places, however. This is one of the primary reasons we set out to launch our own system for building and iterating on email templates fast.

The POP Way

What many email systems are lacking that we added support for was the concept of layouts. You may be running several email campaigns that require a different aesthetic. We acknowledged this by adding a configuration file which specifies which layout gets assigned to which template. Our repository consists of a PHP CLI server which can be enabled by running a simple bash file from your command line. Once the server is up and running, we utilize a minimalist router to direct URIs to a preview of each email template. The global configuration file gets loaded and we use the URI of the current template to determine which parent layout to load for the template. We then dynamically compile the associated layout LESS file into a CSS string and include it in the page header. This effectively sums up our preview and design mode.

Coupled with this rapid prototyping mode which allows us to test and preview templates, we also generated a simple build script to enable one click deployments of our email templates.

Automating the Build Process

One crucial aspect of writing email templates that utilize a layout is the fact that if you update a layout, you want to ensure that all of your email templates also get updated. The process of manually updating a couple dozen email templates with inline styles sounds like a daunting task, so we decided to avoid it altogether. What truly pulls together our email templating engine is the build system. Our build system utilizes a simple PHP script. When I say simple, I mean it. This thing is only 213 lines including a scaled down Mandrill API client wrapper. Our build process consists of loading a global configuration file which contains a mapping of email templates to their perspective layouts. We search for all files contained in our templates directory and make an HTTP request for the local template page. The CLI server, which is still running, returns the HTML with inline CSS in the header. We then take the resulting HTML email template and run a filesize check against our last known template build to see if the content has changed. If the content in the template has changed, we issue an API request to Mandrill to check if the template currently exists or not. If the template exists, we issue an update. If the template does not exist, we issue the creation of the template. And that, ladies and gentlemen, is how we can quickly make changes to our email marketing campaigns on the fly. Note that we don’t need to inline our styles on the fly as Mandrill handles this cumbersome task for us.

One key piece of information we didn’t discuss is the concept of template versioning. Our configuration file references a version number of our email templates. If we were to update our email templates substantially, we’d increment our version number. This version number gets prefixed to our template names and will trigger the creation of a brand new set of email templates. Essentially, this enables us to make and test drastic changes in email templates without affecting our site’s different environments (dev, staging, production). We highly recommend trying out this approach the next time you’re tweaking your email template build system. Speaking of email template build systems, there’s one you may wish to check out.

You can just as easily automate your email template build process using grunt if you’re comfortable. In some ways, grunt may be better situated for you. To get you started, there’s a nodejs based solution, grunt-email-boilerplate, which includes all the bells and whistles. One thing I’m particularly fond of in this build script is the usage of premailer and grunt-premailer. Premailer is the defacto standard when it comes to inlining your styles from header CSS or CSS includes. It does a fantastic job and comes recommended from all of the major email delivery services.

A Final Note: Style Guides are Your Friend

There’s numerous style guides out there which you may consider perusing before you decide to blaze your own trails. These will clue you in on how you should be structuring your code as well as provide a baseline of tags and semantics that are known to be compatible across email clients. If you do a bit of reading here before plowing into an email boilerplate or framework, you’ll be more aware of what styles and tags to avoid.

Next time you get tasked with email templating, take the opportunity to look at the daunting task as an opportunity for improvement. What can you do to make sure that your workload is minimized in the future? Let us know!

Share this post on Tweet about this on TwitterShare on FacebookShare on Google+Share on TumblrShare on LinkedInShare on RedditDigg thisBuffer this page