Responsive Web Design, Part 2 (2015)
Responsive Email Design
BY FABIO CARNEIRO
Explaining email design and development to someone whose primary gig is web design is always an uphill battle, because the majority of web designers already have some sort of idea what it is; many have experience working in the medium, and just about every single one of them I’ve spoken with hates it. To your average web designer, the idea of having to tangle with email design makes them feel very much like the guy in that nice little illustration—stuck on a boat, in a storm, with only a shark for company.
There are some common attitudes web designers have when you ask them about HTML email, and dislike is generally the most common. There’s also confusion, and apathy, and — well, you get the picture. They’re mostly negative. I’ve had the conversation about what email design is thousands of times and, almost always, web designers say something I don’t believe is true in the least: “Yeah, email design really sucks.” That’s a tough place to start talking about a particular discipline, regardless of what it might be.
This issue of perception is one of the larger problems in this arena: many web designers think email design is just like web design, but more wrong. More than once, I’ve heard people say that the practice of designing and developing email essentially consists of throwing modern web design skills and knowledge out the window. But the truth is that designing and developing for email is not about forgetting what you’ve learned as a web designer; email design is about learning a new set of skills, and working in a medium that shares some commonality with traditional web design, but is altogether different.
So, yeah, as a general rule, I don’t think email design sucks, but I understand why people think it’s some sort of hellish venture. HTML email and a lot of the techniques, technologies, and the industry grown up around it are, in many ways, stuck in the past. For a long time, email was solely the domain of marketers, and things like good design, rewarding user experience, and well-defined content strategy were only considered useful when they were done in service to the almighty principle of ROI. Unfortunately, the perception that commercial email is only about making the largest amount of money with the smallest amount of investment is one that has largely stuck around to this day. It’s a state that’s analogous to web design back in the mid-2000s, when having a beautiful, usable website was seen more as an isolated, artistic practice. But that was then.
Today, email design is going through an evolution that looks a lot like the one we experienced in modern web design, where design, user experience, content strategy and simple creativity all matter. Also like modern web design, there’s a lot of great, forward-looking innovation going on in the email design world.
And that sums up email design as a discipline: a complicated meshing of old and new. It requires the web designer to once again think in <table>s versus <div>s for layout structure, with all of its limitations and pitfalls, but also involves using modern user experience, content strategy, and design practices to create a great finished product.
If that sounds like a major dichotomy, well, that’s because it is. The cool part is that this melding of techniques is absolutely possible. You just need to get the lay of the land before you start.
We’ve Been Here Before
This is where much of the difficulty inherent in HTML email development starts to become apparent, because the world of email design in 2014 looks a lot like the world of web design did back in the mid-to-late 1990s and early 2000s, when the browser wars were at their peak and web standards was still in its infancy.
Back then, major web browsers like Mosaic, Netscape Navigator, Internet Explorer and Opera (later joined by Firefox, Safari and, finally, Chrome) all allowed users to visit the same World Wide Web, but each worked in a slightly different way and produced a slightly different result in the rendered webpage. Although the HTML 2 spec came on the scene in 1995, followed by 3.2 in January 1997, and 4.0 in December 1997, it took a number of years for web standards to gain any traction, and even longer for the big players in the browser arena to get their products rendering sites according to those newly emerged guidelines. Nowadays, I think it’s fair to say that the web design playing field is pretty level; browsers all have good parity with each other and, in cases when they don’t, trusty languages like JavaScript are there to bridge any remaining gaps.
None of that ever really happened in the world of email. At least not at the same pace. There are dozens upon dozens of different email clients scattered across multiple platforms — far more than there were browsers — and the rendering engines or code sanitizers of the most popular clients haven’t evolved much over time; many are still working the same way they did back when using <marquee> was cool. There’s a lot of catching up to do, and there are three major schools of thought around the question of standards for email and how the industry should move forward.
First, there’s the old-old-school: that email shouldn’t be HTML at all; that an email was never meant to be anything more than a plain text message, and that email, as a whole, isn’t a part of the web and shouldn’t be treated as such. This argument is made a lot by the extremely security-conscious, but it isn’t realistic. That saying that once the genie’s out of the bottle, there’s no putting it back in is very fitting in this case, and it’s abundantly clear that the genie is definitely out of the bottle; a rough estimate via Cisco’s Senderbase1 (which tracks web and email traffic worldwide) shows that there were 432 billion legitimate emails sent worldwide in 2014. That number balloons to 3,034.4 billion if you include spam, which accounts for around 85% of the world’s volume of email (spam is, unfortunately, an industry unto itself). Every year, the amount of email sent grows by leaps and bounds; MailChimp, for example, sent 34 billion, 70 billion, and 100.5 billion emails in 2012, 2013 and 2014 respectively. Beyond that, you can look to the massive industry that’s grown up around creating and sending email, and at the largest email senders like Amazon and Google, to understand that HTML email isn’t going anywhere.
The second school of thought has been around since as recently as late 2014, and is centered around the idea that email should have its very own standard, distinct from web standards, and complete (some argue) with its own markup language, scripting libraries, the works. The thinking here is that the creation of email standards and a dedicated email markup language will formalize email, push the companies behind email clients to modernize and maintain a healthy ecosystem for email, and move the industry forward. But there isn’t particularly strong support for this idea, and making it happen would require a concerted effort by a staggering number of companies and people. Given how slowly standards bodies tend to move, it would take at least a decade before anything concrete would present itself. Maybe someday, but, in my opinion, this is one of those “don’t hold your breath” sort of things.
Finally, the third view, and the one that I and most others in the email design world find the most realistic: that the standards already exist in the form of web standards that have been set forth by the W3C, and that the catching-up must be done by the companies responsible for the most popular email clients. If that sounds like a familiar situation, that’s because it is; web browsers went through the same evolution years ago. Despite the fact that it’s certainly not perfect (there would be very little improvement in security, for instance), I think this plan is the most workable in the industry right now, because it’s the path of least resistance. The sticking point lies in the fact that the way forward is essentially in the hands of Google and Microsoft, because their email clients, Gmail and Outlook Desktop, are two of the most popular in the world — yet also among the most outdated. Unfortunately, although both companies have expressed interest in moving forward, neither has yet taken action.
Whatever anyone thinks makes the most sense, email design in the present day is still a discipline centered around the HTML4 and XHTML markup languages, along with CSS2 for styling. And using programming languages like JavaScript to help fix the quirks across email clients? That’s a pipe dream, as most email service and email client providers strip out scripting because of security concerns. The email developer is left with two major tools at their disposal: the markup and their wits. Email development has a steep learning curve that’s daunting to conquer, in large part because the host of issues inherent to the discipline are:
1. Obscure: because there isn’t a master list out there that details the problems you can encounter;
2. Bizarre: due to inconsistencies between email client rendering engines that multiply across platforms;
3. Immutable: because solutions to these problems aren’t in the hands of email developers.
Despite these issues, you can still take comfort in the fact that, as a web designer, you already have the lion’s share of the knowledge you’ll need to develop email. At the end of the day, email is just HTML and CSS, and if you can get a webpage put together, you can do the same with an email. You just have to get used to the fact that, especially at first, it’s not an easy job to do.