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 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 later created all the email marketing resources we use today.
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. If they’re using the same language, then what’s 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. As long as you code your website adhering to these standards, your site will look 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. 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”*.
Now, to mix metaphors, there is also a fly or two in the ointment along with those spanners. 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 enables responsive emails.
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. Learning how to use ESPs will ensure you stay in compliance with these rules and regulations. 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.
There’s a lot that goes into making an email appear correctly, across the board. Email Developers spend a lot of time working on this, because of how quickly and frequently the industry changes. Even ESPs make changes without alerting their clients. This just isn’t the job for a Front- End Developer. They have an entirely different job to focus on, and won’t be able to keep up with changes in the email world. Doing so will either cause their main work to suffer, or they’ll end up becoming an Email Developer.
And to tackle the ‘they both use HTML’ argument another way: An anaesthesiologist and a cardiologist both use medicine, would you ask the anaesthesiologist to perform surgery on your heart? Or trust the cardiologist to administer the correct dosage of anaesthetics? 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.
[* And this is why it’s controversial: an ex-colleague of mine 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, is saying a virtual “Screw You” to the email clients that are behind the times and who don’t support funky unctionality, 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.]