HTML Emails

Producing HTML emails raise several challenges.

• Different mediums: People look at emails on a variety of mediums, including desktop, tablet and mobile.
• Different viewing modes: Mobile users tend to have a quick glance at their emails, often being distracted by other activities. Desktop users tend to be overload by hundreds of emails and so want to move through them as quickly as possible.
• Different clients: Gmail, Aol mail, Outlook, Apple Mail, Yahoo Mail. The list is endless and each client renders the messages slightly differently. It doesn't help that a lot of them are still using outdated rendering engines. As such, it's a battle to get even the simplest CSS layouts to render correctly.

I was faced with these challenges in developing a set of email templates for Penwizard, an online company that sells personalised children books. To overcome them, I used the following design and coding strategies.

Design Strategies

As emails are viewed in a fractured state of attention, clarity is vital. For the mobile version, I stripped all the information to the bare essentials.

For these order confirmation emails, the most important information is placed in a box, with darker colours being used to emphasize key information even further:

Although, desktop offers more space, users receive hundreds of messages and so only skim through them. Therefore, the desktop designs adhere to the clear, minimalist design of mobile, but use the extra space for images to reinforce the core information.

One glance at this image and the customer will instantly know which product they have purchased.

These money-off coupons emails have less information to convey. This frees up more space on the mobile view to use an image to anchor the message:

Images help with differentiation. When ordering from Penwizard, customers receive an order confirmation email, an "item shipped message" and then finally a "Please review your order image". For each of these, a different graphic is used. This makes it easy for the user to tell them apart.

Of course many email clients strip out images. Conventional wisdom suggests that good alt text can compensate. However, for many images, it's better to leave the alt field blank.

For example, in this template, the product image reinforces information already contained in the text.

Including alt text would be redundant, creating clutter that makes it harder to absorb the core message.

It makes more sense to omit the alt text.

Bars and Sectioning

On both mediums bars are used for sectioning.

This provides a clear division between sections, so the user can easily understand the message contents when quickly scrolling through.

Coding Strategies

Premailer

One of the biggest drawbacks of HTML emails is that many email clients do not apply styles to elements. The work around is to make all your styles inline, removing shorthand syntax.

For example,

.heading {
font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif; 
color: #000; }

becomes

<h1 style="font-style: italic; font-variant: small-caps; font-weight: normal; font-size: 13px; line-height: 150%; font-family:Arial, Helvetica, sans-serif; color: #000;">Thank You</h1>

Naturally, this becomes a nightmare to maintain, especially when needing to make multiple changes.

The solution is to use Premailer. Similar to Compass and Sass, this watches your HTML directory and then produces an inlined duplicate on save.

Tables

After a decade of designing website layouts without tables, it can be jarring to go back to tables. It's best to think of tables like a grid.

The TD element is a unit of content. Multiple TDs are stored in a TR, which acts like a wrapper that contains a row of content.

For easier code maintenance consider using a separate TR for each content section.

If you need more divisions in the grid, place another table inside the TD, although to keep the code clean, it's best to do this as little as possible.

You can use margin and padding to control the space between cells. Unfortunately, you can't apply margin or padding to the TR elements that hold TDs. It has to be applied to the td directly.

Responsive Layout

There's a big divide in email clients. Desktop clients tend to be older and can't parse newer CSS technologies like media queries. Mobile clients are hit and miss. The iPhone's Apple mail client seems especially good at handling newer CSS properties including media queries. The stock Android client also supports media queries but doesn't support all the CSS3 properties. Gmail on both iOS and Android doesn't fully support media queries.

Despite this, it is possible to make a responsive email, but it has to be 'desktop-first' with the mobile version receiving extra code that will rework the desktop layout for mobile. In addition, it's better to use widths on tables to create a fluid width layout. This will ensure the layout will scale to fit the device even when media queries aren't supported.

When using media queries for mobile, be sure to specify both the device with and the regular width for maximum compatibility. E.g.

@media only screen and (max-device-width: 615px), screen and (max-width: 615px) {

}

Hiding Desktop Content on Mobile

For the Penwizard Emails, my primary method was to create a table with two columns.

The first column has all the desktop-only content. Each TD has a class of "col1".
The second column has the main desktop and mobile content. Each TD has a class of "col2".
A media query was used to hide "col1" on mobile.

Hiding Mobile Content on Desktop

Setting mobile only content to display:none doesn't always work as many desktop clients ignore this. The trick is to use the following:

.mob {
    width: 0;
    max-height: 0;
    overflow: hidden;
    float: left;
    display: none;
}


@media only screen and (max-device-width: 615px), screen and (max-width: 615px) {
        .mob {
            width: auto !important;
            max-height: inherit !important;
            overflow: visible !important;
            float: none !important;
            display: table-cell !important;
        }
}

For even stronger compatibility apply the .mob class to both the TD that holds the mobile only content and the wrapper TR.

Responsive Layout and Meta Tags

In normal mobile website development, a meta scaling tag is used to disable zooming which allows a responsive layout to display correctly.
Using this creates issues for email, as the meta tag causes Blackberry clients to display a blank page.
The fix is to use rems. Set you HTML font size to 16px. Then declare all your other font sizes in rems. In your mobile media query, change the HTML font size to 20px. This will boost up the font size for smaller screens.

The rem values won't work on most desktop clients, so you'll need to declare each font size twice, once as pixels and once as rems.

If this sounds like too much work, you can use this mixin in Sass to automate the process.

Here is a code example:

html {
    font-size: 100%;
    line-height: 1.5;
}

body, td {
    @include rem(font-size, 14px);
}

h1 {
    font-family: Arial, Helvetica, sans-serif;
    font-weight: bold;
    @include rem(font-size, 28px);
}


/*  Adjust Font size for Small screen devices, but not small widths */

@media only screen and (max-device-width: 615px) {
    html {
        font-size: 20px;
    }
}

With Blackberry users in decline, it might not seem worth the effort of bothering with them. However, with the rem mixin, it's only a trivial amount of effort to support them and if it creates extra good-will that results in more sales, it's definitely worth it.

Outlook

Microsoft Outlook client has a fairly rudimentary rendering engine. Thankfully, similar to Internet Explorer, it makes use of conditional comments. Sections of a table that display correctly on all other clients apart from Outlook can be hidden as follows:

 <!--[if gte mso 9]>
    <style type="text/css">
   .contact {
display:none;
}
    </style>
<![endif]-->

Then, an Outlook conditional comment can be used to house an entire TR row that contains new content that has been specifically designed for Outlook's quirks.

 
<!--[if gte mso 9]>
<tr>
    <td class="outlook-contact">Call us today! </td>
</tr>
<![endif]-->

The Outlook version numbers are as follow:

• Outlook 2000 - mso 9
• Outlook 2002 - mso 10
• Outlook 2003 - mso 11
• Outlook 2007 - mso 12
• Outlook 2010 - mso 14
• Outlook 2013 - mso 15
• gte - Greater than or equal to
• lte - Less than or equal to

Other Styling Tips

You can use the :hover pseudo class, but you need to apply !Important to get it to work properly on all devices.

Declare the font-family name for all elements such as p, h1, h2, h3, as Outlook won't render inherited font families.

For example:

body {
font-family: Arial, Helvetica, sans-serif;
}

h1 {
color: #000;
}

h2 {
color: #e3e3e3;
}

p {
color: #d3d3d3;
}

would change to :

body {
font-family: Arial, Helvetica, sans-serif;
}

h1 {
color: #000;
font-family: Arial, Helvetica, sans-serif;
}

h2 {
color: #e3e3e3;
font-family: Arial, Helvetica, sans-serif;
}

p {
color: #d3d3d3;
font-family: Arial, Helvetica, sans-serif;
}

Doctype

As Desktop email clients tend to be dated, the best type of Doctype to use is XHTML 1.0 Transitional doctype. If you have a more modern audience, then you can stick with HTML5. There's a great article from Campaign Monitor that explains it here.

Conclusion

Although HTML email can be challenging, employing the strategies above gives plenty of freedom in the design. Overcoming these challenges make development especially rewarding.