Today, I thought I would point out a few of my favorite tricks when creating templates. Let’s call them email template hacks. I’ve briefly mentioned some of these in previous blogs, so today I’ll expand on those ideas and add in some use cases and examples.

1. Leveraging Substitution Fields in CSS

The first trick is to use substitution fields for your CSS values. Colors, fonts, height, pretty much anything can be substituted. Many email clients leverage header styles while others don’t. However you choose to tackle formatting your emails across various clients, you can leverage substitutions both inline, in the header block or both.

There are a few different approaches available if you want to inject CSS in the header block in order to maintain standards through all of your templates. The first method is to simply replace CSS values with substitution data. For example, if modifying the text color for an html <a> tag within the <style> block I would modify the color field to reference a substitution field. Here’s an example:

Then, in the transformations JSON call, I would have the corresponding substitution field:

This is the easiest way to modify the look and feel without having to rummage through hundreds of template and make changes. This also assumes that you are holding those values somewhere on your server and can retrieve them fairly easily for the transmission JSON creation.

Building this example up, you may use a dynamic_html and/or dynamic_text blocks. This allows you to make wholesale changes by bringing in large CSS blocks that you may be storing in a repository of standards. Change the blocks in that repository, and you change all of the templates that get the dynamic html/text referenced.

Please keep in mind that dynamic_html/text blocks are held within the global substitution_data blocks, now the recipient substitution_data blocks. A CSS block within the Transmissions dynamic_html structure may look something like this:

This code block is no different than if you had it placed in the HTML template itself. Now it’s just easier to update when referenced into the template via the transmission which pulls from a central repository. The template itself will use this code block with the following entry in the template somewhere in the html <header> block:

If you want to go all out, dynamic rendering even allows for recursive substitution fields. This means that the dynamic code block can have substitution fields as well. A good use case for this is when you OEM or White label your product. In the following example, the CSS block is similar to the one above, but there are substitution fields for the CSS values. Those substitution fields are then placed in the global substitution block of the transmission. For example:

But wait, what if I want to use inline CSS, you ask? Well, just change those big blocks of CSS settings and make them substitution fields.

2. Not sending the email at all if certain data does not exist

As emails become more personalized, they start to look and feel like transactional emails. This is a great trend, but it opens up a greater possibility for unfinished emails. Let’s say a job board sends lists of job opportunities to all active members each morning. Hopefully there are checks and balances that stop the application from requesting for an email to go out if there are no matches for that user, but as a template designer, I don’t want to rely on that. So a little trick that I use is to check for a specific substitution field or array that must be present; if it doesn’t exist, I call a non-existent function with the following line somewhere in the template (I tend to put this on the bottom). This will automatically kill that email from being generated so the bad email doesn’t make it out the door. In the example below, I’m checking for the ProductList array, and if it doesn’t exist, I call the function ‘crash’ with the parameter ‘onpurpose’.

3. Validating data before creating the table for arrays

SparkPost has a very powerful feature that allows a template to loop through an array in order to display a set of information, like jobs, real estate listings or products. In fact, SparkPost even supports having loops within loops within loops. Often, multiple tables, rows and columns get created order to display this information in the fashion the content creator wishes. But what if there is no data to show in one of those loops, but you still want the email to go out, just without the empty rows or tables? In many of my retail templates, I display a list of products that have ‘x’ number of features for each product. If there are no features, I still want the product to be displayed but I may not need to create some of the corresponding html code for the empty features list. In order to keep the email looking good, I check both the existence and the value of my arrays before building unnecessary tables, rows or columns that would house this information. This trick is solved with a simple two part if statement:

4. Using substitution fields in the subject line

So you built your template and placed it onto the SparkPost server. Don’t forget to create a dynamic subject line. One of the easiest way’s to get your email clipped by Gmail or buried into a huge thread is to use the same subject line over and over. So go ahead and use substitution fields for your subject. I often put the person’s name, along with a subject field. My Subject field in the SparkPost UI is set to something like:

5. Use dynamic_html for headers and footers

So, continuing on the theme of standards, I like to send my headers and footers to each template via the Transmission API in the form of a dynamic_html entry. This allows me to keep a library of headers and footers that can be easily modified without having to change every template. Because SparkPost doesn’t have the ability to store those headers and footers on the server then insert them into the targeted template, it’s a good practice to have those standard headers and footers in another content management system that marketing can change without developments help. When the transmission json is getting built, the appropriate headers and footers are placed into the dynamic_html section which is then pulled into the template before sending.

Upcoming Email Template Hacks

So those are some of my favorite template tricks. In my next blog, I’m going to tackle the trick of validating that the transmission payload has all of the data the template is expecting to receive. The blog will be accompanied by a full PHP code sample for this validation step.

Happy Sending

Jeff Goldstein
Senior Messaging Engineer

Any email template hacks we missed? Tweet us or come find us in our community Slack

10 Steps Great Deliverability Blog Footer

TL;DR: Building HTML Email Templates Sucks

Back in the day, I worked for O’Reilly Media. As I was the only one on the public relations team who knew anything about coding, I was quickly tasked with creating our HTML press releases.

Sidenote: It’s important to understand that everything I knew about programming was self-taught. My dad had encouraged me to learn HTML in high school when I grew tired of the 1990’s plug-and-play website setup that Yahoo offered. I wanted colors and designs and buttons, all things that were difficult to do with their minimal settings. My rudimentary skills grew throughout college as I worked on my poetry website — learning about fonts, columns, tables, and styles.

These skills treated me well, so long as I had the basic templates to follow. But email was a new world. Suddenly I needed to worry about how the email looked in someone’s inbox, whether they were using Thunderbird, Yahoo Mail, Hotmail, or the relatively new (at that time) Apple Mail. Not only that, but as I learned new HTML skills to update my website, I had to forget those in order to go back to coding our emails, because HTML for email is a whole different ball game. It was (and still is!) stuck in the ’90s, with everything from table nesting to client-specific CSS properties.

I eventually moved on from that role, but unfortunately, designing HTML for email still hasn’t. Enter Topol, made by our friends over at Sendmark. They get me.

We know how hard it is to build HTML email templates; to handle all of the code exceptions, table structures, and get the result to be responsive. That is why we have built a tool on top of MJML, where we are an active part of a vibrant community. We have built another layer on top of it to allow anyone to use a drag and drop builder to create MJML-backed HTML emails.

Basically, it’s like Yahoo’s plug & play websites from my childhood, but way better, and for emails, which were always infinitely harder. My mind was blown.

Tell Me More

I sat down with Jan Tlapák last week (virtually, since he’s based in the Czech Republic) to talk about this awesome new email template tool.

Who is this awesome web app built for?
We have built an app for anybody in need of building beautiful HTML email. And by anybody we mean your assistant, copywriter, designer, or even web developer. Maybe even you will use our editor to build HTML emails! With our drag-and-drop tool you can easily build beautiful emails in a matter of minutes. Simply choose a pre-designed layout and start building your own.

Why did you decide to build Topol?
There are only one or two tools available publicly and we aim to be the best solution there is when you need to build a HTML e-mail. Our editor is not only easy to use, but fun! It’s also easy to test your emails with Litmus to make sure things appear correctly in various email clients.

What’s the tech stack?
Our tool is sitting in AWS cloud on Elastic Beanstalk, backed by several Lambda functions and S3. And of course, it’s built on top of MJML, where we contribute to the creation of bulletproof e-mails.

As this is a free service, we aim to keep costs to a minimum. Lambda allows us to move compute-heavy requests out of servers and pay only for what we use. And Sparkpost allows us to completely forget about maintaining email servers and the infrastructure around it — you can test the email template you’re building from within the app, making it a completely seamless operation.

With this tech stack we were able to completely focus solely on the editor itself.

Find Your Specialty

You may be wondering why we at SparkPost don’t take this challenge on ourselves — why we don’t simply build out a WYSIWYG editor of our own. Mr. Rogers has wisdom that resonates in this particular situation (as much of his wisdom does):

Discovering each one’s specialty is the most important learning.

Our speciality at SparkPost is the sending and delivery of email. As our VP of Product Amie Durr says, “We’re really awesome at email, and we’re going to keep focusing on that — along with great developer-centric features like the requisite APIs, data, etc. — as our core competency. WYSIWYG editors and email templates? We could fake it, I guess, but we actually want to help people use the best tool for the job, whatever the job. So you bet we’re really excited to share and support initiatives like Topol.”

As for me, I’m grateful that creating HTML email templates no longer has to be my specialty. These days, I can depend on other people on my team to send stylish emails to our community. And on the rare occasion that I do need to send a newsletter myself, I can rely on email template tools like Topol to create beautiful emails for business and pleasure.topol html email templatesLet me know what you think of the template that I built, or if you’ll be at any of the upcoming events that Ember and I are attending! We’d love to connect with you (in person, via Slack, or Twitter) to chat more about email — whether it’s html email templates, delivery, or any other issues you’re running into. In the meantime, happy template designing!

Mary Thengvall,
Community Manager

Biz Eval Guide Blog Footer