The techniques that we’ve incorporated into our most recent newsletter – such as animated GIFs, web fonts and bulletproof buttons – have been all the rage in email campaigns. However, what’s had many designers and marketers stumped is how to implement them.
Following from our earlier post on email workflow, we’ll be demystifying these techniques in Part 2 of our Email Redesign series. Also covered are some of the design and code considerations that needed to be made, especially when sending to an audience that’s increasingly reading their email on mobile devices.
To help us with our most pressing questions, we’ve got Tim, our email designer and Stig, our ever-resilient email coder, at the ready.
First up, what makes email design and code different?
Tim: One of the biggest challenges in designing an email are the technical restrictions. What you’re capable of doing in a browser is far more advanced than what you can pull off in an email client. Because of this, it’s easy to find yourself stuck in a glass case of boring, underwhelming design… And emotions.
I’m a big fan of designing for best case scenarios. Try not to think about what isn’t possible – for the start of the design, at least – and let the creative juices flow. Design with custom web fonts, rounded corners, shadows and gradients to really make the email sing! Once you’ve got an email that’s so visually stunning that it will knock the socks off someone looking at it in Apple Mail, you can go back to your design and plan for broken rendering environments and unique email client bugs.
Web fonts can have fallbacks, buttons with rounded corners can use CSS and VML – in the process, you’ll get a couple of finishing touches simply won’t display in certain clients.
Of course, it helps when you’ve got a couple of email gurus like Stig and Ros (shucks, Tim!), but there are some great resources out there to get you started and hold your hand along the way.
I’m a big fan of designing for best case scenarios.Stig: Some of the most commonly used email clients are still stuck in a state often compared to web browsers circa the late nineties. Aren’t you glad Internet Explorer 5 and Netscape 6 aren’t still making appearances in your website’s browser usage stats? Coding HTML emails means dumbing down your code to the lowest common denominator, while also trying to provide the best experience in modern email clients.
Progressive enhancement is a good way to approach both web and email design, but emails tend to end up with a much more eclectic blend of deprecated coding practices and experimental new techniques.
Using best practice for the web when coding will often provide consistent results across the few clients that have good rendering capabilities. But to get things to look right in Gmail and Outlook you may need different fixes for each of them. And for Yahoo! Mail. And don’t forget about images-off. Before you know it, you’re working with more back up plans than Antwan Patton.
How the hey did you pull off that smooth animated GIF?
Tim: Dynamic Content was the feature we wanted to highlight in this instance and it’s very nature is, well, dynamic. Moving. We didn’t want to have a static image illustrating this and thought it’d be cool to clearly show an example of what Dynamic Content is.
The illustration itself is really quite simple, and I attempted to animate this myself. Fades, slides, bounces. They weren’t really working for me. Luckily, our creative director Buzz was on-hand to provide some silky smooth transitions using minimal keyframes and some clever blur techniques.
The real shame is that we couldn’t use the Retina version of the animated GIF due to its sheer size – over 500kb is just too big for an email image in our opinion.
So, what kind of layouts result a good responsive email experience?
Tim: These days, it’d be silly to design without mobile optimization in mind but we didn’t want that to completely dictate the design of the email. Our last newsletter was largely comprised of single column articles, making any sort of mobile optimization easy by reducing the column width and tweaking accordingly. However, single column can be quite limiting when it comes to designing a really beautiful layout for anything wider than a mobile device, so we opted for a single-column mobile approach, but that said, our desktop emails aren’t as limited – you’ll find two column, three column, even six column layouts. With this newsletter, we had some freedom to explore a wider range of designs while still optimizing for the smaller screens.
I see bulletproof buttons! Are there any caveats to using them?
Stig: Bulletproof buttons suck, but they’re the best option we have in my somewhat-biased opinion. I say they suck because they add more complicated code to the email than should be necessary, and ESPs – including Campaign Monitor – can’t track the button clicks you get in Outlook 2007/2010/2013 at this stage.
Before I came up with this technique, there just weren’t any great options out there. For example, if you used image-only buttons, one of the key elements of your design would likely be blocked, never to be seen by half your recipients. Other issues that occur with alternate button techniques, especially those based on a link alone, include that links with only CSS padding deflate in Outlook. If you wrap a link around a table for spacing, Outlook won’t let you click though. Then, if you place the link inside a table instead, only the button label will be clickable and nothing happens if you click the rest of the button shape. The result is a distant cousin of those classic prank buttons which would move from under your cursor on mouseover.
You get the idea.
So, the motivation was to replace all of these flawed methods with a “super hack” that allowed you to code big clickable buttons with background images, rounded corners, and even shadows if you do some custom coding.
Despite what I said earlier about them sucking, bulletproof buttons really are great because, even without us counting button clicks from Outlook, the big green button got over 32% of all tracked clicks in this newsletter. Plus, with tools like buttons.cm, they’re not difficult to generate, either.
I see you used web fonts… And media query expressions that aren’t of the regular max-width: 480px type. Why?
We also made sure to back up the web font Montserrat with a stack of appropriate fallbacks. People reading the email on Macs or iOS devices, but without webfonts, will see Avenir in Montserrat’s place. And for everyone else, we went with the generic sans-serif font, which defaults to Arial or Helvetica on most computers.
When implementing the responsiveness, I didn’t set out to target any particular mobile, pad, tablet or phablet. Instead, I set the breakpoint just outside of where horizontal scrolling would have started in say, a desktop client’s preview pane, so that the mobile version would appear in any narrower email client viewport where media queries are supported.
A media query was also used to replace the background images of the bulletproof sharing buttons in the footer with 2× versions on hi-resolution displays.
3 things we learned…
- Aim high when using CSS and web fonts in your campaigns, but make sure they degrade gracefully in email clients that don’t support these techniques.
- Use bulletproof buttons in your designs, but understand the caveats first.
- With web fonts, know your fallbacks. You don’t have to stick to Verdana, Arial et al, so shop around – Avenir may work for you, too!
Many thanks to Tim and Stig for discussing the design and code considerations that came with our email newsletter redesign. If you haven’t already, check out Part 1 of our Email Redesign series to find out more about how these two coordinated on our November newsletter – and of course, stay tuned for Part 3 when we’ll spill the beans on our results.