Designing Email Sucks: A Brief History and How We’re Making it Better

We spend a lot of time helping people improve their email. And over time we’ve become acutely aware of the reasons why creating and designing emails is a hard process. Frankly, it kind of sucks. But why it’s difficult that’s important. Because if we know what makes it so hard, we can probably solve those problems and make the process less painful, maybe even enjoyable. Over the next few weeks, we’re going to run a series of posts about why designing and creating emails is hard and some ways to make it better. First up: why even scaffolding a basic template layout sucks.

Email is just HTML. From 1999.

The nice thing about email is that it’s “basically” HTML. If you’ve designed emails before, you’re probably gnashing your teeth at that last sentence. Basically HTML? More like barely HTML. There are so many HTML and CSS features you can’t use. If you haven’t spent a lot of time with email, here’s the situation. Just like how you’d design a web page and need to worry about different browsers, the same is true for email, except it’s not just browsers, it’s email clients. For web designers, this used to be a really big pain five or 10 years ago. Thankfully, standards like HTML 5 and the eventual decline and death of some very old browsers has made the situation much better. However, in the world of email, we’re still stuck in the past with different email clients behaving in very different ways. There have been been efforts to create email standards, but we just haven’t seen the same progress.

So what gives? There are a number of factors, but the biggest impediment is that Microsoft continues to use the Word rendering engine in Outlook. And the problem with that is the Word rendering engine is somewhere near the HTML 4.01 and CSS 2.1 specifications with plenty of missing features.

For all other email clients, as browsers have improved their support of various HTML and CSS features in their underlying rendering engines, they’ve improved right along side. And a few older email clients (looking at you Blackberry) are dead or dying.

However, with Microsoft’s decision to use Word’s rendering engine in Outlook 2013, support for modern HTML and CSS features is likely to be stuck for quite some time. Since Outlook still has lots of users, you’re stuck working with the lower common denominator. And so the differences between email clients and how they render emails will likely grow.

How to solve cross client compatibility

It’s a frustrating situation that HTML and CSS support in email clients is where it is, but it isn’t hopeless. In fact, if you follow the strategies web developers took to deal with cross browser issues, you can dramatically reduce the pain. Looking back, there were two big pieces to their strategy (other than waiting it out):

  1. Create comprehensive resources describing the differences between browsers.
  2. Build frameworks that automatically account for those differences so they’re largely abstracted away from framework users.

Remember Quirksmode.org? I rarely spend time there anymore, thanks mostly to the fact that I no longer spend a lot of time worrying about IE 6/7/8 and early versions of Firefox. It’s still a great resource for understanding browser compatibility, especially on mobile, but it’s just not as necessary as it was. In the past year or two, I spend more time on caniuse.com for checking HTML 5 feature support. It’s another great repository of what browsers can and can’t do. But, honestly, I don’t use that very often anymore either.

Aside from browsers getting better, one reason is that the rise of CSS frameworks and JavaScript shims has smoothed out the differences between browsers to the point that there are few features I can’t use without some reasonable fallback. Everyone’s heard of and probably used Bootstrap. It’s clearly a framework that fits that bill. But, for the record, even pre-Bootstrap, I was using Compass and SASS a year or so before for the same reasons. Instead of having to know what the quirks or incompatibilities are, these frameworks abstract away the issues, which makes development much easier.

So the whole process went from great websites that could tell you definitively why something didn’t look right in a given browser to frameworks that took those quirks and made them almost completely transparent to developers and designers.

The same process is now playing out in email. Great resources? There are plenty of them and I’m sure I’m leaving some out. Frameworks? These have just started to emerge in the last year or so, but they’re starting to pick up speed. And that’s where we stand today.

Making email layouts easier: Email template builder and a “coming soon” email framework

In surveying email frameworks that exist so far, there are lots of features you want. One of the first and most important is a way to scaffold an email so you can then focus on different areas. Some sort of grid system. Existing email frameworks are a good start, but they don’t go far enough to abstract the table-itis, not to mention indent-itis, you’re likely to get from actually building a template. They still require you to a steady stream of <table>s, <tr>s and <td>s to create your email, which is kind of a bummer.

email design

The peaks and valleys of email design.

If you step back, what would be really great is an email framework that let’s me think in terms of <div>s and then compiles that markup into cross client compatible, table filled HTML I rarely have to look at. I could build semantic HTML that I can easily edit and preview in a regular web browser and when I’m done, have the peace of mind knowing it’ll compile into HTML that will look the same and consistent across all email clients — even Outlook. You can imagine it would be a little like Bootstrap (because it’d have semantic classes to create a grid and various components) and a little like LESS or SASS (because it would take your simpler HTML and compile it to the final, nastier, but cross client compatible version).

So why doesn’t that exist? I think it’s only a matter of time. And we want to help push that effort forward so we’re working on it right now (it’s internally coded named Mailstrap). We’re most of the way there towards something releasable, but to give everything a thorough testing, we’ve made it the underlying rendering engine for our standalone, drag and drop email template builder. The templates you generate have all the nice features you’d want. They’ve been tested in all major email clients and are mobile ready out of the box. Once we’ve exterminated the last few bugs and built out the docs, we plan on releasing that project on it’s own.

In the meantime, you can create just about any email layout today with our email template builder and use it however you like. You can export the HTML to edit it  by hand and use it in your projects. You can render and send templates via our Email Templates API or use Klaviyo or another email service to send it.

Up next, we’re going to discuss CSS inliners — why they’re crucial for email and what features they need to ensure they preserve your content’s layout across mobile and web based clients. Oh, and if you want updates on “Mailstrap,” keep an eye on this blog, we’ll be announcing more soon.

 

3 Fall Email Designs We Love

 

 

With shirts and email lists, quality matters: One company’s story

 

 

How to Know When Your Marketing Tech is Holding You Back

 

.yuzo_related_post img{width:260px !important; height:250px !important;}
.yuzo_related_post .relatedthumb{line-height:16px;background: !important;color:!important;}
.yuzo_related_post .relatedthumb:hover{background:#ffffff !important; -webkit-transition: background 0.2s linear; -moz-transition: background 0.2s linear; -o-transition: background 0.2s linear; transition: background 0.2s linear;;color:!important;}
.yuzo_related_post .relatedthumb a{color:#323b43!important;}
.yuzo_related_post .relatedthumb a:hover{ color:}!important;}
.yuzo_related_post .relatedthumb:hover a{ color:!important;}
.yuzo_related_post .yuzo_text {color:!important;}
.yuzo_related_post .relatedthumb:hover .yuzo_text {color:!important;}
.yuzo_related_post .relatedthumb{ margin: 0px 0px 0px 0px; padding: 5px 5px 5px 5px; }

jQuery(document).ready(function( $ ){
//jQuery(‘.yuzo_related_post’).equalizer({ overflow : ‘relatedthumb’ });
jQuery(‘.yuzo_related_post .yuzo_wraps’).equalizer({ columns : ‘> div’ });
})

Back to Blog Home
Get email marketing insights delivered straight to your inbox.