6 things you need to know about email development

Email’s stuck in 1999, says everybody since forever. While this may or may not be true any more, it is true that email coding has evolved according to a distinctly different timeline than the rest of the web. Add to this the seemingly infinite combinations of email clients, mobile apps and browsers, and you see that email development, as compared to web dev, is a very different beast.

So whether you’re an email developer, an email designer or a marketing manager ready to launch your next email marketing campaign, there are some things you should definitely know about email development. I recently talked to Chiara Giuliani, Head of EM Development here at Moskito Design, to find out.

1. The responsive revolution is far from over

Despite all that’s been written (including in this blog) in the last five years on how responsive has become the default approach to web development, it’s amazing to realize that the revolution is still far from over. To take one famous example, Google ― with its Gmail and Inbox clients ― only just started supporting media queries in autumn, 2016 (though they’d been advocating for it since long before that).

According to Litmus and the 2017 State of Email Report, the key number is 75%: it’s both the number of email clients that support responsive design (as of Gmail’s updates) and the number of email marketers that use responsive design regularly in the marketing emails.

But that remaining 25% may represent a hefty chunk of your email subscribers, depending on the email clients they use. As our developer Chiara says, “the code is continually in evolution, but we have to work with what’s essentially an older version. We still don’t find support everywhere. We can evolve our code, but the obstacles are presented by the email clients. If they don’t evolve, we can’t either.”

2. Background images aren’t always picture-perfect

Background images have always been “notoriously difficult to get right”, in the words of Jaina Mistry over at Litmus. And retina displays, or the high-DPI (dots per inch) screens that have been the norm in iPhones and iPads since the release of Apple’s iPhone 4, have made them that much trickier.

Essentially retina displays show images so pixel-dense that the human eye ― or retina, in Apple’s conception ― can’t distinguish individual pixels. The result is a crisp, clear image. To optimize images for retina displays, you create an image that’s roughly twice the size you actually need and then scale it down, retaining the original pixel density in the smaller dimensions.

Optimizing for retina display has become the norm, but when it comes to background images, some email clients, like Outlook, don’t allow for this scaling down in size. And the result is images that look slightly fuzzy and unfocused.

As Chiara says, “our clients want to use background images in their email, so we include them, even if they’re not retina quality in a number of email clients. But they’re the background, not the main focus, so that’s ok. Sometimes you’ve got to make compromises in quality of an image to achieve a certain objective.”

 

3. Develop for what your customers use (not what you’d like them to)

When it comes to email development, every email client, operating system, browser, device and native app has its own particularities. You can plan for them all, but the more sensible solution is to plan for the ones your customers actually use. That means keeping track of who’s reading what, where and how.

And when you’re developing for a massive user base, as we do, you’ve got to establish thresholds for when it makes sense to develop for a new device or client (if bulk of your end-users aren’t early adopters, don’t rush to start coding for devices they won’t be using for another year or more.)

“We regularly develop emails for five big European markets,” Chiara says, “and each of them have some country-specific email clients. Our clients share their tracking data about what email clients their customers are using, and we work together to prioritize which needs the most time and attention. Here in Italy that means we have to develop for Libero which for a long time was where most Italians opened their first email account. It’s the same for GMX in Germany. We want to make sure the email still looks good on them.”

4. Beware the update (especially Outlook’s)

However enthusiastic email clients are about releasing them, when an update is announced it’s best to beware. And no updates call for more circumspection than Outlook’s.

One memorable Outlook update saw the email client automatically inserting a 10 pixel space between the image and the rest of the text.

 

 

 

Not the end of the world, perhaps, but when you’ve invested the people-hours into crafting the web design and writing the code you want, an unexplained and unasked for 10 pixel gap is enough to drive you crazy. After some searching we found that Outlook had essentially written a style rule into the code (in the form of what’s known as a DIV tag) that created the gap, which we overwrote with another style rule.

Problem solved ― until the next update.

As Chiara says, “Updates can be a mess. The best thing you can do is approach every update with caution. I tend not to jump on them right away. Updates are a bit like wine ― they tend to improve with age.”

5. Templates are great. Modules are better

Anybody who’s ever used a template for anything ― web design, word processing or code ― knows that they can make your life easier and save you time. You’ll also know that they have limits, and these limits often become more noticeable and more constraining with time.

If you want flexibility and creativity in your emails with all the time saving benefits of a template, you’ve got to look to modules (essentially the building blocks of any template). Build a typical email module ― say, a module with a text, call to action (CTA) or image and an icon ― and you can reuse it, revise it and adapt it. And file it away for later use.

As Chiara said, “here we started with a library of design modules and created the corresponding dev modules in HTML. This library we’ve created helps us save a lot of time and allows us to deliver on tight deadlines when we have to. It’s a great starting point, especially when we’ve got a lot to deliver.

It also gives you a lot of security ― there are many fewer surprises when the code has already been thoroughly tested. Not no surprises, but many fewer. And we keep expanding this library to give us greater range and flexibility when delivering for clients. They just make your life easier, and there’s nothing wrong with that.”

6. Check, test, repeat

Developing for your clients’ browsers, email clients, devices and apps means also testing for all the relevant permutations. If your end users use Yahoo, for example, you might want your email to look sharp on Yahoo via browsers like Firefox, Chrome, Safari and Explorer and the various native apps for each device.

To make sure it does look sharp, you’ve got to test. There are lots of great tools out there like Litmus and Email on Acid (both fantastic, but we tend to use the latter because it does everything our clients need). And as Chiara said, “there’s no such thing as too much testing.”

But before you even turn to the tools, making sure your code looks good starting with your own two eyes. Or better yet, someone else’s. “It’s pretty much a rule that if you write something you’re going to have a harder time finding the mistakes,” said Chiara. “Maybe if you set it down and come back to it later you can see it with fresh eyes, but tight deadlines just don’t always permit that. That’s why we always want to have an extra set of eyes to check everything. As a rule here, you don’t test the same emails you develop.”

 

At Moskito Design we write (in 5 languages), design, develop and test marketing emails that reach over 10 million readers every year.