Navigating all the quirks of HTML email is super fun (if your definition of fun includes cursing Outlook 2007 for using Microsoft Word as a rendering engine). Equally fun: updating email templates and keeping them consistent with one another as they evolve.
It's important to deliver thoughtful and well-crafted emails when they're being used as a direct line to reach over 50,000 people. However, ensuring the quality of that work can quickly become tedious and time-consuming, especially when many different hands are touching different parts of different email templates. This, and having to use tables for layout, adds up to a high yuck factor—it's not something anyone really wants to spend their time on.
Having waded through that mess myself, I developed an automated email creation workflow to rescue my fellow designers from the tedium of email template creation and maintenance.
Working on a Workflow
To think about how our workflow could be improved, I sketched out what our existing email template creation process at Sunlight looked like, and what the ideal process would look like.
The original process involved building all of the markup and styles in a single HTML file. Framework dependencies were dumped into the same file, and often modified directly instead of being overridden properly. These templates were supposed to use the same header and footer, but those were usually just copied into the file from other templates.
For testing, we had to manually inline our template code using a CSS inliner, individually upload each image in the template, and then run it all through Litmus. When a bug was found and a fix was attempted, we'd have to repeat the entire testing process again—sometimes up to 50 times for a single template. (Pretty serious about quality.)
It's easy to see how much of that could be streamlined. Repetitive parts of the templates like the header, footer, and framework dependencies could be broken out into common shared files. Inlining tasks, uploading images and even running tests in Litmus could be automated to save time.
Ideally, a designer would only need to write the template-specific markup and styles and be done.
The Process of Automation
To make this automation a reality, I wrote some custom tasks for Gulp. I broke out the varying headers and footers into a set of common partial files, to be included in every template. This makes it easy to quickly make changes to the header and footer and have those changes updated across all of our templates immediately. Previously, this process involved modifying every template individually and verifying that the changes were made correctly—it was an inaccurate process.
The Ink framework CSS was broken out into its own stylesheet, which would allow it to be included in any template as needed— but never directly modified for the sake of a single template. I also extracted a set of base "Sunlight" CSS styles that were mostly common across the templates— including brand colors, typography, buttons, and specific Ink framework overrides. This allows for changes to the overall base theme if needed without breaking anything else.
I wrote a Gulp task called
gulp publish. This step builds and inlines all of the source files and outputs the finished files to a directory called
/dist. It also inlines each template's CSS in the process. Lastly, I automated image uploading to a single task called
gulp uploadImg. This pushed images to an AWS server (image path replacement is done in the previous step).
All of this means the next person working on this now can focus on the actual development of the email template and not any of the headaches about the process.
I had another designer try this out: the last email template took several weeks to get right—with this new workflow, creating a new email template went from weeks to just a couple days of work.