But email editors are woefully behind. Here’s why…
Designing HTML Emails Is Far More Complex Than For A Website
If your company wants a beautiful HTML email designed, the process is exponentially more complex than building out a web page for several reasons:
- No Standards – There is NO strict adherence to web standards by email clients that display HTML email. Virtually every email client and every version of every email client acts differently. Some will honor CSS, external fonts, and modern HTML. Others honor some inline styling, only display a collection of fonts, and ignore everything but table-driven structures. It’s quite ridiculous that no one is working on this issue. As a result, designing templates that render across clients and devices consistently has become big business and can be quite expensive.
- Email Client Security – Recently, Apple Mail updated to block all images in HTML emails by default that are not embedded in the email. You either give permission to load them an email at a time or have to enable the settings to disable this setting. Along with email client security settings, there are also corporate settings.
- IT Security – Your IT team may deploy strict rulesets on what objects can actually be rendered in an email. If your images, for example, come from a specific domain that’s not whitelisted in a corporate firewall, images simply won’t show up in your email. At times, we’ve had to develop emails and host all the images on the corporation’s server so that their own employees could see the images.
- Email Service Providers – To make matters worse, the email builders that email service providers (ESPs) actually introduce problems rather than constrain them. While they promote their editor is What You See Is What You Get (WYSIWYG), the opposite is often true with email design. You’ll preview the email in their platform, and the recipient will see all the design problems. Companies often unknowingly opt for a feature-rich editor instead of a locked-down one, thinking one has more features. The opposite is true… if you want emails that render consistently across all email clients, the simpler, the better, because less can go wrong.
- Email Client Rendering – Hundreds of email clients render HTML differently across desktops, apps, mobile devices, and webmail clients. While your nifty text editor on your email service provider may have a setting to put a heading in your email, the padding, margins, line height, and font size may differ for every email client. As a result, you have to dumb down the HTML and code every single element differently (see the example below) – and often write in exceptions that are email client-specific – to get an email to render consistently. There’s no simple block types, you have to do table-driven layouts that are the equivalent of building for the web thirty years ago. It’s why any new layout requires both development and cross-email client and device testing. What you see in your inbox may be totally different what I see in my inbox. That’s why rendering tools like Email On Acid or Litmus are a must to ensure your new designs work across all email clients. Here’s a short list of popular email clients and their rendering engines:
- Apple Mail, Outlook for Mac, Android Mail and iOS Mail use WebKit.
- Outlook 2000, 2002 and 2003 use Internet Explorer.
- Outlook 2007, 2010 and 2013 use Microsoft Word (yes, Word!).
- Webmail clients use their browser’s respective engine (for example, Safari uses WebKit and Chrome uses Blink).
An Example of HTML for Web Vs. Email
If you want an example that illustrates the complexity of designing in email versus the web, here’s a perfect example from Mailbakery’s article 19 Big Differences Between Email and Web HTML:
We must build a series of tables incorporating all the inline styling necessary to place the button properly and ensure it looks good across email clients. An accompanying style tag will also be at the top of this email to incorporate the classes.
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<table border="0" cellspacing="0" cellpadding="0" bgcolor="#43756e">
<td class="text-button" style="padding: 5px 20px; color:#ffffff; font-family: 'Oswald', Arial, sans-serif; font-size:14px; line-height:20px; text-align:center; text-transform:uppercase;">
<a href="#" target="_blank" class="link-white" style="color:#ffffff; text-decoration:none"><span class="link-white" style="color:#ffffff; text-decoration:none">Find Out More</a>
We can utilize an external stylesheet with classes to define the case, alignment, color, and size of an anchor tag that appears as a button.
<a href="#" class="button">Find Out More</a>
How to Avoid Email Design Issues
Email design issues can be avoided by following a decent process:
- Template Testing – Understanding the email clients your subscribers utilize and ensuring that your HTML email is fully tested across mobile and desktop is critical before deploying any template. We can design an email literally from a Photoshop layout… but slicing and dicing it into a table-driven, cross-email client is essential to deploying email designs that are optimal and consistent.
- Internal Testing – Once your template is designed and tested, it should be sent to an internal seed list within the organization to review and approve. You may even want to start with a very limited subset of individuals to first ensure there aren’t firewall or security issues associated with rendering the email internally. If this is building out an instance on a new email service provider, you may even find some filtering or blocking issues associated with even getting your email to the inbox.
- Template Versioning – Don’t change your layouts or designs without working on a new version of your template that can be designed, properly tested, and deployed. Many businesses love one-off designs for every campaign… but that requires every email be designed, developed, and deployed for each campaign. This adds a ton of time to the email marketing process internal. And, you risk not understanding what elements in your email are performing well over what elements are not. Consistency isn’t just a way to make the process easier, it’s also important to the behavior of your subscribers.
- Email Service Provider Exceptions – Virtually every email service provider has a means of working around the issues that their email builder introduces. We can often add raw CSS to an account – or even have a content block that has to be included in every email – in order for the company to utilize the built-in email editor and not have it break the design of your email. Of course, that may require some training and process control to deploy those steps to ensure they’re complied with. Or – you may literally just want to develop your email design in a solution that is proven to work across clients and devices, then paste it back into your email service provider.
Email Design Platforms
Because email service platforms have done a poor job at building out and maintaining cross-client and cross-device consistently rendered builders, a number of great platforms have come to market. One that we’ve used extensively is Stripo.
Stripo is not just an email builder, they also have a library of over 900 templates that can be easily imported. Once you design the email, you can the email to 60+ ESPs, and email clients, including Intuit Mailchimp, HubSpot, Campaign Monitor, AWeber, eSputnik, Outlook, and Gmail. Best of all Stripo templates come with the email rendering tests included so you can ensure they’ve been tested and work consistently across over 40 email clients.