We love pretty things. The easier they are to use, the better. We recently overhauled our emails to make them look better, render and function properly across devices and clients, and highlight key information. As we embarked on this journey, we ran into a variety of issues. In addition to the standard HTML email challenges, we had to resolve some interesting problems that were specific to our new design.

In this post, we’ll review how we handled the redesign, covering a handful of topics including:

  • Media queries
  • Email-specific markup (HTML and CSS)
  • Tools of the trade (Pardot, Litmus, and SendGrid)
  • Testing emails in a Rails environment

Note: This article is Part 1 of a 2-part series

Why update?

We updated our emails to respond to user feedback, improve usability, and stay up-to-date with modern design standards.

Responding to our users

Some users want more mobile-friendly emails. Others can’t find the important or relevant information of the email fast enough. We wanted to fix that.

Improving usability

During our redesign, we asked ourselves, “Can we provide more?” We wanted to add more relevant information to our emails so users can know exactly what’s happening with their sites without leaving their inbox.

Staying current

We never want to fall behind or be left in the dust. We hear comments all the time like, “your app looks good…way better than the other guys” and “it all looks so clean.” We love hearing this (who wouldn’t?), but we aren’t content leaving it at good. We want to make it great.

Design for your users

We know that we can’t optimize for everyone. There are tons of email clients that we want to support, but it’s tough to get them all right. Instead, find out what your specific users are reading from and make sure that those are 100% handled.

We use SendGrid, a popular email delivery platform, to send our app emails. Using our SendGrid data, we know that the majority of our users are on Gmail, Outlook, and Apple Mail (which happens to be inline with the global metrics for top email client usage). We don’t have as many mobile views as we do desktop, but 83% of our mobile users are on iPhone. This is great news, since Apple Mail and the default Mail app on iOS support more HTML email features than any other mobile client.

Here’s a look at some of our numbers from SendGrid:

Desktop email client usage
top desktop clients.png

Web-based email client usage
top webmail.png

Common email problems and solutions

Since we know the most popular email clients among our users, we can account for common problems for each when writing our templates. Here’s a list of the more common problems and techniques that can be used to solve them:

Always use 6-digit HEX values

Outlook drops 3-digit HEX values and replaces them with a harsh blue or black. For example, a bgcolor set to #FFF turns a pretty white backdrop into an ugly blue, and makes black text impossible to read.

Inline styles everywhere, every time

Clients like Gmail drop everything inside the <head></head>  tags, so things like media queries and viewport settings are rendered useless. Place inline styles on every <table><td><span><p>  and <div>  (div tags should be used sparingly, more on this later).

Force your font-size, color, background color, and font-family upon your email

This accompanies #2 above–some email clients aren’t as smart as others (or maybe they are too smart?) and if you don’t specify a CSS property inline, it might inherit a property from a parent element. So, a pretty Open Sans font-family  gets rendered as Times New Roman on the one element you didn’t specify a font-family  value.

Expect Gmail and Outlook to force their own styles on URLs and email addresses

No matter how hard you try and customize the font color, some email clients (like Gmail and Outlook) apply that hideous blue anchor tag style to text–even text that isn’t an anchor tag. In our Set Password email, we display the username as standard text and a URL as standard text for copying (not clicking). Despite the fact that these are regular text blocks, an anchor tag is auto-created and default styles are applied:

Anchor tag auto-created by Gmail & Outlook on URLs
auto generated blue anchor terxt outlook mac.png

Define CSS classes as an element attribute

Yahoo doesn’t play nice with the way we typically write our CSS selectors ( .class-name { ... } ). The safest approach is to define all CSS classes as specific element attributes. That way they work anywhere normal CSS selectors function and with Yahoo. td[class=class-name]  is an example of CSS written as an element attribute.

Explicitly define the viewport

Not every email client cares if you define your viewport, but some do. To handle those, set a viewport in the <head>  tag.

If you want your email to be responsive, use:
<meta name="viewport" content="width=device-width, initial-scale=1">

If you want to lock the viewport to to a specific width, use:
<meta name="viewport" content="width=600">

In this example, 600px is the width of the body of my email, but you could change “600” to any number you want. Be careful going much larger, though, as the email may render extremely small on mobile devices when it loads initially.

Nest, nest, nest

Tables are our friend. When you need to align an object in your page or place text somewhere specific other than exactly left, center, or right, just make another table and nest it. The code may look ugly, but email clients will process it more easily.

Don’t float the boat

Avoid using CSS floats. Many email clients can’t handle the float, and your awesome design that rendered perfectly on the latest Chrome will look like garbage to your users.

Long-live the div

The ongoing debate about <div>  tags in email will probably last forever, but there is a time and place for the <div> . Some email clients can handle them (and even float them), but the clients that can’t will simply render <div>  as a 100% wide block element. This will push everything to the left and right onto a new line. A good time to use <div>  is when you want to guarantee anything inside it falls on its own line, creating a line break above and below it.

Know that Outlook doesn’t support margins

Just kidding, they support “Margins”. We’ve always heard that Outlook wouldn’t support margins, so our emails were designed without relying on margins. Recently, however, we discovered that capitalizing the “M” on margins will allow Outlook to process margins correctly. Ridiculous? Maybe. But good to know.

Part 2 will be coming soon

This post blossomed into something much larger than originally anticipated. After beginning, it was apparent that a separation could be made between common email problems and specialized issues that happened with our emails.

In our next post, we will highlight the issues that are less common and deal with local Rails environment testing.

Suggested Blog Posts

The Perception Gap for Poor Web Performance

E-commerce revenue continues to grow,as consumers turn away from shopping in brick-and-mortar stores to shopping online.  However, many businesses are not prepared for this growth because they do not fully understand the market and how to invest in...

Read More

Measuring Cross-Browser Performance

In recent years, client-side browsers have been more involved with processing code before it reaches the user's desktop, shifting away from a reliance on servers handling the bulk of this burden. Websites and applications now rely more on a user's br...

Read More

Using Browser Trends to Maintain a Better Site

Because of the multifarious nature of web clients today, it’s important to consider the usage statistics when designing, implementing, and managing your site. However, misconceptions often arise when determining what browsers to design for an...

Read More

Finding Causes of Intermittent Errors from Google Webmaster Tools

Google Webmaster Tools is a web service that allows webmasters to view the status of their sites as seen by Google and the Googlebot crawlers. In addition to indexing your site structure and content, the Googlebot crawlers also record data on perform...

Read More