Building email newsletters like it’s 2016
Email newsletters are having renaissance but are a pain to build. What if developing them was as easy as making a website?
“Email bulletins have proven to be very successful for us”
— John Witherow, editor of The Times, during a recent speech to staff
At The Times & Sunday Times, we’re investing heavily in email newsletters. Some, like our morning and afternoon news bulletins, offer a way to keep in touch with our paying subscribers and showcase our best articles from each day’s edition; others, such as our Red Box political briefing, are available to anyone for free and allow us to reach an audience beyond our subscribers.
In total we now send 30 different newsletters across both titles — some sent daily, some weekly — to 300,000 email bulletin subscribers, with plans to create niche newsletters for distinct audiences. And we know they’re popular: we see average open rates of 40 per cent, versus an industry average of 22 per cent.
As a developer, however, there is one downside: HTML email templates are a pain to build. The need to support ancient clients (Outlook 2000, anyone?) means modern techniques like responsive design go out the window, while limitations on <style> tags leave us restricted to inline CSS even in 2016.
This is particularly upsetting given our team spends a lot of time writing code for the modern web, where we’re spoiled by the abundance of tooling such as Gulp, SASS and Browsersync. Which got us thinking: what if we could make email development as easy as building a website?
Building blocks
My colleague Chris Hutchinson has written previously about Deck, our templating system that makes it simple for journalists to put together emails each day by stacking pre-configured modules, called cards, on top of one another.
From a development perspective, a Deck project is made up of several sections: a header, which always appears first; a corresponding footer; and some number of cards in between. Each of these sections has an associated template, which is an HTML snippet that uses Handlebars to output any text, images or other data entered by the journalist. Our challenge is to build templates that will render correctly regardless of how many cards there are or what order they’re in.
Because nested HTML tables are the one thing that work reliably in all email clients, our solution is to create each card template as its own self-contained <table> element. The header and footer templates, meanwhile, contain all the necessary metadata, parent elements, and Outlook-specific comments. The result is a complete HTML page with a guaranteed correct structure no matter the choice of cards.
For a while, that was sufficient. We wrote our CSS for each card template directly inline, and with enough Litmus testing we were able to produce several richly designed newsletters that we knew our readers would be able to enjoy. That was, until word filtered down along these lines:
We’re going to turn off an old system, so we need to migrate about 25 ancient email templates into Deck. We also want to completely overhaul their designs. And it needs to be done soon.
OK.
Improving the workflow
Writing inline CSS by hand wasn’t going to cut it any more. We needed a rapid development process that would allow us to build email templates as quickly as we could build websites, with CSS that was guaranteed to work in all clients and the ability to easily make sweeping changes to the design — no more changing the font colour on 20 individual inline style attributes.
Enter yo deck, our companion Yeoman generator for Deck. Given a JSON representation of a Deck project, the generator will scaffold out HTML files for each type of card it finds and even hazard a guess at an appropriate table structure for each one.
Next it will scaffold out accompanying SASS files — one per template, again with guesses at an appropriate structure, plus some well-tested defaults and resets to help us avoid common issues.
Finally, the generator provides a custom Gulpfile full of useful functionality. While we’re developing a template we can live-compile and reload our SASS and Handlebars, enabling us to see exactly what the template looks like at any time. If we want to try out different sample data, we can simply alter or swap out the JSON file from Deck.
When we’re ready for production, our system processes our template files so they can be uploaded to Deck. As well as automatic inlining of CSS, it performs some repetitive tasks we might otherwise forget or get wrong — for example, copying and transforming all our <img> tags so they will display correctly in Outlook. It also includes a custom CSS and HTML linter, which will warn us if, for example, we’ve forgotten to properly set an image’s width.
All of this means our HTML templates are kept extremely clean and simple during development:
<table class=”card border”>
<tbody>
<tr>
<td class=”heading”>{{heading}}</td>
</tr> <tr>
<td class=”copy”>{{{copy}}}</td>
</tr> <tr>
<td class=”image”>
<img src=”{{image}}” alt="{{image-description}}">
</td>
</tr>
</tbody>
</table>
While the SASS / CSS is neatly taken care of elsewhere:
.card {
.heading {
font-size: $heading-font-size;
} .copy {
padding: 10px 0;
} .image img {
max-width: 660px;
}
}
Using a combination of Deck and our generator, modernising our suite of email templates became only as hard as unpicking their existing CSS. With that done we can now make changes to the templates in minutes instead of hours; spinning up a brand new email design from scratch takes a matter of hours instead of days. What’s more, although we still run everything through Litmus, it’s increasingly rare for the testing process to throw up issues. Last week alone we made changes to three templates that would previously have taken at least half a day; we were able to complete them in 40 minutes.
Building emails for 2016 is still hugely frustrating, and we’re going to be nesting HTML tables for a long time yet — but there’s no reason we can’t enjoy a modern workflow while we’re at it.
