Wait. What Just Happened to My Email? Webinar Recording

[ 0 By

Nearly every designer and developer has to build emails at some point in their careers—whether they want to or not. But the sheer number of email clients—each with their own rendering problems—leaves many shaking their heads in defeat, bewildered by the onslaught of email design problems.

Having lived through many such scenarios, we joined forces with Alex Mohr from Sendwithus to shed some light on the most common problems facing people new to email and, more importantly, some solutions to those problems.

If you didn’t have a chance to attend the webinar, “Wait. What just happened to my email?”, don’t worry. You can download the slides and check out the recording below.

Views slides & recording →

Try as we might, we couldn’t get to every question asked during the webinar. And there were some great ones. So, I’m using this opportunity to answer some of the more frequently asked questions by those just dipping their toes into email marketing and design.

Why are Google and Microsoft so bad at rendering emails?

All email clients have trouble rendering some HTML and CSS—the two languages used to code email campaigns. This is because they all use different rendering engines. Rendering engines are the underlying parts of the email application that determine what code is rendered to the screen and how it is actually rendered.

rendering-engine

In the case of Google’s Gmail, a preprocessor is used to strip specific parts of the code from an email for the sake of security reasons. While nearly every other webmail client has figured it out by now, Gmail essentially strips out embedded CSS styles in the < head > of an email. And, since many designers use those styles to determine how their campaign looks, those emails suffer in Gmail.

This can be especially noticeable on Gmail’s mobile clients, since media queries—the CSS triggers used in traditional responsive design—live in that section. This is why techniques like hybrid (or spongy) coding were developed, as a direct solution to Gmail’s poor rendering capabilities.

In the case of Microsoft’s Outlook clients, the trouble lies in the fact that Outlook actually uses Microsoft Word as its rendering engine. That’s right, a rich-text editor used by students and business folks alike is used to render HTML and CSS code (or at least it tries to). While older versions of Outlook used the installed version of Microsoft’s web browser, Internet Explorer, to render email code, as of Outlook 2007, Word has been used to make rich-text editing easier for Outlook users.

Unfortunately for email designers, Word has very limited support for HTML and CSS that is commonly used on the web and in email campaigns. This limited support for web standards results in email campaigns that look broken in Outlook. Understanding that support is the first step in getting emails looking good in Outlook, or any email client, for that matter.

Here are a few resources to get you started in better understanding email client support for HTML and CSS:

How do you deal with Outlook not displaying the proper fonts when using web fonts?

Web fonts, fonts served over the web instead of being installed on a user’s device, are increasing in popularity. Since they allow companies to stay on-brand with their typography and encourage live text, they are an ideal tool for email marketers. Unfortunately, they are not supported by all email clients. And, in the case of Outlook, lack of support leads to situations where Times New Roman is displayed instead of any fallback fonts declared in your HTML.

We’ve addressed this issue before with a solution that requires an HTML class on the affected text and some Outlook-specific CSS. While this solution still works well, a cleaner and easier to maintain solution has been gaining traction. Originally proposed by the folks at Action Rocket, this solution requires using @font-face rules to serve fonts and wrapping them in a media query in the head of your email.


<style type="text/css">
@media screen {
 @font-face {
  font-family: 'Family Name';
  font-style: normal;
  font-weight: 400;
  src: local(), local(), url() format();
 }
}
</style>

This solution is an excellent approach since it doesn’t require HTML class attributes polluting your code while still ensuring that Outlook falls back to your declared font stack. Check out Action Rocket’s original article to learn more about the technique.

How do you stop blue links from happening on mobile?

Mobile devices are useful tools. To make them even more useful, companies like Apple have added a feature to their email client that allows users to quickly add information to their contacts, calendar, or map apps. Chances are good that you’ve seen something like this in an email:

ios_links

Specific text-like addresses, dates, times, and phone numbers are highlighted as blue, underlined links to show that they can be interacted with. Unfortunately, these blue links sometimes cause problems from both a design perspective and an accessibility one. When light text on a dark background is turned blue, those links are now hard (if not impossible) to read, let alone interact with.

blue-links-accessibility

We’ve written before about a solution to this problem that allows you to maintain styles on that text but, again, a newer solution is gaining popularity. It turns out that including the following snippet kills blue links on iOS without the need for additional markup in your HTML. Just include it in the head of your email and send away.


a[x-apple-data-detectors] {
  color: inherit !important;
  text-decoration: none !important;
  font-size: inherit !important;
  font-family: inherit !important;
  font-weight: inherit !important;
  line-height: inherit !important;
}

Some webinar attendees astutely pointed out that the CSS above specifically targets Apple devices. While my recent tests have shown that blue links haven’t been a problem on Android, some Litmus Community members have run into problems with Android and Gmail linking things like phone numbers. Check out the Community discussion to see some of the clever workarounds.

What’s the best way to handle responsive images? How about retina images?

As more people adopt responsive email design, the need for responsive images has increased. My best advice for handling responsive images is a technique I picked up for Julie Ng, the developer behind the awesome Email Development Newsletter.

Basically, you declare your image dimensions in a number of ways within your img tag. To prevent some email clients from displaying larger, retina images at their full size, you declare the width using the width attribute. This provides a good baseline width in pixels. For responsive emails, you then declare the width, max-width, and min-width of the image as inlined CSS. Here’s an example:


<img alt="Hello" src="http://example.com/image.png" width="600" style="display: block; width: 100%; max-width: 100%; min-width: 100px; font-family: sans-serif; color: #333333; font-size: 18px;" border="0">

Naturally, you’ll want to provide some ALT text for when images are disabled and declare display:block; to prevent unnecessary whitespace around the image. If you need additional control over the image, you can target it with a class and CSS in the head of your email. Just remember, embedded CSS isn’t supported everywhere.

When it comes to retina images, your best bet is to simply create your images at twice the intended display size for the image in your email. For example, if you have a 600px by 200px image, you would create and save it as a 1200px x 400px image. Include it normally in your email. The width attribute that I mentioned earlier will prevent it from displaying as an absurdly huge image in clients like Outlook and your images will look nice and crisp on devices with retina screens.

Any advice for someone looking to use animated GIFs in an email?

Go for it! Animated GIFs are a fantastic way to add movement and interest to your email campaigns. We love the technique so much we wrote up an extensive guide to using animated GIFs in email.

Just go in with the understanding that they are not supported everywhere, most notable in Microsoft Outlook, which only displays the first frame of the animation. It’s a good idea to make sure any imagery in the GIF is used for illustration purposes, not to convey vital information to subscribers. That kind of information should always be displayed as live text in the email so that subscribers can read it even when things like GIFs and images are disabled.

While a lot of people think GIFs are just for fun, a ton of product companies are using animated GIFs to show off interactions with their products and essentially teach people how to use products before they even touch them. Here’s a great example from MailChimp:

mailchimp-interface-gif

GIFs are a great addition to every email marketer’s toolbox. One word of advice would be to use them sparingly, though. If every campaign contains a bunch of GIFs, they quickly lose their sense of surprise. Use them occasionally when you really want to draw attention to a campaign or show of something cool.

What’s your take on using video in email?

Just like animated GIFs, videos can be an excellent way to grab a subscriber’s attention. Unfortunately, videos themselves have even less support across email clients. While we were once able to use a video background in an email, it was only supported in Apple Mail and Outlook for Mac.

That shouldn’t deter you from using video in tandem with email, though. People absolutely love videos and companies are increasingly using video marketing as a way to increase engagement with users. The best way to use video in email is to include a still image of the video with a play button in the email campaign that links out to a landing page. Users immediately understand that it’s a video and can view the video on the landing page.

While embedded video in email would allow for a nice user experience, our friends over at Wistia made some good points as to why landing pages are a better solution.

  • Video on a landing page can be reused elsewhere. It’s a permanent content resource.
  • Landing pages facilitate further interactions. Once you’re done watching a video in your inbox, what is there left for you to do?
  • People can more easily share videos on landing pages.

So, definitely use video in your email campaigns but, at least for now, come to terms with the fact that doesn’t mean viewing videos in an email.

Are there any responsive email frameworks you recommend?

We mentioned a few resources for building better email campaigns in the webinar, but they’re definitely worth repeating and expanding upon here.

As far as responsive email frameworks and templates go, there are a number available:

One of our favorites is our very own Slate, which includes five responsive templates for a variety of sending scenarios. Whatever option you choose, be sure to test them across email clients to make sure your subscribers aren’t in for any surprises.

View the slides & recording

We covered a lot of ground in, “Wait. What just happened to my email?” Along with identifying the most common email problems and their solutions, we touched on the importance of testing every email and even looked at how to test transactional emails with Sendwithus. If you missed it the first time, you can download the slides and view the recording below.

Views slides & recording →