Does my email look good in this?

What are the merits of responsive email design? What type of coding is required? Alice Yeates, our digital designer, investigates.

Alice Yeates

05 April 2017

( words)

50% of consumers prefer to be contacted by brands via email versus social media at 9%

2017 is apparently set to be the 'Year of the interactive email'. Rather than jumping on the trend (that's not to say we're not building interactive emails!) I thought it might be good to remind ourselves of the most important choice email designers have to make in building emails: making them work for the majority of the email list - or ALL of your email list if you're very clever and/or no one in the list uses Lotus Notes. There's a time and a campaign for interactive email, but coming to terms with the choices made for most HTML email communications is important too.

No matter how hard you try, a beautiful email in one email client is unlikely to look exactly identical in every client (there is no equivalent to the Web Standards Project for email). This results in a huge amount of difficulty, especially if you're not yet aware of the main email clients that users are opening your emails in. In my previous blog, Email was never dead, I noted that email has some seriously impressive advantages, including the fact that a marketing promotion is 5x more likely to be seen if sent by email than if posted on Facebook. With such potential, it stands to reason that, for the most part, emails need to display consistently (though not identically) across multiple email clients and devices. This applies especially to mobile based email clients, where open rates are now consistently above the 50% mark. This has led to responsive emails becoming the norm. But there are a couple of methods to achieve this, so how do you develop a style of code that covers all the bases for your project?

Responsive design

Litmus defines responsive email design as "using fluid tables, images and media queries to control the layout of an email across different device sizes". Responsive emails make content responsive across multiple screen sizes through the use of CSS media queries. This is how the head of your HTML file would look with a media query in it to make it responsive, 600px is a good base to begin with. In this case, if anything is larger than 600px in screen size it will display the fixed width, anything smaller will display the overwritten styles from the media query. For the most part, I tend to use these to overwrite font sizes and widths only. Creating a design that takes into account how it could stack on mobile to begin with saves the need for altering the design (and having a lot of CSS) specifically to make it work on mobile.

When I first began coding email, this was my favoured method of designing responsive emails. Having moved straight from web design to email design and researching most of this of my own accord, it seemed a logical approach to take as the logic or principals behind it remained the same. However, it had one minor snag; Gmail used to strip out the <head> of any email code, which would render any CSS or media queries completely obsolete, and I still have similar problems with Outlook Web App to date! Aside from forcing Gmail to display the desktop version, there was little that could be done to work round this...

...until I started using the Hybrid method

Also known as "Spongy" email coding, it relies on fluid elements by default and then fixes the widths of these using the 'max-width' style (and heavy use of conditional formatting for everyone's favourite awkward Email Client, Outlook).

To break it down:

In the most basic of terms - for a section of an email with two columns of text; both are wrapped in a larger containing table fixed through inline styling to a max-width of 600px, but the fluidity is created by the main width being 100%. This allows the table to work in a fluid manner up to a width of 600px, but prevents it from expanding any larger than this. The addition of conditional formatting keeps Outlook happy by fixing the width to 600px - as Outlook can't quite handle fluid widths.

Within the containing element, there would be two more elements both with 100% widths but a fixed width of 280px. This means these are fluid up to a width of 280px but will not expand any further. At smaller screen sizes, the two columns will stack on top of one another.

Tip: You can drive the stacking order using the direction:ltr and rtl style, giving plenty of flexibility. This is how I set up the basics of a two column layout that drives the order of the stacked columns through the styling.

The hybrid/spongy method allows for designers to ensure that an email will display in both mobile and desktop clients with ease. It does reduce the flexibility on complex layouts but equally, it guarantees that everything is displayed and not stripped out by the email client. Three column structures, I'm looking at you, you difficult little things.

Gmail's changes to CSS support

Gmail rolled out support for CSS in September 2016, finally coming out from its email-design-hidey-hole. (Though they're yet to support their own fonts). Despite the lack of CSS support in Gmail in general being a factor in the development of Hybrid/Spongy coding, the change to this does not remove the need for it altogether.

Here's why:

Hybrid ensures that the email re-formats to fill the available space, no matter the width of the service provider or device. This means you don't have to optimise for every potential screen size and/or device out there (phew!).

Stacking <td>s responsively on mobile isn't fool-proof. Some email clients don't stack table cells within the same row, only two tables. The Hybrid approach removes the need for relying on "align=Left" or "align=Right" styles to overcome this and media queries to centre these at mobile sizes.

In responsive design, relying on aligning tables means you cannot vertically align content in two columns next to one another. Hybrid allows for vertical alignment, meaning an image next to text can display nicely vertically centred to the image.

New ESPs and apps can appear, new updates can bring massive changes and not knowing how or whether they'll have support for CSS (strikes fear into my very being) means coding for the worst case scenario is always sensible! Judging readers for their obscure choices of email clients can come later.

Reducing your reliance on media queries altogether is a good aim to have an email design - ideally you'd keep your structure and styling as much as possible within the <body> and use CSS as an opportunity to enhance the existing styling rather than definitively set the structure of the email.

To hybrid or not to hybrid? That is the question.

Where possible, I lean towards applying some level of Hybrid coding in emails. I like the knowledge that should any random fluke mean my styling is removed, should any new update come out the day I send an email that obliterates all support for CSS, the email will still look close to the way it was designed. (I call this 'Generalised Email Anxiety'). For complex layouts however, it's not the most forgiving of methods, and I'd use a structured layout relying on media queries to make it responsive, knowing that for some clients I may have to build multiple fallbacks or build to the best case scenario.

To find out more about email and how it can benefit your business, read my previous blog, Email isn't dead, or if you have a project in mind, get in touch.