Why Does Email Feel Like It’s in the Stone Ages?
People send 183 billion emails a day, but on the coding side, HTML email can still be throw-your-keyboard-against-the-wall difficult to build. Here’s what I learned in my most recent foray into one of the web’s oldest protocols.
Typically when our agency designs emails, it is part of a larger campaign and we opt for MailChimp, Constant Contact, or a similar tool. So when our Fortune 50 client asked us ask to build a static email that would only be seen a handful of executives, I approached the task with the reckless confidence web developers are known for. This would be simple right?
Apparently not so much.
After clearing the hurdles of having a controller print an email (something for which there doesn’t seem to be an easy, out of the box solution), I set about writing and styling the email design I had been giving: HTML5 and CSS3. After the usual fiddling and testing I had a nice, responsive, email layout. It was ready for the client’s application. Quickly I went and passed it into the helper method I was using to build the emails, and launched it off to the test email account I was using.
I was then shocked to learn two things. First, Gmail doesn’t like rendering anything. Second, email renders differently than almost any other type of modern web content. I was beyond perplexed. After some reading, I learned that most email clients require layouts to be structured as tables as opposed to the modern paradigm of css positioning, or using a framework like Twitter Bootstrap.
In the veritable dark ages of web development, most websites were written and laid out using tables to position elements. Today, it is generally considered bad practice due to how time consuming it can be. Table layouts have a tendency to have strange behavior when you have to design them to be responsive to a mobile experience. Therefore it’s natural that I (and many other newly minted developers) have never had to design anything using a table layout.
This really got me thinking. In the current age of rapid change in the web development industry, why is something as ubiquitous as email still feel so archaic?
With my sophomoric knowledge in tow I employed my best Google-fu to figure it out. Why does something as basic as email require a specialized skillset to look professional grade? A quick search revealed I’m not at all the first to discover this problem. In fact, there are a slew of articles focused on overcoming the limitations of email rendering. After much sifting I deduced there are two key barriers preventing email design from making the leap into the modern age, both of which are rather simple answers.
- Email technology is locked in.
There are so many email providers and engines responsible for rendering it, a significant change could impact potentially billions of people.
- Email has to be able to work for the lowest common denominator.
This is related to lock-in. The fact that so many people around the world are using email systems means that most emails must conform to the oldest, most basic of rendering engines, hence the reason for table layouts and lack of access to modern CSS and its extensions.
Armed with an understanding of why my perfectly crafted email looked like absolute garbage in all the major email clients, I had to figure out a way around the problem so I could deliver a functional and aesthetic product to the client. This ended up being quite a bit easier than I expected. A simple search provided several lists of web apps for designing very nice, responsive email templates.
After much fiddling, I decided my favorite was beefree.io. It has a very simple and easy to use interface which requires no understanding of coding to generate a very attractive product. It has been very easy when I’ve been swamped to ask a designer or someone else to start the layout, then have me pull out the code for final tweaks. The Pro version is only $10/month and just adds the ability to save your work. Also, recently added in a beta release is the ability to host any images on a BeeFree CDN and then link to them so they don’t have to be sent inside the email itself.
After designing the email and exporting the code, it’s easy enough to pass it into any sort of method in a larger application and add data objects and other required information. You can also of course then edit the styles (all of which are in-line remember!) and other attributes to get things just looking just right.
I didn’t want to stop at BeeFree, after all, they aren’t even paying us for the shoutout! So I did a bit of quick research, and found several other platforms with appealing, easy-to-use features. I even made a handy-dandy chart. I rated three categories: ease of use, price, and extensibility, or ease of adapting the code to be used elsewhere.
Obviously using a third party application like BeeFree isn’t always an option (or the best solution) to craft a nice looking email. So what else can we use to make our emails look like they weren’t written in 1995?
While my marketing colleagues may balk and cry foul, maybe we should just, kind of, let email die. This may be the most elegant solution given the incredible lock-in it has. If you can’t cure its problems, just Old Yeller it and start using Slack like a real near-singularity human being.
Again, just killing email isn’t a solution for a long while (if at all), and until then, there is the wonderful concept of graceful degradation. All too familiar to any programmers reading this, graceful degradation means coding an email with built-in fallbacks if something fails to render in the way it should.
Here is the simplest guide I was able to find on what the authors call “defensive email design”. Both that article and this additional piece do a far better job at explaining how to work around the issues I’ve raised. Each provides concrete code examples that should be easy to duplicate for even the beginner.
Well, now what?
We’ve explored why emails feel so outdated, ways to compensate for email rendering’s obvious age, and pointed you towards expert opinions and advice. It’s now time for readers to go out into the web and decide the future of email.
Will we keep designing for the past — let’s be honest, anytime you write fallback for IE7 that’s what we’re doing — or will we gently guide users into the future by just ignoring this problem and using instant messaging systems and social media for our marketing communication?