According to Litmus, mobile operating systems accounted for 47 percent of all email opens in March 2014 – down from a high of 51 percent late last year. Apple’s iPhone was the leader in market share last month, being credited with 26 percent of all opens – a large lead over Outlook, which was number two with 14 percent.
It’s possible that your audience isn’t reading your email messages on mobile devices – but it’s unlikely. I feel that I understand the concept of responsive design and that I know enough to answer some basic questions. That said, I was eager to learn more and understand some of the nuances, especially around how you decide which technique to use to achieve the responsiveness. If you feel the same, this column is for you.
I was lucky enough to have dinner recently with my colleague Luca Bellavita, a design and HTML manager for Alchemy Worx. He’s based in London while I work out of our Atlanta office, so it was a real treat to spend some time with him (he cooked us a lovely risotto!) and learn more about responsive design and coding.
In a nutshell, responsive design and coding allows us to send one email message that will automatically adjust how it appears to the reader based on the size of the screen it’s being viewed on. It’s an attempt to optimize the recipient’s experience. Typically responsive emails are designed for desktop, tablet, and smartphone views. The wireframes below give an example of how the elements in an e-mail might be rearranged via responsive design through the use of media queries and/or CSS.
There are actually three techniques you can use to achieve responsive functionality, per Luca:
- Fluid Coding (aka Liquid Layouts)
- Show and Hide
This is what I think of as the simplest way to do responsive design – but as Luca taught me, there are times that it’s a good choice and times when it’s not. Fluid design shrinks the width of the email to fit the width of the screen – and shrinks each column proportionally within that. Images will resize; text will wrap. The email keeps the same proportion width-wise, but the length of the elements may change. Some responsive email messages that rely on fluid coding look really good on a smartphone; others don’t.
Fluid Coding is fairly easy to visualize. That’s not necessarily the case with Show and Hide and Stacking, so I wanted to share our latest Alchemy Worx newsletter to provide examples of both (and yes, you can mix these two techniques in a single email message – which I didn’t know before I spoke to Luca!). Obviously, the smartphone view is on top and the desktop/tablet view is on the bottom.
Notice how the jelly, uncommon goods, and Pandora image moves below the “Our Favorite Emails…” copy block in the mobile version? That’s an example of Stacking.
And see how the bright yellow “Stay Tuned…” block became narrower in the mobile view? That’s an example of Show and Hide. Let’s start by talking about this technique.
Show and Hide
From a coding perspective, Luca says that Show and Hide takes the most work, because you actually have to design and code each element twice (once for each screen size) and then specify which version of the element should be shown and which hidden for each screen size.
If you’re doing an entire email in Show and Hide, it’s like coding two emails – and it can actually take almost twice the time that a single email would. It also increases the size or weight of the email in kilobytes (compared to the other two options). These are not necessarily reasons not to use Show and Hide, but they are things to keep in mind.
Let’s talk about the yellow block. It’s a banner image; simply shrinking it down to the narrow mobile width would have made the copy too small to be readable. That’s why Show and Hide was used here. We created a second version of the banner, wrapping the text and keeping the font size large enough to be readable in the mobile view.
Stacking is Luca’s favorite technique for responsive coding. But not all emails lend themselves to this method.
If you use the stacking technique you don’t have to create two versions of each element. The existing elements are just repositioned and/or scaled to create a narrower version for mobile. In order to stack, the elements of your email need to be arranged in columns. Desktop views with two or three columns of the same width (our example above has two columns of the same width) are easiest to stack, but structure can vary.
Three last notes.
In order to do responsive emails, you really need to be thinking about which of these coding techniques you’ll be using when you do the design. I grasp this much better after my dinner with Luca. In addition to column format you need to think about background images and what slicing and stacking your content will do to them.
Another thing I grasp better since eating that delicious risotto – I now understand why few WYSIWYG editors are able to create responsive design emails (and why those that do use the Fluid Coding technique). It’s because of the judgment calls that need to be made when you use Show and Hide or Stack. Virtually all of our work for clients is designed with responsive in mind and hand coded. Responsive email has been our standard offering since late last year.
To help one of our clients with their responsive email program, we recently developed a custom tool that allows them to populate their responsive email templates with new content without having to edit the HTML. It uses a combination of Share and Hide and Stacking techniques, which are pre-defined based on the template.
Responsive email design and coding are here to stay. We continue to work on tools and techniques to make it easier and more effective. Whether you’re a marketer, a designer, or a coder, increasing your responsive design and coding knowledge will serve you well in the future.
Until next time,
The web doesn’t have a traffic problem, but it has a conversion problem.
Do you ever get the feeling that you’re being ignored? That despite your best efforts to ensure every email you write is a) highly relevant; b) succinct; and c) blurb-free, your message still gets overlooked?
As consumers, we live in a real-time world. We have the technology to access the information we need, when and where we want it, and the "when" is usually "now."
A new starter in Team SaleCycle recently asked me the following question… “Wouldn't they just come back anyway?”