Why you want an Email Developer to build your emails

Square peg, round hole

Email Development History

Once upon a time, email was the black sheep of the marketing family. No one quite knew how to do it, or what was required; they just knew it had to be done. So it was generally palmed off to the Front End Developer (most likely the Junior Front End Developer), to grumble their way through it, muttering about tables as they go.

Around about 2010 email became trendy, and dare I say, sexy. It became something that people actually do, rather than something that was endured. Through self-teaching and a lot of experimentation, a tribe of Email Developers (aka #emailgeeks) emerged, sharing code hints, tips and frustrations on forums like Twitter. Sharing was a necessity as there were no resources available – these were the people who would go on to create the resources for the developers that were to come along after.

Differences between Web and Email Development

A lot of people think I hate Front End Developers. I don’t. I hate that Front End Developers still take on email development without knowing how to do it properly.

Front End Developers build websites using HTML. Email Developers build emails using… HTML. So, I hear you say, if they both use the same language, then what is the problem?

There are web standards for building websites. What this means (simply) is that the big browsers (e.g. Chrome, Safari, Firefox & Internet Explorer) all treat the HTML code in the same way. So as long as you code your website properly, adhering to these standards, your site will look basically the same in all browsers (or at least the most up to date versions).

There are no coding standards (yet) for email. And although browsers, if left to their own devices, would show you your email beautifully, there are a few spanners in the works. These spanners are generally referred to as Email Clients; Outlook, Gmail, yahoo etc. And they, for one reason or another, all read and act on your code differently. Some will strip out bits of your code, others will ignore sections, some will happily just read it like it’s supposed to be read. So for coding email you have to (and this is a controversial statement) code for the lowest common denominator; instead of marking up your content using semantic elements in your HTML, like you would in Web, styling it with CSS, you have to use tables and inline styles. Which basically means “We have to code it like it’s 1999”[1].

Now, to mix metaphors, there is also a fly or two in the ointment along with those spanners. And these flies are called Email Service Providers, or ESPs. These are the tools that Email Marketers use to send out bulk emails. These can also make changes to your code. For example, in Dotmailer you have to put in some special code to allow your email to be responsive. Otherwise it strips out the code that you’ve written that does this.

In addition

As an Email Developer you also need to be aware of things like spam filters and deliverability, and how to ensure your email actually ends up in the inbox of the subscriber. And talking of subscribers you also need to understand, and abide by, unsubscribe rules and regulations in the countries that you’re sending to. I mentioned ESPs earlier, you need to know how to use at least one of these at any one time. You may also be working on strategy, segmentation and targeting of the campaigns themselves, and are more likely to be working on the content than a Front End Developer would.

Summary

There’s a lot that goes into making an email appear correctly, in inboxes, across the board. And it’s something that Email Developers spend a lot of time working on, finding hacks on, keeping abreast of changes in the Industry and with the Email Clients (because oh yes, they make little alterations every now and then without telling anyone). And a Front End Developer, even one with the best intentions in the world, has a whole other job to be concentrating on, and isn’t going to keep up with all of this as well. And if they try, it’s likely that their main work will suffer. Or they’ll end up becoming an Email Developer.

And to tackle the ‘they both use HTML’ argument another way: An anesthesiologist and a cardiologist both use medicine, would you ask the anesthesiologist to perform surgery on your heart? Or trust the cardiologist to administer the correct dosage of anesthetics? No. Because they have two very separate and very specialist jobs. And so do a Front End Developer and an Email Developer. Let them do their own jobs, and you will end up with a much higher quality end product as a result.


[1] And this is why it’s controversial: an ex-colleague of mine (Steph Jones) came up with a lovely analogy. If you’re catering for 200 people at a party, and three are vegetarian, and two are gluten intolerant, what we’re currently doing is serving everyone gluten-free, meat-free food (eugh).

What a lot of developers are doing now (and I’m looking at you Mark Robbins), is saying a virtual “Screw You” to the email clients that are behind the times and who don’t support funky functionality, and just doing it anyway. There’s a silent revolution going on trying to force some of the email clients to catch up, or risk unhappy users realising they’re receiving substandard emails.

However, there are a number of reasons not to take this approach, a big one is if a large percentage of your client base uses one of those behind the times email clients. I’m focussing on the majority of companies who will want an email that works (reasonably) well across all clients.


First published in the No BS Email Marketing Guide

Subscribe
Subscribe to receive any of my blogs via email

Sign me up

Subscribe
Subscribe to receive any of my blogs via email

Sign me up

Leave a Reply