Email can be one of the most powerful ways to engage with your users, and can serve a multitude of purposes. It can be used as a way to highlight selected content (weekly/monthly newsletters, 'year in review', etc.), provide a service to users (analytics breakdown of visits to your profile/favorites page), or re-engage with users (new feature announcements, etc.). Here at Artsy we use all of these kinds of emails and have found them to be a very valuable asset. However, best practices for template layout and CSS (keeping in mind the variety of devices and screen sizes that your users have) are quite different from, and very far behind, the current HTML5 standards and practices for making beautiful web pages. In this article, I'd like to present some techniques I've successfully used at Artsy to create emails that look good on your browser or mobile device, in some of the most popular email clients out there.
The Main Difference Between Email and Web
A fundamental difference between email and web, and which essentially accounts for the completely different methodology and rules you should follow for emails, is that of the rendering client. In 2014, (assuming you are not supporting certain legacy versions of Internet Explorer and other old versions), browsers for the most part will render passed in HTML and CSS in a standard fashion. While there are some notable exceptions still, graceful degradation is quite possible. That is because the only 'interpreter' of your HTML is the end user's browser, which operates under a certain set of known rules. With emails however, the interpreter is the end user's mail client of choice, which can be: native iOS apps, web apps, and even standalone desktop applications. All of these do their own parsing/interpreting before rendering, which can cause HTML that results in a nice looking web page to look totally broken in an email, as well as the same exact email looking remarkably different across mail clients. One of the main reasons why email clients do this is to remove things that might interfere with the rendering of the mail client itself, or any security risks.
Some Basics about Tables
Yes, it's 2014, and yes, we're going to talk about tables on an engineering blog. That's because for emails, tables are going to be your main tool to position and lay out your content. Two of the most common CSS selectors (
display) are bad ideas to use in email. They are mostly unsupported by mail clients (which will reach in and rewrite your HTML/CSS) and will lead to unexpected looking output. However, you can achieve virtually any layout desired using tables.
Here is sample HTML that generates the top part of the email shown above. While it may make your eyes bleed from the table use, notice we are able to achieve the beginnings of a basic 3-column layout, with equal-width columns and centered headers/text with no position-related CSS.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
Now under this we present a heatmap and table of top views by city. For that we use the same 3-column table, except specify a colspan of 2 on the column that contains the heatmap. That is because we would like that column to take up a width equal to the first 2 columns of the equally spaced three at the top, and the table of top views will take up the last column. Here's that markup:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Notice that again we are using no position or display related CSS. However, now our table has a 3 column section and a 2 column section, and we are well on our way to creating a nice email! I kept these as separate rows in the same table, but could have equivalently had each of them be their own table with no ill effects and almost the same markup. Depending on your design and layout, you may need to have multiple tables (nested and not) to support different widths and column layouts, however they should all just work.
Background Images and Overlayed Text
Ok, so tables are all well and good and you can achieve a lot using them, and without having to use any display or position CSS. But what if you want to overlay text on an image? (or even another image over an image)? On a web page, there are many ways to accomplish that, but they all use CSS that you really should not be using in emails (namely:
left, and most layout properties besides padding. Also, no negative padding please!). But no worries, because you can still accomplish that using background images!
Here is an example from our current welcome mail to users:
The top part (the iPhone pic) is actually two images (the picture, and the App Store logo), as well as some text overlayed on top. Here is the HTML to accomplish that:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
I chose to use a separate table to hold this content, where the background image for this table is the picture of the iPhone in hand. That table (with a background of the photo) has two rows, each with one column. The first row which is for the top part of the image, contains the 'Download' white text. That is positioned within the column through padding, which is well supported by most mail clients (as long as it's positive padding that is!) The second row, for the bottom part of the image, is a picture of the 'Download on the App Store' logo, and we chose to put that in an anchor tag and link to the App Store. You could have alternatively made this image a background as well to achieve the same overlay effect, as well as added more overlaid text, etc.
Essentially, to overlay text on images, and images on images - your only option in email is to use background images.
Ok, at this point we know how to craft some 'dynamic' layouts, (multi-column, sidebar, etc) and can overlay text and images for added effect. Now let's think about how this should work/look on a mobile device. Media queries will be our tool of choice here (well supported by mobile mail clients, with a notable exception being the Gmail iOS app.)
Something to keep in mind, depending on your use case, is to potentially design the email in the first place with mobile in mind. This can mean larger font sizes across the layout, as well as a single or two column layout max for your content. Since you have much less screen space to work with on mobile, the media queries we are going to use will largely be to increase font sizes, as well as using 'width' and 'float' to force a two column layout into one column (as an example). Depending on the mail design, this can be simple to do, or quite tricky. It's worth considering this in your initial designs.
Now the first thing to do is to include the following meta tag in your HTML:
This will tell the browser to treat the viewport size as the size of the device that is being used. This combined with media queries will enable us to create mobile emails.
As an example, consider the following two images. The first is the desktop version of the top part of a personalized weekly mail (blog post on how we efficiently generate these to come!), and the second is the mobile version of that same mail.
The markup for this is pretty vanilla (similar to above, 3 column layout in a table). For mobile, we want to left-align everything and trim things down to one column. Of note here is that we are truncating text with ellipsis in the desktop version, and when the content reflows to one column we actually have more room to reveal the text (but still keeping truncation in just in case), so we have to enclose the text in a
div (must have a block element for truncation)
Here is how we truncate text:
1 2 3
We specify a width on a block-level element and then use the ellipsis trick. Here's another screenshot of the truncation in action:
Our first media query can be something like:
1 2 3 4 5
We've set the breakpoint at 320px (vertical layout on an iPhone), and at widths less than or equal to that, this rule will kick in. Note the '!important' at the end (all of our media queries will have that to allow them to override the existing inline CSS). This is enough to expand that div and reveal more text.
Here's the media queries for the rest of this section that transforms the three column layout into one:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
td[id='nested-summary-col'] are the
tds that hold the thumbnail and artist or gallery name.
Essentially all we are doing is changing the width of the container/parent table to 300px, and then making the width of each
td 300px and adding a float. This will force your table to now be a one column layout- easy!
Some misc. email tweaks
Sometimes it becomes necessary to hide/show certain things for mobile or desktop. This can be a bit tricky due to not being able to use
display:none; , so here are a few things I've found that worked:
width: 0px;(works for hiding images)
line-height: 0px;(works for hiding text)
font-size: 0px;(works for hiding text)
Another thing you might encounter is that text links automatically become blue in email. This is because many mail clients will take an un-styled or black link text and make them a default blue color. An easy hack to get around this is to explicitly color your links something like '#000001'. This 'almost-black' will be left untouched by mail clients, yet is close enough to black that the naked eye can't perceive the difference.
Here is a gist I use to prepare artworks for a columnar display like this. You pass in a collection of artworks (where each artwork is arbitrarily sized), and the number of columns and width of the desired output. It will return the artworks grouped into columns that can be directly rendered in an email, while respecting aspect ratios and ensuring the columns are of approximately equal height - resulting in a dynamic feeling layout. For this email, we group this set of artworks into 2 coumns, with each column having a width of 300px (for desktop).
Great tools to use:
- Premailer This will enable you to develop CSS in a sane (ie- not inline) way, and then at generation/compile time, inline it for you.
- Litmus Using Litmus's VM's with different OS's and mail clients, you can preview how a sample email will look among all sorts of different configurations. I recommend figuring out what mail clients/browsers/OS's you want to target and making sure you test all your emails here.
- Haml (or any templating language of choice). A lot of the blocks of content in our mails are dynamically generated, and Haml's conditionals and looping syntax, as well as Ruby-style string evaluation has proven invaluable.
That's all for now! With a lot of trial and error, I've built up a toolbelt of tricks, techniques and hacks I've been using to develop responsive and pretty emails quickly. I think of the limited set of tools at my disposal as a puzzle with which you can still create great looking and responsive layouts to feature your content. Previewing mails using Inbox Inspector have enabled me to craft, deploy, and send them to our users with confidence. Post any comments or tips of your own here, and follow us on Github!