Copy
Issue 15 \\ Responsive Email
 

Issue 15 \\ Responsive Email

This week, we'll take a look at how our in-house email guru Fabio Carneiro designed and built a responsive email template system for other designers and developers to use.
Tweet
Share
Forward to Friend
EditingJason BeairdFederico Holgado
Illustration: Caleb Andrews
Hey, did you miss our last issue?
On Twitter: @MailChimpUX

Building a System for Responsive Email


by Fabio Carneiro
I recently set out to create a modular responsive email blueprint for email designers to learn and work from. Though there are plenty of articles and code snippets in MailChimp's email template reference, getting into ready-to-use, working code helps put all of that information into a practical frame of reference.
Creating stable code blueprints is challenging even in modern web design, let alone in the wild west that is email design.
The responsive blueprint isn't MailChimp-specific, so I had to consider the ways in which email designers might actually use the code. It came down to two things: the emails had to be adaptable to many purposes while also being robust across a wide variety of email clients.

Robustness is the easy part. It's true that many email clients are a nightmare to deal with, but things get a fair bit easier once you become familiar with the ins-and-outs of each. Then, it's only a matter of working within those constraints.

Adaptability is a good deal more difficult. Designing and building an adaptable email for a person with a defined set of purposes is simple because you can take greater liberties with design and use specialized HTML or CSS to make it all work. That's because there's context: knowledge of what the email is for, what sort of content it'll be stuffed with and, hopefully, in which email clients it'll be viewed most.

There's zero context to work from when designing and building emails that large groups of people may use, many of them in ways that I can't foresee. To work around the problem of a lack of context, I followed a process that's very similar to the one I apply to the email templates I build for use in MailChimp:
  1. Anticipate common use cases
  2. Determine design patterns for those use cases
  3. Create loose hierarchies and modular HTML structures
  4. Reinforce the code with client-specific HTML or CSS
  5. Educate within the code with commented, easy-to-use markup

Anticipating Common Use Cases

By anticipating common use cases, I'm able to establish a rough idea of just what I need to code and how I need to code it. Pretty much all email falls into four broad categories: Read Me, Buy Me, Join Me, and Understand Me.

'Read Me' emails, for example, are newsletters or RSS-to-email campaigns, 'Buy Me' are ecommerce-based emails, 'Join Me' are event notices and invites, and 'Understand Me' are transactional emails like receipts and order summaries. In the case of this email blueprint, I had to account for all of those scenarios. The most common use case for 'Read Me' emails is simply the delivery of information, whether text or image. For 'Buy Me' emails, it's the enticement to spend money. In 'Join Me' emails, it's to highlight a particular occasion and urge an action towards it. Finally, 'Understand Me' emails are used to convey important details or data and little else.

Determining Design Patterns

All of those use cases, regardless of how different they may be, share components with each other. For instance, 'Buy Me, 'Join Me', and 'Understand Me' emails might all contain a call-to-action in the form of a button, and 'Read Me' and 'Buy Me' emails rely on interesting content, most commonly in the form of multiple images.

By examining the common threads between each type of email, these shared design patterns begin to emerge, and I could then compile a list of the blocks to be built.
Ultimately, 17 different patterns like buttons, image groups, callouts, boxed content, highlight calendars, and captioned images were included in the blueprint.

Creating Modular HTML

Once I knew what I was coding, it was time to figure out how to code it. With this blueprint, I felt that anyone should be able to grab the HTML and:
  1. Understand how the code is structured
  2. Arrange design patterns to suit different needs
  3. Style the email without worrying about the framework
  4. Send campaigns almost immediately
To meet those requirements, the HTML was written in a way that all content blocks share a common supporting structure, which makes the code easy to read and understand. Each of the content design patterns is sequestered in its own table row, which allows for modularity within the template; content areas can be duplicated or moved simply by copying or moving the containing row.
With so many nested tables, it becomes useful to mark off different sections of the code.
Additionally, the entire framework is run by very minimal CSS - just four rulesets in the standard CSS and another four in the media query. There's some placeholder styling for the content itself, but it only affects text styles and background colors, so a designer could go in and write their own CSS without having to worry (too much) about how the functionality of the email will be affected.

Reinforcing Email Markup

Once I finished building, I ran the email through my usual series of tests in desktop, browser, and mobile email clients. In the first run-through, the email rendered without major issues in all the popular email clients. I wasn't quite finished, however, because of two email clients:

The Android Gmail app's lack of media query support and Outlook 2007/2010's Word-based HTML rendering cause no shortage of issues.
Outlook 2007/2010 and the Android Gmail mobile app are terrible email clients. Outlook has a host of issues due to its Microsoft Word-based rendering engine and the Gmail app, despite being a mobile app, doesn't support media queries. Writing email HTML for the former requires very rigid, carefully-crafted code, while the latter requires "spongy" code: not responsive, or even fluid, but pliable.

Normally, in MailChimp's emails, we err on the side of caution and make the emails more robust in order to support Outlook. It does, after all, have a stranglehold on the desktop email client market. Because this responsive blueprint was meant for email designers with a bit of technical know-how, I took the opposite tack and went for maximum mobile support. This meant coding many of the content blocks using aligned tables. Now, the Android Gmail app is happy. You might be thinking, "but why only the Android Gmail app? There's one for iOS, too", and there is, but the iOS Gmail app is even worse - it supports nothing at all. Emails will render just fine, but - for now - forget about mobile friendliness.

Regardless, that solution for Gmail - using aligned tables - is great for flexibility, but extremely brittle and prone to layout mishaps in - you guessed it - Outlook 2007/2010. The problems all stem from a particularly frustrating bug in Outlook that automatically inserts a page break into any document that measures longer than 22 inches (~1700px) in length. When that happens the aligned tables, which are essentially floated, get all sorts of wonky (aside: it seems like the problem's been solved in Outlook 2013).

Because HTML in Outlook 2007/2010's rendered by the Microsoft Word engine the application is rife with quirks, and support for a lot of CSS is poor.
One solution to this issue is to use Outlook conditional CSS, and write a stylesheet to override problems in Outlook. In this case, I kept it simple and just collapsed the layouts into a single-column stack - the same thing that's done on mobile devices via the media query. The conditional CSS is entirely optional, but it is a nice fallback to have available.

With support for Outlook 2007/2010 and the Android Gmail app shored up, the email is now not only pretty robust across multiple clients, it's reasonably flexible, too.

Educating With Comments

Some of these techniques may verge onto "way out there" territory, particularly for newbie email designers. To that end, I made sure to include brief (and not-so-brief) explanations of why a certain bit of code is used and what exactly it does:
Email design is tricky under even the best circumstances, so a little clarity goes a long way.
I also took steps to indicate where a content section begins and ends, and whether or not it requires some kind of special treatment.

By keeping the responsive email blueprint focused on common uses, including design patterns that are ubiquitous in email, ensuring the code is both robust and flexible, and taking the time to clarify any murky code, anyone should be able to dig into the responsive email blueprint HTML and start working with it easily.

Combined with the email template reference, we're hoping that some of the mystery and confusion surrounding HTML email design will be dispelled. We're not finished, though. Not by a long shot. Both the reference and the email blueprints are projects that I strive to continually improve and evolve based on feedback. Feel free to reply to this email and share your thoughts.
By the way, we're looking for a talented UI designer to join the MailChimp UX team.
Is this you?

UX Around The Web

Ask Us Anything

We want this newsletter to be a dialogue. If you have any questions for our team about our release cycles, stylus preferences, favorite apps, or even how Fernando almost slept through a half marathon, send them in. Seriously: hit reply and ask us anything. We'll try to answer every email and maybe even share our conversation in future newsletters.

Twitter
© 2001-2013 All Rights Reserved.
MailChimp® is a registered trademark of The Rocket Science Group


view in browser   unsubscribe   update subscription preferences   



Email Marketing Powered by Mailchimp

Love What You Do