Email, the web’s much maligned little cousin, is in the midst of a revolution—one that will change not only how designers and developers build HTML email campaigns, but also the way in which subscribers interact with those campaigns.
Despite the slowness of email client vendors to update their rendering engines, email designers are developing new ways of bringing commonplace techniques on the web to the inbox. Effects like animation and interactivity are increasingly used by developers to pull off campaigns once thought impossible. And, for anyone coming from the world of the web, there are more tools, templates, and frameworks than ever to make that transition as smooth as possible. For seasoned email developers, these tools can decrease email production times and increase the reliability and efficacy of email campaigns.
Perhaps more importantly, the email industry itself is in a state of reinvention. For the first time, email client vendors—traditionally hesitant to update or change their rendering engines—are listening to the concerns of email professionals. While progress is likely to be slow, there is finally hope for improved support for HTML and CSS in the inbox.
Although some problems still need to be addressed, there has never been a better time to take email seriously. For a channel that nearly every business uses, and that most consumers can’t live without, these changes signal an important shift in a thriving industry—one that designers, developers, and strategists for the web should start paying attention to.
Let’s look at how these changes are manifesting themselves.
The web comes to email#section2
It’s an old saw that email design is stuck in the past. For the longest time, developers have been forced to revisit coding techniques that were dated even back in the early 2000s if they wanted to build an HTML email campaign. Locked into table-based layouts and reliant on inline styles, most developers refused to believe that email could do anything more than look serviceable and deliver some basic content to subscribers.
For a few email developers, though, frustrating constraints became inspiring challenges and the catalyst for a variety of paradigm-shifting techniques.
When I last wrote about email for A List Apart, most people were just discovering responsive email design. Practices that were common on the web—the use of fluid grids, fluid images, and media queries—were still brand new to the world of email marketing. However, the limitations of some email clients forced developers to completely rethink responsive email.
Until recently, Gmail refused to support media queries (and most embedded styles), leaving well-designed, responsive campaigns looking disastrous in mobile Gmail apps. While their recently announced update to support responsive emails is a huge step forward for the community, the pioneering efforts of frustrated email developers shouldn’t go unnoticed.
Building on the work first introduced by MailChimp’s Fabio Carneiro, people like Mike Ragan and Nicole Merlin developed a set of techniques typically called hybrid coding. Instead of relying on media queries to trigger states, hybrid emails are fluid by default, leaving behind fixed pixels for percentage-based tables. These fluid tables are then constrained to appropriate sizes on desktop with the CSS max-width property and conditional ghost tables for Microsoft Outlook, which doesn’t support max-width. Combined with Julie Ng’s responsive-by-default images, hybrid coding is an effective way for email developers to build campaigns that work well across nearly every popular email client.
<img alt="" src="" width="600" style="display: block; width: 100%; max-width: 100%; min-width: 100px; font-family: sans-serif; color: #000000; font-size: 24px; border="0";" />More recently, two other methods have emerged that address the issues with mobile email using more advanced techniques. Both Rémi Parmentier’s Fab Four technique and Stig Morten Myre’s mobile-first approach take the concept of mobile-first development so common on the web and apply it to email. Instead of relying on percentage-based fluid tables, both techniques take advantage of the CSS calc function to determine table and table cell widths, allowing for more adaptable emails across a wide range of clients. And, in both cases, developers can largely drop the use of tables in their markup (save for Microsoft ghost tables), creating emails that hew closer to modern web markup.
Moving beyond responsive layouts, email designers are increasingly adding animation and interactivity to their campaigns, creating more engaging experiences for subscribers. Animated GIFs have long been a staple of email design, but CSS animations are becoming more prevalent. Basic transitions and stylistic flourishes like Email Weekly’s heart animation (scroll down) or Nest’s color-shifting background colors are relatively easy to implement, fall back gracefully when not supported, and give email designers more options to surprise and delight their audiences.
Combined with the checkbox hack and Mark Robbins’s punched card coding, CSS animations allow email developers to create highly interactive experiences for the inbox. While earlier examples of interactivity were reserved for elements like product carousels, people like Robbins and the Rebelmail team have started creating full-blown checkout experiences right in an email.
Interactivity doesn’t have to be reserved for viewing retail products, though. At Litmus, animations and interactivity were used to provide a full product tour inside of an email.
In this case, interactivity was used to provide product education, allowing users to experience a product before they even got their hands on it. While similar educational effects have been achieved in the past with animated GIFs, the addition of truly interactive elements created an experience that elevated it above similar campaigns.
Finally, the web’s focus on accessibility is cropping up in email, too. Both table-based layouts and inconsistencies in support for semantic elements across email clients have contributed to a near-complete lack of accessibility for email campaigns. Advocates are now speaking out and helping to change the way developers build emails with accessibility in mind.
The use of role=presentation on tables in email is becoming more widespread. By including role=presentation on table elements, screen readers recognize that those tables are used for layout instead of presenting tabular data and skip right to the content of the campaign.
Developers are also embracing semantic elements like proper headings and paragraphs to provide added value for people with visual impairments. So long as you are careful to override default margins on semantic, block-level elements, designers can safely use those elements without worrying about broken layouts. It is now something that every email developer should be doing.
Combined with email’s focus on alternative text—widely used to combat email clients that disable images for security reasons—accessible tables and semantic elements are laying the foundation for more usable, accessible email campaigns. There’s still a huge amount of research and education needed around accessibility in email, but the email world is slowly catching up to that of the web.
All of these techniques, mostly commonplace on the web, are relatively new to the world of HTML email. Somes have been used on a limited scale, but they are on the verge of becoming mainstream. And, while animation and interactivity aren’t appropriate for every email campaign, they are valuable additions to the email toolbox. Taken together, they represent a massive shift in how developers and marketers approach HTML email and are changing the way subscribers think about the humble inbox.
Better tooling#section3
If anything can be considered a constant on the web, it’s that web designers and developers love building tools and frameworks to (in theory) improve their workflows and the reliability of their code. Just like accessibility and interactivity, this focus on tooling and frameworks has been making its way into the email industry over the past few years.
Instead of relying on individual, locally saved, static HTML files, many email developers are now embracing not only GitHub to host and share code, but complete build systems to compile that code, as well. Tools like Grunt and Gulp are now in wider use, as are static site generators like Middleman.
Being able to focus on discrete components means developers no longer have to update multiple HTML files when managing large email programs. For teams in charge of dozens, if not hundreds, of different email templates, this is a godsend. Updating a logo in one place and having it propagate across different campaigns, for example, saves tons of time.
The use of build tools also opens up the possibility of hyperpersonalized campaigns: emails with custom content and custom layouts on a per-subscriber basis. Allowing build systems to handle the compilation of individual modules means that those modules can be pieced together in a virtually unlimited number of ways based on conditions set at the beginning of the build process. This moves personalization in email beyond basic name substitutions and gives email marketers an unbelievably powerful way to connect with subscribers and provide way more value than your typical “batch and blast” campaign.
Likewise, more email developers are relying on preprocessors like Sass and Less to speed up the development workflow. Controlling styles through variables, mixins, and logic can be extremely powerful. While CSS post processors aren’t in wide use, a few savvy email developers are now starting to take advantage of upcoming CSS features in their campaigns.
Email developers and designers working with smaller teams, or those less familiar with advanced tools like preprocessors and build tools, now have a plethora of HTML email templates and frameworks at their disposal. They range in complexity from simple, static HTML files that make customization easy to completely abstracted coding frameworks like MJML and Zurb’s Foundation for Emails 2. Both MJML and Foundation for Emails 2 introduce their own templating languages, allowing email developers to use markup closer to that found on the web, which is then compiled into more complex, table-based HTML.
<mjml>
<mj-body>
<mj-container>
<mj-section>
<mj-column>
<mj-text>Hello World!</mj-text>
</mj-column>
</mj-section>
</mj-container>
</mj-body>
</mjml>One area that still needs improvement is testing. While tools like Litmus have vastly improved the experience of testing static emails across clients, interactive emails present new challenges. Since testing services currently return static screenshots taken from the inbox, access to devices is crucial for teams working on interactive campaigns. Although a few people are coming up with novel approaches to testing interactive emails (most notably Cyrill Gross’s use of WebKit browsers and clever JavaScript), tooling around interactive email testing will need to improve for more email developers to adopt some of the techniques I describe here.
A seat at the table#section4
Two of the most exciting developments in the email world are the recent Microsoft and Litmus partnership and Gmail’s announcement of support for media queries.
Due to their typically abysmal support for HTML and CSS (especially the box model and floats), the many variations of Outlook have long been the biggest thorn in email developers’ sides. Outlook is the primary reason that emails use tables for layout.
Now, though, for the first time, Microsoft is reaching out to the email community to document bugs and rendering problems in order to guide future development efforts and improve the rendering engines underpinning their email clients. While we’ll still have to rely on tables for the foreseeable future, this is a good indicator that the email community is moving closer to some form of standards, similar to the web in the early 2000s. I don’t think we’ll ever see standards as widely propagated across email clients as they are on the web, but this is the first step toward better HTML and CSS support for email developers.
One likely result of the Microsoft/Litmus partnership is that more email client vendors will open up lines of communication with the email design industry. With any luck, and a lot of work, Microsoft will be the first of many vendors to sit down at the table with email designers, developers, and marketers in order to improve things not only for email professionals, but also for the subscribers we serve. There are already signs that things are getting better beyond Microsoft’s promise to improve.
Gmail, one of the more problematic email clients, recently updated their rendering engine to support display: none;—an unprecedented move from a team that is historically unsympathetic to the concerns of the email community. Email developers were in for an even bigger surprise from the Gmail team when they announced that they will be supporting media queries and embedded styles, too. While the hybrid coding approach mentioned earlier is still useful for addressing some email clients, this change means that it is now easier than ever to apply the principles of responsive web design—fluid grids, fluid images, and media queries—to HTML email campaigns.
Perhaps more interesting is Gmail’s added support for embedded CSS and element, class, and ID selectors. With this one change, embedded styles will be nearly universally supported—meaning that email designers will no longer be bound to inline styles and all the headaches they bring. Emails will now be easier to design, develop, and maintain. The lighter code base and more familiar style of writing CSS means that many of the blockers for web developers taking email seriously will be removed.
Beyond rallying around improved support for HTML and CSS, the email community itself is thriving. I remember the dark days—really only a few years ago—of email design, when it was extraordinarily difficult to find reliable information about how to build email campaigns, let alone connect with others doing the same. Today, people interested in email have a large and growing community to turn to for help. More marketers, designers, and developers are sharing their work and opinions, contributing to a discourse that is helping to shape the industry in new and interesting ways.
Perhaps more importantly, designers and developers are beginning to understand that working with email is a viable career option. Instead of relegating email to one more task as a web dev, many are now taking up the mantle of the full-time email developer.
Now’s the time#section5
Where once there was just darkness and Dreamweaver, the email world is brightening with the light of a growing community, better tools, and amazing techniques to animate a traditionally static medium. And, with the increasing support of email client vendors, we can finally see the flicker of email standards way off on the horizon.
While some folks have expressed emotions ranging from amusement to scorn when discussing email marketing, no one can take it for granted anymore. Subscribers love email, even if you don’t. Email is routinely the most effective digital marketing channel. Companies and teams need to embrace that fact and take email seriously. Fortunately, now’s the perfect time to do that. Never have there been more tools, resources, and people dedicated to making email better.
The revolution in email is bound to be a slow one, but make no mistake: it’s coming. The web is leaking into the inbox. If you can’t keep up, your campaigns (and you) will be left behind.
As a web developer who uses email alerts, workflows, and whose thousands of customers are locked into high security models, I’d like to dash some cold water on this view of a brave new world.
Email (phishing, spearphishing, whaling, etc) is the largest security hole in the enterprise. Press email software providers to help fix that problem before you develop better ways to market to people using email (a practice for better or worse regarded by most people as ‘spam’).
Millions of customers in the enterprise have email restricted to text-only, so make sure your opt-in includes that option, and (increasingly I find this to be a problem) enforce a true text-only email result if the customer selects that option. I cannot count the number of ‘text-only’ emails I receive which are 90% tags and 10% text, buried under a heap of markup.
You may be delighted to be able to present a beautiful, code-heavy marketing presentation to Jane Officeworker in their inbox. But if that mysterious interactive code (jQuery or whatever) doesn’t slide by the security protocols it will be removed. If the recipient responds to this sales pitch during office hours, they might be tagged by monitoring software. If the recipient has ever suffered a phishing attack, they will probably flag your email and your domain will be routinely blocked for sending active code in email.
Stanistani, you’re absolutely right that email can be a huge security risk and many enterprise subscribers have their inboxes locked down. Email security should definitely be a focus for every email provider.
But to clarify, this article is largely geared towards marketing to consumers via email. While considered spam by many, it’s an absurdly valuable marketing channel that is preferred over other channels by most consumers. It’s a channel that drives huge business for some of the biggest companies in the world.
The techniques and tools described above give email marketers, designers, and developers the ability to set their email programs apart, in order to provide a more interesting, valuable experience to their subscribers. The techniques might not be for every sender, but I see more and more email marketers using them to great effect.
And to be fair, none of the techniques described above rely on JavaScript or jQuery (which is rightly stripped out by most email clients). They use HTML and CSS to add interactivity in email clients that support it, with graceful and usable fallbacks for those that don’t.
Nice article thanks for sharing. Stanistani said “Email (phishing, spearphishing, whaling, etc) is the largest security hole in the enterprise.” In my humble opinion people are the largest security hole. 🙂
With so many new forms of messaging available it only seems inevitable that email would eventually catch up to the innovations we’ve seen from these new platforms. It’s possible that email could fade away if it doesn’t keep up, but with the sheer amount of people who still actively use email today it doesn’t seem like that will be any time soon.
Today people get so many e-mails and to create new customers it is to important to be different and use new methods. Thanks for sharing this usefull post about the e-mail design. I think the rebelmail goes in the right direction, I try to implement it for my page http://www.praktischarzt.de – lets see if I can create more direct dynamic interactions with new customers.
Well, there are two major enemies to security: complexity, and convenience. Introduce either to E-Mail, and you’ll get a lack of security (and privacy, too) in return. And HTML introduces both of them.
For those of us who can’t live without the web in the inbox, willing to shell out tons of bitcoins for the ransomware they’re inviting, ok, there you go.
For me: no thanks.
Just my two cents.
Michael from Germany
Hello,
This article most usefull for me . So Thanks For the sharing this artilce related to The Coming Revolution in Email Design
Yes very interesting post about this design. Thanks for this sharing but what about security? I heard that could be an hole
Given the choice, I choose plain text.
I have my email client configured to show plain text even in the presence of HTML (given multipart/alternative); I just wish that it would handle HTML-only via a plain text approximation.
If I want a web page, I have a web browser for that.
So yes, do check that your mail is readable as plain text, and do make sure that the URLs are present and don’t run into following text…
Nice article thanks for sharing. Some interesting points mentioned here good job.
Or — code as a table, max 600 pix wide, the way email html likes to be. Make each “cell” into an embedded table. The table “cells” will line up vertically in the order entered – you can have two or more on a row if you would like. Max width of each table/cell is 280 pixels. This accommodates the tendency of images to just TAKE the room they need no matter what width is entered in the table cell or the table itself. Make the images 280 pixels and they will fit into the older, smaller phones. 280 image, paragraph text 280 wide can have 10px padding and 10px margin, therefore it doesn’t smack against the sides or each column when viewed on a desktop instead of a phone. And the lack of border-box capability means 280 + 10 + 10 + 10 +10 = 320px – the width of portrait view of the older iPhone which some people are still using.
A bit of a pain, but it works. Works on my old iPhone 4s, passed all the Litmus test, works on everything.
I was freelancing for Staples before I got this gig and they were trying to figure out how to make responsive email. Others made the images and the design decisions — I’m not taking credit for those. But “responsive tables in old school code” that’s all me. I sent them to myself and to managers through the Salesforce interface and also tested them in Litmus’ free tool, putmail, as well as on my collection of old phones n things.
http://www.wendy-walsh.com/email-mobile-coffee-vid-testedit.html
http://www.wendy-walsh.com/email-mobile-newsletter-testedit.html
Feel free to use and re-use the source code for these. It will always work. I do agree that email should be less dependent on images. These are pretty image-heavy. They were sent only to people who specifically requested them as part of the Staples rewards program.
It has always amazed me that google, that monster of the internet, does not send out responsive emails from its spam blocking services. They are sent in html, in a table where the 3rd column, the one holding the long description of the email, is about 4 characters wide. This leading to emails that scroll for ever as each entry is several screens deep with loads of blank space.
Email design is playing key role to attractive customers and it has potential for marketing. I am working as email marketer at http://www.webilogics.com/ and using same technique that you has mentioned in the article. thanks good stuff
Great article on email design! A revolution in email design is something I think many design agencies have been waiting for. We started using email campaigns over 15 years ago to grow our agency and we were adding interactive elements back then using Flash. So having interactive emails would be something that’s not only welcomed but long over due.
Great article. I would choose plain text if I have to. Beside that, email security is one of the problem to consider too. I also agree with the idea that rebelmail has gone in the right direction. I tried it with my website and I have created more interactions with new customers.
Great information on the Revolution in Email Design. I will implement this on my site soon.
Thanks a lot!!
Just started a new website dealing with foot care. I am planning to implement this on the website as soon as its done.