Posted on July 7, 2015
In a recent blog, we gave you 6 ways to create inbox-friendly HTML emails and make them more clickable. We touched upon the frustrating reality that the emails we beautifully design, code and send are not going to look the same when viewed on the many different email clients out there.
Today, we’re going to talk you through why that is.
What happens to an email?
From the moment you press ‘send’ on an email to the time it appears on your recipient’s device, a lot happens along the way. How the HTML email ends up looking ultimately depends on two separate spheres of influence: the preprocessor and the web browser.
‘Preprocessing’ is what happens when the email client (the computer program used to access and manage emails e.g. Outlook) takes a good look at an email’s contents and makes sure everything’s in order. It needs to check that there’s no malicious code hidden away and that it understands all the HTML it’s being asked to process.
Preprocessors are usually quite strict. If it thinks any of the email’s coding is going to compromise the functionality or security of the email client in any way, it will just remove it. Web-based email clients are even keener to remove and ignore some of the HTML code placed in emails, even if it’s perfectly valid.
It boils down to a battle of wills: the web-based email client and the email itself may both be using the same code to describe how it should appear. This inevitably means conflict.
Once the preprocessor has decided what code to process, it hands it over to the rendering engine which forms part of your web browser or email client. Its job is to read the HTML code that’s made it through the preprocessing stage and dictate, finally, how it should be displayed.
The challenge of endless variability
Here are some of the main web browsers on the market today, the rendering engines they use and the company responsible for each one:
Software Rendering Engine Company
Internet Explorer Trident Microsoft
Firefox Gecko Mozilla
Safari WebKit Apple
Chrome Blink Google
Looking at that list, things don’t seem quite so bad. Four different rendering engines? That’s not so many.
But the variability doesn’t stop there. Once we’ve taken into account the potential rendering engine, we then have to consider the operating system the software is running on – Windows, OSX, iOS and Android, just to name a few. We also have to consider the platform’s version. Is it Windows XP, Windows Vista, Windows 8, or the new Windows 10? Earlier versions are still in plentiful use out in the real world because people can’t necessarily upgrade if they have older hardware.
Then there are the desktop email clients. How many versions of Outlook are still in use today? Just a quick check of some of our recent email campaigns show that Outlook 2003 and Outlook 2007 is still in use and fairly popular.
Outlook on Windows is also famously troublesome for using an entirely different rendering engine and not the inbuilt Internet Explorer Trident engine. To be blunt, it’s not great, and a constant source of irritation for email designers and coders.
What we end up with, then, is not just web browsers and email clients to code for. We’re faced with a combination of different operating systems and different versions of the same software, all of which are using different rendering engines.
This means that unless you and your email recipient have identical machines running identical software, the end results are going to be different; sometimes imperceptibly, sometimes noticeably.
This all sounds incredibly depressing. While web browsers are mostly getting better at staying up-to-date and following web standards, email clients look as if they’re dragging far behind.
So what can we do?
The good news is that the majority of mobiles and tablets are pretty good at processing and displaying HTML emails. If we take a look at our delivery statistics, about 50% of our audience is going to receive something that looks as we intended, and if we code them appropriately, they’ll be mobile friendly and engaging whichever device they’re viewed on.
Desktop applications usually fall into two camps: Outlook or Apple Mail. The latter is very good at displaying content, and while Outlook, as discussed, is a mixed bag, we can often code around its issues.
Web-based email clients too are usually not too bad. They have their own idiosyncrasies that seem to change on an almost daily basis, but by keeping abreast of developments via the many coding blogs online, we can try and avoid the major pitfalls.
But rather than leave it to chance, the most effective way we can combat the challenge of emails not displaying how we’d like them to is to test. Tools like Litmus and Email on Acid allow us to test our emails across the range of the most popular platforms. If it doesn’t look right, we can change it, before we hit send.
We won’t ever have a perfect email on every single screen, but we can check to see that most emails will arrive in good shape. If it’s readable and contains some great content, chances are your important call-to-action will be read and, hopefully, responded to. And that’s what we’re after, after all.