Designing a modern email

It’s not unusual to have a flashback to the Netscape Navigator 4 and Internet Explorer 5 days when working on an HTML email. The quality of rendering engines is totally inconsistent, most modern development techniques are unavailable, and even images – an essential element of many emails – are turned off by default in many clients. This can feel like 1998, but the web development community has learned a lot since then. Strategies like progressive enhancement and modern tools like Litmus can help us build HTML emails suited for today’s Babylon of inconsistent desktop clients, various web clients, tablets, smartphones, and high resolution displays.

Last month we decided to start sending educational emails to new Beanstalk customers to familiarize them with our features. The plan was to send a total of three emails with a set interval between them. After designing these emails I decided to explain my process and go through the tools and techniques I used.

Working on layout #

We decided that each educational email will be written by a member of our team. Chris, founder of Beanstalk, wrote about deployments, Ilya, one of our lead developers, introduced users to advanced tools, and Russ, our systems engineer, explained our approach to security.

I started with a simple design but wasn’t really happy with it:

Emails written by our team members were personal, but the design didn’t reflect this. It looked as if the email was coming from a company, not the person who actually wrote it. So we decided to put the authors in the front seat while still referencing Beanstalk, and metadata is the perfect place to do this:

Now that its clear that the email is from Beanstalk I simplified the look, added the author’s photo and removed the logo:

This looks and feels much more like a personal letter written on the product’s stationery paper rather than a corporate brochure – exactly what I tried to achieve.

Bringing responsiveness to emails #

To figure out which email clients are the most popular between our users I checked Campaign Monitor statistics from our latest newsletter. The results are impressive, but not too surprising for a geeky product like Beanstalk – 30% used Apple Mail, 23% iPhone, 19% Gmail, 6% Sparrow, 5% iPad, 3% Android and the remaining 14% is all other combined. This means that a third of our recipients use devices with smaller screens and our email may not be readable to them.

In normal view our text column width is set to 600 pixels, which limits the number of characters per line to about 85-90 – a top boundary for good readability. I started with adding the @media query for screens narrower than 780 pixels to allow for some whitespace and the green border around the text:

@media only screen and (max-width: 780px) {
    div[class="bs-email"] {
        padding-right: 20px !important;
        padding-left:  20px !important;
    }
    div[class="bs-email"] .bs-wrap {
        width: 100% !important;
    }
    div[class="bs-email"] .bs-content img {
        max-width: 100% !important;
        height: auto !important;
    }
    ...
}

Here I decreased whitespace around the text, let the text column and images take all of the available space and moved the sender photo inside the column:

Next is a version for small screens, like the ones on smartphones. I added another @media query for max-width: 380px after the first one, where I decreased whitespace even more, removed the green border around the email and set a smaller line height to fit more content on the screen:

Using @media queries in emails with old table-based layout still feels unreal to me, but they‘re well supported in new devices and old clients just ignore them. The only exception I can think of is Yahoo! Mail, which ignores the @media declaration itself but applies all included styles to your normal view. To fix this I use attribute selectors like div[class="className"] or h1[id="unique"], which it ignores too. Speaking of hacks, I can’t recommend HTML Email Boilerplate enough as a starting point in email coding – it’s a great collection of workarounds and fixes to rendering problems in major clients.

High resolution displays #

What do people checking emails on iPhones, iPads and Androids have in common? Most of them look at high resolution displays, like Apple‘s Retina. Adding hi-res graphics to email is tricky as many of these people may be on a slow and expensive 3G connection, and nobody will wait a minute for the email to load.

My first take was to replace img elements with divs and use original images as backgrounds, while providing a hi-res version through the @media query only when it is actually needed. This is a hack from any standpoint – divs have no semantic value, they don’t provide alt text when images are disabled, and some old clients just won’t display background images. Even worse is that Gmail and other clients without @media support will show original image on hi-res devices, like MacBook Pro with Retina screen.

This is when I decided to go with the simplest available solution – just create all images twice as big and downsize them with width and height attributes of the img element. This solution works everywhere from Gmail to iPhone, but the downside is increased file size. I used ImageOptim and ImageAlpha rigorously to trim all extra bytes from our graphics and screenshots, and in some cases went with overcompressed JPEG instead of PNG. The total size of an email with 3-5 big images is about 100-150 KB, which is a lot but still not terrible, especially considering we don’t use any graphics in the design (except of logo in the bottom) and images appear only after a few paragraphs of text.

Testing emails #

Any testing starts with sending an HTML email, and it’s not as easy as it may sound. First, you need to host all images and assets somewhere so they can be linked from HTML. Second, you need to turn your HTML file into an email and send it. One option is to create a free account on Campaign Monitor or MailChimp and send email previews to your own email address – this works well, but the process can be a bit slow. My new choice and a recent discovery is the Direct Mail app for Mac – it’s free for up to 50 emails per month, beautifully designed and works really well.

Litmus is another favorite of mine. I checked it before but wasn’t sold on the idea of testing and debugging emails based on screenshots, so I always maintained my own library of email clients and accounts. Things changed when they released Interactive Testing which allows you to test, troubleshoot and preview emails in real-time. Not every client in their library has this tool yet, but even the limited selection saved me an enormous amount of time.

Gathering data #

I’m risking sounding like a Litmus promoter, but another feature we used for the first time in our transactional emails and totally loved is Litmus Analytics. We generated unique tracking codes for every type of email we send, so now we have a solid set of data on our recipients and their reaction to each of the emails we send. The way they collect this data is some sort of magic, but seeing engagement reports, email clients statistics and even the number of forwards is really empowering. With real data at our hands we can see which emails our users like the most and change our communication accordingly.

Hopefully you found something new in this walk through of my design and development process for emails. Know a better way to do something or have a tool recommendation? Let me know in comments!