HighEdWeb 2015, Milwaukee, WI
Monday, October 5th, 2015
Hi. My name is Peter Anglea and I am the web developer for Bob Jones University’s Marketing department. Counting workshops, track sessions, and a repeat red stapler presentation, this is my 7th time to present or lecture on responsive something at HighEdWeb. And of all the responsive projects I’ve tackled in the last 5 years, email has without a doubt been the most frustrating, annoying, infuriating, mind-boggling, etc.
I started doing email a year and a half ago, when the previous person responsible for it left the university. Prior to a year and a half ago, I had never coded an HTML email. It was not something I had ever planned on doing. But I jumped in with both feet, trying to learn my way around this new medium.
Obviously, coding email is a frustrating and peculiar task. Otherwise, I would have no need to “demystify” it. And although I could say plenty of nasty things about email, I promise to stay positive about this.
So let me begin by saying…
I love the web. I mean, don’t you agree? It is a pretty fantastic medium and it just keeps getting better every day. New technologies and new standards are constantly emerging and as the web become more and more an integral part of daily life, so too comes the opportunity to truly enrich people’s lives with meaningful, beautiful, elegant technological solutions.
Every reason why I love the web is a reason why I hate email. Seriously. It stinks. Big time. There are no standards, it’s not cutting edge, it’s not enjoyable, and frankly, most people are just content to send your content to the great cyber trash heap in the sky!
While I’m venting… let me tell you more about why I hate email. It’s hard! Hard to get right, hard to test, hard to code. It’s tedious! It’s ugly! Seriously, this code is ugly. It’s like living in 1995 all over again. But the thing that frustrates me the most—to no end—about email is how stinking valuable it is. As a marketing medium, it’s really hard to beat.
As much as I hate email, even I must admit that in a marketing world saturated with social media, the inbox is still one of the most valuable channels at your disposal. Seriously. There’s a reason why people are still talking about this even though we’re in the era of social media and search engine marketing and whatnot. Other people have covered this issue, so I won’t bother in my limited time here to discuss the merits of email in general.
But what about responsive email? Do we need that? There is a great article—very thorough—written by Campaign Monitor, and in it they summarize with 3 main points. First of all, statistics show that opening email on mobile devices is more common than desktop or webmail clients. How much more common? Most reports conclude that over 50% of email opens today happen on mobile devices. Over half! Another thing… readers are less likely to click through on mobile. You could argue that this makes mobile less of a worry for you. After all, if people don’t bother clicking, what does it matter? However, you might also argue that the reason people don’t interact with mail on mobile as much is because most mail isn’t formatted properly for mobile or is so poorly conceived, it doesn’t allow for an on-the-go user to interact with it in the first place. So, there’s room for improvement there. Third, if a mobile reader opens an email again from a different device (assuming it got their attention), more clicks happen. So there is definitely a huge benefit to making our emails mobile-friendly so that users can interact with them or at least notice them and become interested.
You add of this information together… the size and engagement level of your email audience… the vast amount of mobile email consumption… you begin to realize that…
…if we can get this right, the payoff will be huge. This is worth pursuing, as frustrating as it might be. The potential ROI outweighs the frustration.
But it’s not easy. And that’s what I want to talk about today. Responsive email is a huge topic and there is so much to learn. To get you started on your journey, I’ve decided to focus today’s talk on the three major hurdles to responsive email development and of course some solutions to those hurdles. Hopefully, you’ll walk away today with a game plan. A plan of attack. And if I can manage to inspire you (at least in some small way) to tackle this job and not completely dishearten you, you are the person for the job.
The first hurdle that we need to talk about is email clients. Some of you probably expected me to say “code” but code and standards are only as good as the clients themselves. So let’s explore this issue.
You see, unlike browsers and the web, there are two huge problems with the current landscape of email clients (probably more than two, but I’m summarizing). First is the sheer number of email clients. I think by MailChimp’s latest count, they serve email to 62 different clients. 62! Let’s compare that to the web. You’ve got maybe 5 main browsers (Chrome, Firefox, IE/Edge, Safari… Opera… um). More to the point, there is an absolute lack of adherence to standards in a good majority of these clients. So… basically like the web back in the 90s. Thankfully, nowadays, even though we love to complain about testing our sites for IE and such, it really is much, much less of a chore than it used to be even a decade ago because of great innovation in the browser realm.
Why hasn’t that same kind of innovation happened in the email realm? There are a lot of reasons and I’m not sure I can speak to all of them. We could probably have an entire separate discussion about this. Some have posited that since some companies… ok, Microsoft… wanted a strong connection between their word processing software and email software, standards stalled on their email client so that it could handle the proprietary format of Word documents and such.
Unfortunately, it’s not helpful to today’s discussion to dwell on why exactly email clients are so nasty. Let’s just acknowledge that they are and focus on how to make the best lemonade possible with these lemons.
As we dig into the realm of email clients, there are two main offenders that we have to account for because they hold so much of the market share. First is Outlook (Microsoft… no surprise there, right?). The other is Gmail. Yes, Gmail. The sheer number of people who use these two clients means that we have to account for this in our coding. Then there’s mobile email clients which… are actually pretty good! Seriously, the silver lining to this email client discussion is that most mobile email clients (ie. Apple Mail) actually support a lot of HTML5/CSS3 standards. This is excellent news for us responsive folks. It’s also shocking news… because now the breadth of email clients that we have to account for just got that much bigger. A developer friend of mine tweeted me recently and said responsive email was like trying to live in 1995 and 2015 at the same time. That’s a pretty accurate assessment.
The second hurdle we need to talk about kind of goes hand-in-glove with the first hurdle… the code. Clients and code kind of go together since it’s the clients that determine how well standards are applied, and therefore how we as developers have to accommodate them with the way we code.
And to make this simpler to digest, let’s take responsive out of the equation. You need to understand first how a basic HTML email is constructed. To make a long discussion short, for the sake of time, what you need to know is basically this… take everything you know about semantic HTML5 markup and throw it away! Yes, you heard that right. To accommodate for the lack of innovation in the client realm we need to go back in time. We’re basically limited to HTML4 and CSS2. So, let’s take a moment to reacquaint ourselves with (or, if you’re somewhat new to web development, introduce yourself to) some long-forgotten HTML tags and attributes. These will be our tools of the trade.
Of course there’s <table>. Table-based design is something they talk about in the history books nowadays. But that’s exactly where email development has stayed all this time. I forgot the <center> tag was a thing. And, of course, we need to use <i> instead of <em> and <b> instead of <strong>. Of course, since we’re going to be getting familiar with <table> we’ll need to become best friends with cellpadding, cellspacing, border, align, valign, and bgcolor. We’ll need to specify widths with the native attribute instead of just with CSS, and speaking of CSS, we’re gonna inline-style everything because many email clients don’t support <style> tags. Oh, can anyone guess which element uses hspace and vspace attributes? Yup, <img>.
Let’s consider a basic example. Here we want to make an email template with a center-aligned content area. We need to start with a table to wrap around everything. For every table (yes, every table) we need to specify cellpadding, cellspacing, and border, even if the value is “0.” Width and bgcolor are optional, but I’ll specify them here. I need to make sure that the content area is vertically-aligned to the top; we do this with valign. Then to center-align the content area inside of it, we’re going to bust out the <center> tag. Yeah! All this forms the wrapper for the content. Phew. Ok, now for the content area. Another table. More pointless attributes, but let’s give the content area a little padding. And no, we can’t use the CSS padding attribute because clients do not render that consistently at all. Go figure. Again, we will use valign top for our content area and finally… some content. For each element, we must repeat the styles inline. This is simply my preferred formatting for a paragraph. It helps to specify all of these attributes because if you don’t, different clients will supply their own defaults (kinda like browsers do, but way more irrationally).
How was that for you? Still with me? That was a pretty basic example, and I know I glossed over a lot of reasoning and best practices there.
That was a fixed width. How do we take it a step further and make it responsive? Well, if, for a basic HTML email we had to forget so many modern best practices, then for responsive… take everything you know about mobile-first best practices, separation of content and styles, DRY coding, proper CSS specificity, and almost everything else that you’ve probably been taught about responsive web design and…(you guessed it) throw it away!
What are our responsive email tools of the trade? A little bit of “@media (max-width),” and a whole lotta “!important.” Yep. Responsive email is literally a mobile-last operation. Hence the max-width media queries instead of min-width. We must develop our email for the crusty desktop and webmail clients, and lean on our mobile devices’ support for CSS3 media queries to make things work. Remember, I mentioned earlier how most mobile email clients actually have pretty good support for modern standards. That is our saving grace here.
What about another standard responsive layout: columns? How would we use what we know about HTML email development so far to go about making two column that are side-by-side on desktop, but stacked on mobile? First let’s make our content wrapper (simplified here from the previous slide… I can only fit so much text on the screen) and create two more tables inside of it with fixed widths; one left-aligned, and one right-aligned. This will work great for desktop, but how do we make it responsive? Here is where our friend the max-width media query comes in handy. We’ll simply specify in a <style> tag (for the modern clients that actually support it… unlike Gmail) to have these tables be 100% width under 600px.
Now, that’s a basic example and it’s all the code we have time for. I haven’t even mentioned all the crazy, asinine ways of getting around the various quirks of email clients. Seriously, if you think CSS hacks for IE6 are extreme, you haven’t seen anything yet!
If I have somehow managed to whet your appetite for this kind of thing (or if I’ve only raised more questions than I’ve answered), I’d encourage you to check out Smashing Book 5 which was recently released and read chapter 8—”The Dark Side Of Responsive HTML Email” by Fabio Carneiro, a brilliant developer over at MailChimp. (See, even he acknowledges responsive email has a dark side!) He does a fantastic job of explaining why there is such a disparity among email clients and gives you some great code examples in much greater detail than I can possibly cover here today.
Ok, deep breath. I have one more hurdle to discuss with you today. As if those first two weren’t enough, right? And that is email service providers, aka ESPs or bulk email services. This would be software like MailChimp, ExactTarget, ConstantContact, or whatever CRM or system your institution uses.
I think it’s vitally important that we talk about these systems. This is not something that I’ve really seen other people in the industry talk about primarily because most of the technical writing out there about responsive email is done by people who work for these email services (like Fabio at MailChimp in the Smashing Book). The fact of the matter is, email clients and the code are not the only things struggling to keep up with the speed of innovation. ESPs are, too. Depending on your setup, your ESP could either make the first two hurdles we discussed irrelevant, or render all of your hard work to this point ineffective. I found this out the hard way. I worked for many, many weeks on a solid responsive email template only to find that my ESP introduced a whole new series of problems that almost rendered all of my work to that point completely worthless. So, what am I talking about?
The first big problem that many ESPs have is little or no support for responsive templates. Many ESPs claim to “support” (air quotes) responsive, but it’s normally not intuitive or requires a whole lot of technical knowledge and expertise to make it happen. This is often due in large part to the tools they provide with. The WYSIWYG. We all know them, we’ve all used them in some CMS or other, but building responsive templates (and perhaps HTML emails in general) is fundamentally different from building a website. WYSIWYGs just don’t work well with email development because, first of all, they generate terrible, inconsistent code. Email code is specific, particular. And, as I will demonstrate in a moment, WYSIWYGs don’t tend to generate code to the level of specificity we need to make a beautiful responsive email. And even if we developers are able to wrangle good code out of a WYSIWYG, there’s little to no chance we can train non-technical users to do it, too. Simply put, the WYSIWYG is just the wrong tool for the job of responsive email.
Let me demonstrate this by showing you some actual problems that have plagued me in this next segment I’m calling…
“Stupid things ESPs do!” Take this example, for instance. Rather than styling text inline like they should, WYSIWYGs are often programmed to resort to the dreaded <font> tag. Now, there are some instances in which use of the <font> tag in an HTML email is perfectly legitimate. This is not one of them. Notice size=”2”. What is 2? What’s the unit? 2 pts? 2 ems? Well, it’s none of those. It’s a relative scale where the lower the number, the smaller the font. But it’s up to the email clients to define what exact size that is. And you guessed it, it’s awfully inconsistent. Here’s what size “2” looks like in Outlook and Apple Mail. Very different. I have to squint to read it on my Mac. And so every time someone in our office uses the provided tool in the system to make an email, it’s inconsistent from the get-go.
Here’s a fun one, not related to a WYSIWYG. In my ESP, whenever I use their template system, each one of my content chunks is automatically wrapped with this table element. I can’t get rid of it. It’s just there, and it’s there for every user. It might not be so bad, except for that bgcolor attribute. You see… when you leave the bgcolor attribute blank like that, there’s a certain webmail client that interprets that… as black. Now, unless your email template happens to be black, that’s a problem. And guess what our campus webmail client is. Yep. The emails are literally unreadable. I tried to let the support department know about this one, but frankly they either didn’t understand my request, or they didn’t want to make this change for every user of their system and so it remains to this day. This is a huge disincentive for me to use my ESPs email creation tool.
Here’s another great thing my ESP did for me. You know what a preheader is right? That teensy text at the top of your email that might show in a preview in your inbox list. It’s a really handy thing. And my ESP decided to automatically include their own custom chunk of code to display it without letting me customize it. Honestly, it wouldn’t be quite so bad if they didn’t automatically specify a hard-coded width. Why?! Now, even if my beautiful email is immaculately coded and perfectly responsive, it won’t flex as long as that table is sitting up there. This is what I mean when I say the wrong ESP can absolutely stop your responsive goals dead in their tracks. Fortunately, after many, many emails with the support team they were able to remove it for me. So kudos to them. I guess.
Anyways, it’s all good now because my school is moving into a brand new CRM with an accompanying email service. Or so I thought. A couple months ago, as our admission team was in the beginning stages of migration into this new CRM, I was brought along to a meeting with the vendor representative who was going to train us users on the email module. Without showing us the email module, he described how it worked and asked if there were any questions right off. Naturally I asked him, “Does your CRM have an email template system which will allow me to write my own code and reuse it, and allow others to modify it etc., etc.” “Absolutely!” was the reply. Then he showed us the “template system.” Yep. It’s one ginormous WYSIWYG!! Everything is all together in one great big glorified text area. If data entry personnel hits backspace a few too many times, the email structure is toast. You’ll also notice there’s a source code button which lets me paste my own HTML into it. Except it doesn’t let me paste anything outside the <body> tag, including the <body> tag. It also strips away <style> tags. Do you know what that means? I literally cannot include @media queries. Not even if I wanted to. It is possible to create basic (and I mean basic) responsive emails without the use of the <body>, <head>, or <style> tags, but it’s a bit like eating gluten-free cake. I mean, is it really still cake??
I’m sorry. I promised to stay positive, didn’t I? But it’s so hard when there’s so many problems and pitfalls waiting to trap you at every turn, isn’t it? To make responsive email work, we have to have a deep understanding of a multitude of email clients all with varying degrees of support for basic web standards and each with their own quirks. You need a high level of technical skill to understand how to code even a basic HTML email. And if that’s not enough, sometimes vendors complicate things instead of simplifying them for us.
But I didn’t come here to be a little black raincloud and vent about problems without actually proposing any solutions. So, is there a solution for all this? I have a few tips for you.
My first piece of advice to email developers is to simplify. KISS—Keep it simple… and short. This applies to our content and our code. We need to simplify our content because long-form email is just not what users want from this medium. We may not have to compete to get our emails into people’s inboxes, but we do have to work to get them to read it (and not unsubscribe). In my office, I am constantly advocating for simpler, shorter emails. One short paragraph of text (maybe two), one eye-catching image, one call to action (not multiple links). In my experience, those are the emails that people engage with the most. And the less cluttered your email is, the more likely people are to reopen and reinvestigate that email on another device, which, as we learned earlier, will result in more engagement. It’s in our best interest to keep our content simple because that will also keep our code simple, and minimize inconsistencies between clients. Developers, I recommend you create a handful of robust HTML snippets which you can use and reuse over and over. Even if you have to code your emails by hand, this will keep you from going insane from coding a unique layout for every e-blast you make.
Of course, there’s the matter of actually creating those short code chunks. What kinds of layouts are worth coding and supporting? What does a good email look like? Fortunately, you’ve got a lot of great research and inspiration to get your going here. I recommend checking out responsiveemailpatterns.com for some ready-to-use HTML snippets for common email layouts. And if you need some design inspiration, a guy from my hometown has created reallygoodemails.com which is, you guessed it, a collection of really good-looking emails of many different types from many different sources.
My last solution is more of a challenge to my developer and vendor friends here today. And that is simply to take up the challenge to build better tools for the job. I’ve already made my feelings for WYSIWYGs known. What good is a WYSIWYG if WYSINWYW (what you see is not what you want? And what good is a tool that we can’t hand to a non-technical user and expect to get great results? There is an opening here for some of us to create a better tool, because if your ESPs default tools are really bad, almost all of them do support straight-up HTML…
So I made an attempt at a solution—something to simplify the HTML creation process—which I’d like to show you.
Basically what I’ve done is I’ve created a system of reusable HTML components with the Handlebars.js library (essentially all the code necessary with placeholders for text and image sources and whatnot). And with a simple user-interface I am able to construct a simple JSON object to pass to my handlebars template which automatically stitches all of my HTML together into a live preview of my template with full HTML output which I can then paste into my ESP.
Here’s a screenshot of what it looks like. On the left, there are a series of template components which I have created: Email Header, Cover Photo, Text Heading 1, Text Paragraph, and so on. I can drag and drop these pieces in any order I want. I can click on some of them to expand them and type into them. And as I do this, on the right, I see a preview of my email as I’m making it. I can also get the complete HTML source at any step along the way. It will even notify me if I’ve made any errors in my template (pieces out of order, etc.). There are no WYSIWYGs here. Just a simple UI that anybody can use to quickly and efficiently create a simple email.
This is what I envision as the future of email creation tools. I hope to have a public demo to let people poke at in the near future and possibly release some code on Github. Follow me on Twitter or shoot me an email if you’d like to stay in the loop on future progress with this tool. I’m almost to the point where I’m ready to train our non-technical staff to use this tool so that I can get a piece of my life back after 1.5 years.
To conclude, I want to encourage to tackle the challenge of creating great responsive email. To do so, I think it is of utmost importance, as with any new medium, to extensively research the inherent limits, strengths, weakness, pros, and cons of this medium. Learn all you can about clients, code, and yes… ESPs. Having done that, you’ll be better equipped to devise a plan for maximum efficiency and optimal ROI. Beyond that, as you make discoveries and have your “light bulb” moments, share what you’ve learned and help make the web better for everyone. I believe in the genius of you all at HighEdWeb, because I believe that at your core, you’re just like me…
… and I love the web! (But email is still growing on me.)