Where Should You Focus Your Testing Efforts?0
Between buggy support for HTML and CSS, spelling errors, bad links, missing images, and other potential blunders, it’s crucial to test your email campaigns before every single send. But, where should you focus your testing efforts? With so many email apps available (not to mention the different versions of each), it’s easy to feel overwhelmed trying to test every possible combination.
While there is general email client open data available, it’s your audience that matters. Sure, nearly 30% of worldwide opens occur on iPhones, but if your subscribers aren’t using iPhones, then why worry about it? Looking at open data for your audience is the key to narrowing down where you should be focusing your testing efforts.
DISCOVERING YOUR AUDIENCE
With the addition of a small tracking code to your campaigns, Email Analytics generates a report of where your subscribers open your emails—including the specific versions of each program and app. You’ll also receive operating system and browser reports—both of which provide helpful data in consolidating your testing efforts (we’ll get to this part later!).
We recommend looking at the top 10-15 most popular programs and apps with your audience (or your client’s audience) and focusing on delivering a great experience in those environments. This enables you to ensure that your emails look great for most of your audience, all while saving you time and resources by focusing your testing efforts where it matters. It’s also important to track your Email Analytics data after every send, so you can note trends and react to any changes in your subscribers’ open data.
FOCUSING YOUR TESTING EFFORTS
Once you identify your audience’s favorite email clients, it’s time to take a look at some of the known issues with each client. Understanding how email clients render HTML is a vital step in fine-tuning both your email campaigns and your testing process.
While there are scores of desktop clients, the most popular worldwide are the various versions of Microsoft Outlook, Lotus Notes, Apple Mail, and Mozilla Thunderbird. By understanding how they display emails, and identifying similarities and differences between rendering engines, you can save yourself a lot of testing time.
Early versions of Outlook
Outlook 2000-2003 use Internet Explorer to render email. As a result, you can group these together when testing since they will render very similarly. These clients block images by default, and have limited support for ALT text (although no support for styled ALT text) so be sure to include descriptions for your images. In addition, forms and HTML5 video will display, but won’t work; while animated GIFs are fully supported.
Contrary to early versions of Outlook using IE to render, Outlook 2007-2013 uses Microsoft Word as a rendering engine (yes, a word processor is used to render HTML). It has extremely poor support for CSS, including:
- No support for background images in divs and table cells
- No support for CSS float or position
- No support for text shadow
- Poor support for padding and margin
- Poor support for CSS width and height
While it blocks images by default, it does support ALT text (but not styled ALT text). In addition, while HTML5 video’s fallback and the first frame of an animated GIF will display, neither will actually play.
Thunderbird, Apple Mail + Outlook for Mac
While Thunderbird uses Gecko as a rendering engine, Apple Mail and Outlook for Mac use WebKit. However, both Gecko and WebKit have excellent support for HTML and CSS, so you can group these clients together when testing.
These clients support animated GIFs, background images, HTML5 video, and Web fonts. However, one difference to note is that while Outlook for Mac disables images by default, Apple Mail and Thunderbird will automatically display images, unless a subscriber manually disables images in their preference settings.
Lotus Notes 6.5–9 can use either Internet Explorer or Notes Rich Text to render, to sometimes disastrous results. Since compensating for rendering problems in Notes can lead to problems elsewhere, we don’t recommend testing in this client unless you have the data to justify the associated headaches. Less than 0.5% of opens occur in Lotus Notes worldwide, but pockets of devoted users still exist. If you’re seeing a lot of opens in Notes, be sure to inline your CSS whenever possible, reset layout style rules (such as padding and margin), and use table-based layouts.
Free services like AOL Mail, Gmail, Outlook.com, and Yahoo Mail combined with email services provided by cable and internet companies (like Comcast) create endless opportunities to check email in a web browser. Rendering for webmail email is dependent on two factors: the preprocessor and the browser the email is opened in.
Once the preprocessor has done its job, the HTML is passed along to the browser, which acts as the rendering engine. Popular browsers include Internet Explorer, Firefox, Chrome, and Safari. Chrome and Safari use variations of WebKit as a rendering engine, while Internet Explorer uses Trident and Firefox uses Gecko.
As stated in the desktop rendering section, Gecko and WebKit have great support for CSS, which means that emails opened in Firefox, Chrome, and Safari will render nearly identically. The latest versions of Internet Explorer also have good support for CSS.
However, you’ll still want to test your emails in a variety of browsers (don’t worry, Litmus offers webmail testing in Chrome, Internet Explorer, and Firefox!), since things like image blocking behaviors, ALT text, and alignment can vary from browser to browser.
Mobile rendering is extremely complex, as there are literally dozens of ways to view an email on any given mobile device. Differences between manufacturers, operating systems, screen sizes, and email apps all play a role in rendering when it comes to smartphones and tablets. Needless to say, there is a lot to consider!
Android, BlackBerry, and iOS use WebKit to render
Android, BlackBerry, and iOS (iPhone and iPad) devices all use WebKit as their rendering engine. As stated previously, WebKit has great support for HTML and CSS and isn’t likely to cause email designers any headaches. However, when it comes to mobile there are some things to be aware of.
Like webmail rendering, mobile clients use a preprocessor to remove anything “risky” before passing the HTML onto the phone’s browser to render. Each email application on the phone then “borrows” WebKit to render the email—even if the email is not being read in the browser itself (rather, it could be read in an email app instead).
So, even though all of the major mobile devices use the same rendering engine, differences in preprocessors and behaviors between email apps can cause rendering discrepancies (even with email apps on the same device!). For example, while the Gmail app on Android doesn’t support media queries (the foundation of responsive emails), some other email apps for Android have full support for responsive elements. How’s that for confusing?
There are also subtle differences between each devices’ implementation of WebKit. For example, Android may use a different style on a button than iOS.
Windows Phone uses Internet Explorer to render
While Windows Phone also uses a preprocessor, it uses Internet Explorer rather than WebKit to render code. While the newest versions of Internet Explorer render similarly to WebKit, there will still be some differences.
So, what do you do?
Needless to say, mobile rendering is complex. There are numerous ways that a subscriber could view your email. And, even when devices or email apps use the same rendering engine, emails could still display differently.
When it comes to mobile, discovering which clients and apps your subscribers are using is imperative to save you time and resources. If your audience is anything like the general population, you’ll definitely want to test on the native email app for iPhone, as well as the email and Gmail apps for Android.
START SAVING TIME AND RESOURCES
Don’t waste your valued time and resources focusing on email clients that your subscribers aren’t even using. Use Email Analytics to discover where your emails are being opened and start focusing your testing efforts.
New and existing customers have unlimited Email Analytics access until February 28th.