Owl’s Head Solutions has been leveraging our collective design and development expertise to provide ready-to-send HTML emails to our clients for a number of years now. Along the way we’ve learned some valuable lessons about the features and limitations of HTML emails, how to smooth out the development cycle, and how to provide an accurate estimate to our clients. In this blog post we will highlight some of the best information we’ve gathered over the years to help our clients better understand what goes on behind the scenes.
What is Possible within an HTML Email?
“So tonight I’m gonna code this like it’s nineteen ninety-nine.” – OHS Development Team, 2019
When thinking about what can be accomplished with an HTML email, particularly those designed for Microsoft Outlook, it’s helpful to imagine that we’re living pre-Y2K. Modern web browsers are capable of displaying highly dynamic, interactive, and beautiful browsing experiences thanks to the power of technologies like JavaScript, HTML5, CSS3, and the sheer computing power we have access to these days. Unfortunately, email clients such as Outlook, Gmail, and Apple Mail haven’t changed much under the hood in recent decades, and therefore don’t feature these capabilities. Not only that, but they all use different software behind the scenes to render the same HTML source code in noticeably different ways. That being said, even with those limitations to contend with we can still deliver elegantly-designed HTML emails that will display reliably across a variety of platforms. Here’s a surface-level overview of what you can expect from an HTML email.
What you can Expect with an HTML Email
In essence, there’s one thing we can reliably do within the confines of an HTML email—design and develop a static, table-based, single-page newsletter. We need to use specifications of the HTML markup language (the code that dictates the structure of websites) and CSS (the code that tells web browsers how to style the HTML) from the late 1990’s that also come with an additional set of limitations and special considerations for each email client.
Since each email service has its own specifications that define which parts of HTML and CSS work with their client, you have to keep one thing in mind. As the number of platforms you want your HTML email to support increases, the number of options for what kind of content it can contain decreases. For example, animated GIFs are supported in Gmail on your web browser, but not in most versions of Microsoft Outlook. Custom web fonts won’t always work, and many CSS styles simply aren’t supported consistently or at all across various platforms.
There’s also a few things that will never work…
- JavaScript. That means no interactive web content such as submit buttons for forms, or information that continuously updates.
- Flash animations. GIFs may work sometimes, but make sure that the first frame of the GIF would be acceptable as a static image if some clients can’t animate them.
- Embedded audio or video. Links are fine, but media can’t play within the email itself.
- Inline Frames. Usually called Iframes, these would let you embed content from another website into a panel on your site. They aren’t supported on any email client.
- Most HTML5 and CSS3. These languages come with some amazing features, but most of them aren’t supported and the clients will try to render them as old-school HTML/CSS, or just ignore it entirely.
Key Takeaway: When creating HTML emails, developers are constrained by having to adhere to older technology and a strict set of limitations. Sometimes those limitations can make seemingly simple requests very difficult to implement, so it’s best to remain flexible with the minutiae.
What to Think About When Requesting an HTML Email
There are a few questions you can answer to help us come up with an accurate estimate, make it easier to understand your requirements, and reduce the likelihood of unforeseen challenges arising during the design and development process.
Which platform(s) will my email be viewed on?
We have a robust testing tool that allows us to view our emails in a few dozen different environments, and you’d be shocked at how wildly different the same code can look across different platforms. We generally prioritize support for newer versions of Microsoft Outlook, and doing so can cause some expected behavior on other popular platforms. Sometimes, there is additional code we can include to specifically target other platforms when they are being used. Media queries and Outlook conditional statements can help alleviate some display issues, but it’s best to know which platforms we need to optimize for so we can provide an accurate estimate and understand how best to approach testing.
What is the acceptable margin of error for minor display bugs?
One thing an HTML email developer has limited control over is how the source code they’ve written will be displayed across a wide variety of email clients on an even wider range of devices. It is inevitable that sometimes one element or another will be a pixel off, be spaced inconsistently, or even break entirely if it’s being viewed on a platform with a lot of quirks. We can alleviate a lot of this with specialized code optimizations specific to individual platforms, but sometimes fixing something that looks incredibly minor could take a significant amount of time due to the finicky nature of some email clients and devices. If we know ahead of time what level of precision we are targeting and which platforms to optimize for, we can avoid roadblocks during development and create a design with the intended platforms in mind.
Will the content (e.g., images and text) require edits throughout the process?
We often find that clients require edits to the copy, images, links, and so on during the development process. We always try to accommodate these requests, but being mindful of how the edits are communicated to us can make a big difference in our ability to stay within scope, time frame, and budget. For example, if many small details in a paragraph of text (e.g., capitalization, abbreviations, links, etc…) are required, it’s best to send us a list with as many changes as possible at once to keep the number of revisions and time spent on additional testing to a minimum. In general, changes to the structure and layout are difficult and should be decided as early as possible, whereas small edits to text or swapping out placeholder images for real ones are simple. It’s much quicker to do many small changes in one revision than it is to implement them one at a time.
Am I Using an Email Marketing Service Like MailChimp or Constant Contact?
Software like MailChimp and Constant Contact can be a great tool, especially for users who don’t want to delve into writing code from scratch. They both have visual editors that are intuitive and don’t require any technical skills to use. Additionally, emails created with these visual editors generally have a high degree of compatibility across a variety of platforms. The downside of these services is that—especially in the case of Constant Contact—the visual editor imposes strict limitations on what kind of design can be implemented. MailChimp does allow direct editing to the source code, but Constant Contact does not. Both options offer the ability to simply use HTML code instead of the visual editor, but there can be concerns regarding where the media content will be hosted and reusability of the same template for future emails. In general, just remember that while email marketing software can make things much easier, it also comes with a set of limitations.
Key Takeaway: Setting expectations and thinking ahead to eliminate the need for extensive revisions, going out of scope or over budget, and disappointment with the final product can prevent a lot of headaches. Even just answering the four questions listed above could save you time and money.
Learn More About the Technical Aspect of HTML Emails
Below you’ll find a list of resources that we’ve used to better understand the technical considerations for HTML emails. While most people would never need to understand the nitty gritty details, a broad understanding can assist in conveying information to clients and managing expectations. And, of course, feel free to contact us if there are any questions we can answer.
The Basics of Modern HTML Emails by Gyula Németh
How to Code Emails for Outlook 2016 by Alex Ilhan
Why is Email Rendering So Complex? By Chad S. White