Coding emails is one of the most depressing tasks in front-end development. From coding to sending we tend to want to push those tasks as far from us as we possibly can, but emails are a very important part of any system, and it is important that we take the time to do it right.

A deeper look at email rendering engines

Prior to 2007, coding emails wasn’t actually so bad. Depending on the type of campaign you would be doing you could even use divs and floats. Yes, you heard me. You could absolutely use anything IE6 had to offer at that point in time.

Then, something catastrophic happened. Microsoft decided to replace the IE engine from Outlook with the Microsoft Word engine. As you can guess, the community went crazy. Multiple blog posts and campaigns were launched to try to convince Microsoft to take a step back. Unfortunately, the opposite happened. Microsoft confirmed their choice of engine and published a blog article “The Power of Word in Outlook” (that is still available on archive.org). The blog article can be summarized in one simple quote:

Congrats on that ugly 3rd bar chart, guys… And just like that, the email development landscape changed completely.

Outlook 2000 and 2003 use the IE version installed on your computer for rendering emails, so you could actually use Outlook 2003 with IE 11 right now. However, that might not be the best idea. There are quite a few bugs because IE 11 was not built for that.

Also, something else to know that is quite depressing- there was no amelioration from 2007 to 2013 in the rendering engine. It’s virtually the same thing with a new coat of paint. Now that’s all said and done, let’s get past Outlook and take a more general view of the email landscape right now.

.

Yahoo, Gmail, Hotmail- they all use a custom engine that mashes up your html and spits out a “secured” version of your content. They also remove any style tags. Since they load the email directly into the interface instead of into an iframe they cannot risk you breaking their interface with your custom CSS.

The mobile landscape is quite peculiar. On one side, you have the default IOS and Android mail that are using webkit. It’s generally quite amazing what you can do with them. On the other side, you have the gmail app and inbox that are still using the same crap that the desktop gmail version uses. I’m not sure why Google went that way; one thing is for sure, they don’t care much about responsive email. If you absolutely must, there is a technique to achieve responsive email in gmail, but be ready to lose countless hours to testing. Plus, it’s more of a hack than it is gmail allowing you to make responsive email.

Now you can understand why your devs go insane when your marketing director comes back to you with some small spacing issues.

Optimizing development time

There is a real issue with the time spent coding emails. Even an experienced dev can lose an atrocious amount of time testing all of the possible configurations, time that he could be spending doing things more useful to the company. And I’m not even talking about when you give this task to an intern (which happens a lot); not only will he spend days trying to figure this thing out, he has no idea where he is going and the code will probably be of very poor quality.

So today I will review for you the best tools that you can give to your team to achieve two goals, one of saving time, a lot of it, and the second of keeping a clean code base, that respects standards and is something you can build on top of when you have this new transactional email to code.

Zurb Ink CSS framework

Ink is a breath of fresh air in an environment of despair. Ink is a battle-tested responsive email framework that mainly handles your email layout. It should really be your starting point for any email project.

Ink is, however, not a silver bullet. For one thing, it has no sass and less file structure. You are stuck with one mangled CSS file. It also requires some decisions about margin and paddings that will conflict with your design. It might also increase the number of tables you are using. Don’t get me wrong; it is still the best CSS framework around for email. It’s just not as drop-in as we would like it to be.

The magic behind the Ink responsive system

Ink uses a row system with a TD wrapper, shown up here, and when the window width is smaller than 600px it puts it at display:block. This changes the column’s layout to stack on top of each other. The expander td is used to fix some bugs to make the table go to a full width in mobile layout.

As explained before, this won’t work in gmail, but it is the best future proof technique available right now.

Premailer, or how to keep your code clean

Premailer is not a new tool. Three years ago I was using it at CakeMail to inline CSS files to HTML. However, what changed in the last 3 years is that it is now much more usable. For a project that seemed dead at the time it is now running at full steam, and the support is extremely good. It will even fix stuff you don’t know about to make your email more compatible. There is a grunt plugin, so it should be easy to integrate into your current stack. You can now keep your HTML files clean and generate CSS inline versions on the fly.

If you have a guy that goes onto a website and copy/pastes his code to get an inline version, please automate that process because otherwise it wastes so much time.

Automating tools

There are a couple of Javascript tools that can help you test your email’s code faster. For one, you have litmus with a grunt plugin. With a simple command you can push a new test to litmus.

// Send a specific template to litmus
grunt litmus:dist/output/sidebar_hero/index.html

Then there is grunt nodemailer, which makes it easy to send a test email to anyone.

// Send a template to any email address
grunt email --fileSrc=dist/output/example.html

Team workflow

Time and time again I have seen email being miss-managed with a tangle of non-reusable HTML tags. Email templates beg to be used with a templating engine with an architecture component. The more you abstract the ugly, the faster your devs will be able to implement new templates based on previous work.

The reality is that when starting a new project, your typical team has no transactional templates completed. The guy decides to code them and they generate an output version of their templates. They then plug their sendgrid library on to it. They forget they even exist.

But then the company grows, more teams start sharing templates, and they find they are not always using the same languages or templating engines. They start customizing all of their own templates, and you end up with three sets of very similar email templates. Then what happens is what was bound to happen- one day, the marketing team wants to change the email header, and now you are stuck re-doing the work for three different teams and trying to coordinate the releases. There is frustration about something that should be so simple, and a lot of time is lost.

In reality, they should have all extended the same template, coded with the same templating engine. If you use a lib for sending emails, when they give data they receive the HTML code. Then, to modify the header, you just need one guy to modify the base templates and all of the apps will use the same header at the same time. That way you can also build a library of components and hide those ugly tables behind it. This will enable other devs to build new emails faster, with fewer errors.

Personally, I use Nunjucks to handle my email HTML components. It enables me to do things like this:

// Cross compatible button for email services
{% macro button(label='default', link='#', class='', align='left') %}
 <table class="button {{class}}" align="{{align}}">
  <tr>
    <td>
      <a href="{{link}}">{{label}}</a>
    </td>
  </tr>
 </table>
{% endmacro %}

// import component in template
{% from "/html-components/component.button.html" import button %}

//Usage
button('Google', 'http://www.google.com', 'button-green', 'left');

Being smarter about transactional email delivery

Chances are, right now you are currently using a library given to you by your provider to deliver transactional emails for your app. That’s a good first step. However, you need to think about what is going to happen when the provider goes down (and it will).

A delivery service should be more than just sending and receiving a response. There are three core things to look for when integrating transactional email delivery for your application:

1. Back-up

You should not be locked in with any one provider. When a provider goes down, there should be a way to re-route that request to another provider. Especially since most of them offer a couple of thousand free emails, this can be a life-saver. Your “forgot password” email should not be dependent on only one service.

Also, while some offer a “templating engine” please don’t lock in to it. Use the one your company uses and then send the template through their API, that way you do not destroy reusability.

2. Asynchronous

You should not have to wait for any delivery service to respond. If you can build a service that responds in 100 ms vs. the 200 ms from any email service provider you should. You won’t know if it is sent, anyway.

3. Logs

You should log any errors that you encounter. You also need to be alerted when your provider goes down so you can react with your back-up provider.

I’m still here, what’s next?

There is a tool that does everything I just talked about. It’s called Inker. It handles your coding stack to your delivery server. If you are wondering how you can do email better, it should probably be your first stop.

Inker Features:

Coding

• Built on top of Zurb Ink
• Sane CSS components structure with sass
• Sane HTML components structure with Nunjucks
• Localization
• Auto generate template to HTML documents with inline CSS
• Auto deployment on litmus for testing
• Auto deployment to any email address for testing

REST API Transactional Email Delivery service (nodejs)

• Asynchronous for a warp speed response (you can use it in sync mode too)
• Generate emails with custom data on the fly
• Integrate all major email delivery providers
• Back-up, when one goes down we redirect the request to another provider
• Logs! hipchat, slack, logtenries, winston, push notifications with push bullet, are all in there, but you can easily add your own too

Source: Position Absolute