Crash Course: Building an Email Newsletter

If you’ve spent your career dealing with web standards — and enjoyed watching the progressive disappearance of those creaky, old, legacy browsers — your first contact with email newsletter building might be a little painful. You are going to need to throw out a lot of your web design golden rules to get the compatibility you’ll need with email clients.

In fact, while in 2013 the Standard Web Project Team had been able to say “Our Work Here is Done”, the road to email standards still appears to be very long indeed.

You can see an example of how email clients render the same content looking at Email Standard Project Acid tests. In the screenshot below, you can see how the same mail appears in Apple Mail and Gmail:

Acid test

Email design does require you to reinvent some of your skills. But try not to consider this as a limit to your creativity – rather, treat it as a real challenge.

So, let’s start by summarizing the main points of email design to give you the widest cross-email-client compatibility:

DO NOT:

use CSS3 rules and selectors
use pseudo selectors or pseudo elements
use floating or positioned objects
use background images
use forms
use linked web fonts

DO:

use tables for layout
use inline CSS rules
limit email content width to around 600px
test
test
TEST!

Email building workflow

Set up a prototype

As you would with a standard web project, I recommend you start by drawing a prototype. This will help you to make each graphic adjustment you need and will help you present your work to your client before you start coding.

In this phase you’ll want to create a design that:

catches customer attention
draws them through to the end of the mail (you have a maximum of 8-10 seconds before a reader decides to delete a mail or not)
deliver some call to action (i.e. the “Buy now” or “Contact us” buttons)

You can find a lot of inspiration on the web. I’ve found some good resources are htmlemaildesigns.com, Really Good Emails or Newsletter monitor, provided by ContactLab and these are mainly focused on marketing strategies.

Coding Your Email

As we said earlier, email is rendered by mail clients in many very different ways: our efforts must be directed to cancel out, or at least to minimize these variations.

Fortunately emails tend to have a relatively simple structure, and in most cases this work is not particularly complicated.

Before coding, take a look at the email client stats (it’s better if you can access the stats of the project you are working on), this will help you to focus on most used clients.
There are many email client market share reports on the web. According to emailclientmarketshare.com (provided by Litmus) in August 2014, top email clients were:

Apple iPhone (26%)
Gmail (15%)
Apple iPad (13%)
Outlook (11%)
Apple Mail (7%)
Google Android (6%)
Outlook.com (5%)
Yahoo! Mail (5%)
Windows Live Mail (2%)
AOL Mail (1%)

After this, you can get down and dirty with the coding, paying particular attention to:

Some clients (including Gmail) strip any CSS rules contained within <style> or <link> tags (look at Litmus: Understanding Gmail and CSS), so you’ll need to place each CSS rule in an inline style attribute (don’t panic: there is a simple way to do this)
CSS positioning is scarcely (or nothing) supported so you must use tables for layout.

Boilerplates

Since email development requires you to deal with several email clients needs, the better way would be to start with a boilerplate. You can find many boilerplates and templates on the web (you can find an essential list below), and my tip is to try them all, if possible, to find the better one for your work.

Personally, I often use Sean Powell’s HTML boilerplate or the Emailology boilerplate.

HTML Boilerplate

As you can see in the few sample lines below, boilerplates (in this case the Sean Powell’s one) are strongly commented, and they are a very easy way to learn email coding.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="https://www.w3.org/1999/xhtml">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
	<title>Your Message Subject or Title</title>
	<style type="text/css">

		/***********
		Originally based on The MailChimp Reset from Fabio Carneiro, MailChimp User Experience Design
		More info and templates on Github: https://github.com/mailchimp/Email-Blueprints
		https://www.mailchimp.com &amp; https://www.fabio-carneiro.com

		INLINE: Yes.
		***********/
		/* Client-specific Styles */
		#outlook a {padding:0;} /* Force Outlook to provide a "view in browser" menu link. */
		body{width:100% !important; -webkit-text-size-adjust:100%; -ms-text-size-adjust:100%; margin:0; padding:0;}
		/* Prevent Webkit and Windows Mobile platforms from changing default font sizes, while not breaking desktop design. */
		.ExternalClass {width:100%;} /* Force Hotmail to display emails at full width */

Other free email templates

Inline Your CSS

Despite what we just said, you’ll notice that our boilerplate does use a standard <style> tag for the CSS, even though we know that our CSS needs to be coded inline every single tag of our email.

In fact, not quite ALL CSS: media queries and all the rules that are specific for clients which support <style> must be kept as they are. The rest of your CSS must be coded inline.

Obviously the act of ‘inlining’ your CSS coding could be extremely tedious and complicated (especially in very elaborate projects), but this is where CSS inliner tools come in.

They all work in the same way: you simply paste your original HTML and the CSS will be automatically inlined.

Mailchimp CSS inliner tool

If you have specific needs, my tip is to test them all (I’ve got a short list below) to find the one that best fits your specific needs. For instance in my case, I often have to deal with Twig or Smarty files, and I’ve found I have better results with Mailchimp inliner.

CSS Inliners

What about images?

Images in emails don’t have many particular requirements: you must, of course, endeavor to keep files small, and avoid newer file formats, such as WebP. There’s even an argument that it might be better to avoid PNG files, and use GIF ones instead.

You need to pay attention to ALT text: many email clients block all images views by default (in fact, Gmail did it until December 2013). In addition, users themselves often block images to prevent external tracking, so it is very important to ensure your email doesn’t become meaningless in the absence of imagery – sometimes this is called ‘degrading elegantly’. As you can see in the example below:

An image-only email without alt text as displayed in Gmail with the block image option

The first precaution is to avoid creating emails composed entirely of images (there are also many other reasons not to do this, concerning usability, accessibility and so on…).

The second one is to always add an ALT text to your images to minimize the bad impact (take a look at The 1, 2, 3 of Defensive Design).

Going Responsive

As is the case with web pages, you can optimize your mail to be displayed correctly both on desktop and mobile clients. There are many techniques and tricks to do this and we’ll cover in detail another time, but, for the moment, take a look at this essential list of documents and articles:

Online Editors

Online editors can be a very valid alternative to hand coding an email. If you don’t have particularly specialized needs (or you are short of time) this could be just the trick.
These editors are built into the feature set provided by these email services (Campaign Monitor, Mailchimp, etc…) but you’ll obviously need an account to use them.

Mailchimp online editor

Email Testing

Testing is fundamental for email design. You have to roadtest your design in a large variety of clients to ensure that all runs well.

You can install many clients on your computer, using virtual machines or emulators, and you can make use of paid online services to help you in this job.

Litmus offers a great service for email testing, as well as Email On Acid, and, although not specifically aimed at e-mail clients, even Browserstack can be useful.

Litmus testing example

Some (very) minimal email design principles

Keep it Simple but, at the same time, try to build an “emotional design”. You have a few seconds until reader decides to either read or trash your email, so you have to find the right balance between aesthetics and loading speed.
Consider mobile email clients: in the Litmus email client market share report delivered at the end of 2013, 51% of emails have been read through a mobile device. Mobile share has increased dramatically in recent years, so always keep the fact that your email will often be read using phones and tablets at front of mind.
Pay strong attention to your content. Although this is not strictly a design task, content is, of course, a key element of email composition. Avoid grammatical errors and make sure that the text content is fluid. Also, choose a proper subject for the mail (Litmus Subject Line Checker can help you doing that).
Focus on your goal. If you are sending a newsletter, you probably want your readers to do something: focus your efforts on this, be concise and try to gain the attention of the users; add a call to action button to achieve your goals.

Resources

Despite the growing attention to email design, it seems that currently almost all the best documentation can be found in company blogs (listed below).

The Email Standards Project might be an important resource, but, although many acid tests are up-to-date, the site blog seems to have stopped in 2010. I’ve tried to contact the site without any useful result, so we can’t confirm if the project is currently maintained or not.