(Relatively) Painless Email Coding
Email Development at Next Big Sound
Web development tends to mature at a rapid pace. It seems like every six months, there’s a new framework or a new shiny tool to use for front-end developers, upon which other developers can then build more frameworks and shiny tools. Compared to the days of Dreamweaver and the marquee tag, we’ve come a long way.
Email development, unfortunately, hasn’t.
Writing HTML-based emails is like entering a strange web development time machine: you leave the modern world and find yourself going against every rule you’ve ever learned about web development. Want to put two things next to each other? Use a table. Want to nest two components within each other? Table within a table. Want pretty styles for your nice component? Forget external stylesheets — you inline those styles, baby. Oh, and by the way, some of those styles just won’t work in emails. Are you crying yet? (I am.)
On the bright side, some email clients have begun to support some of the features of web development previously unavailable to email (Gmail only recently started accepting media queries.) On the other side… some major email clients don’t support these features, and each client supports a different subset of them.
In the words of my mother: Oy, vey.
Emails at Next Big Sound
This past year, we at Next Big Sound have been trying to deliver more insights to our users about their artists’ data. Part of that process has been revamping our emails so that they contain valuable and actionable information for our users. We want our emails to be like your ideal soulmate: insightful, beautiful, and responsive.
In other words, we want our emails to look like this:
Visualize the End Goal
I consider writing code almost like creating art in that you’re building something from nothing. For me, it’s vastly helpful to break down the different sections of an email into components (since, as you have probably garnered by now, we will be using a lot of tables to re-create this design.)
Sometimes it’s even helpful for me to physically draw out the design on a piece of paper and break it out from there. It’s a seemingly trivial step that can help focus a larger design into smaller components.
At Next Big Sound, we construct our email templates using components — a block for the header, a block for an image, a block for a single event, and so forth. Since these components are all generally able to exist independently without interfering with the layout of other components, we can start to think of each of them like a building block that we put together on its own, and then stack on top of each other. Some components will get nested as sub-components into larger components (as you can see from the diagram above.)
If your emails are responsive (which, by the way, they should be), then you should also keep that in mind when visualizing how your code will look. This step isn’t about the nitty gritty — it’s more about getting a general vision in your head.
Build the Foundation
I could link you any number of articles comparing building code to building a house (and quite a few arguing the exact opposite), but we’re not really here to debate that. What I will argue is that, especially for building an HTML email, structure is everything, because the table is the basic unit for building an email. For me, putting something on the screen quickly is most important, so I start by building my tables. Hopefully, because you are working with smaller components rather than tackling a huge email all at once, the nesting of the tables doesn’t get too complex.
Don’t worry about styling just yet — get content and structure on the page. I usually start by building the web layout with the basic content in its respective places, making sure the nesting of the tables is both clear and not convoluted. If we examine the email HTML from the top level, we can see that it’s essentially one giant table with a bunch of rows:
For the most part, each of those rows corresponds to one of the aforementioned building block components that the email comprises. I write each of those components separately so as not to get overwhelmed with the nesting of the tables, but you can see that the components range from fairly simple to quite complex. When I’m writing more complex components, I’ll break those down further into smaller building blocks as well.
Make it Responsive
After getting something workable onto the page, I’ll go ahead and add some responsive logic, still without worrying too much about font stylings or colors. This is the step where most of the padding gets added in. You’ll note that if you did a good job visualizing the overall email from the very beginning, this step actually becomes fairly simple.
Make it Pretty
Utilizing CSS can be one of the most instantly gratifying aspects of being a front-end engineer. Unfortunately for emails, a lot of the fancy CSS goes out the window, but there are a surprising amount of ways to still create a beautiful, slick layout. Each CSS property will likely come with its own set of complications, but I try to emulate the given design as accurately as possible on a web browser and save the real fine-tuning for the testing portion (you’ll see why very soon.)
Testing, Testing, Testing
I can’t stress this enough. This is a painful, horrible, and completely necessary step. Email clients are notoriously unsupportive of various CSS properties, and the worst part is, the support varies across clients (not unlike browsers.) Unfortunately, instead of three main web browsers that generally support a wide array of features, you’re dealing with at least five different email clients that each support a small but different subset of features.
I try to get to this step as quickly as possible, because it’s extremely likely that I will have to alter or tweak a lot of different aspects of the email HTML so that it works on a variety of clients. Before going super in-depth with stylings, I want to make sure I’m not doing anything egregiously wrong.
Next Big Sound uses Litmus to test our email templates, and it works very well. After finding where the majority of your user base checks email (hint: mobile email share is rapidly increasing!), it’s best to test across a variety of clients and devices to see what your email will look like for different users.
But I don’t rely only on Litmus alone. I generally send quite a few test emails to myself on a variety of clients to see the layouts in practice. It takes quite a few runs of tweaking and fine-tuning CSS properties to get an acceptable-looking email across the main clients — lots of fallback options and clever manipulation of layout tricks will help a lot here.
Learn When to Say No
Our email designer is fabulous, and she asks for a lot because we’re all ambitious people and we love to push ourselves. But I’ve learned that it’s important to know that email coding is highly limited in its capabilities, and learning when to stop obsessing over a detail that simply won’t cooperate in Outlook 2010. The balance is difficult to find, and it’s important to me that I have an open rapport with my designer to be able to find compromises.
And really, I try to say no very rarely. There’s some sort of gusto that accompanies web development, and I do feel a developer should be willing to try anything and everything to make a beautiful design work.
Email development tends to be a game of prioritization. There are so many factors to consider: size, fonts, layout, email clients — and it’s important to understand what tradeoffs can be made, and what simply cannot be compromised. It can be a frustrating, difficult, and hair-loss-inducing process, but it’s not an impossible one. And in the end, it’s a fun puzzle to create within the boundaries of some limitations — and in the case of email development, pushing those boundaries as far as they’ll go.
Cynthia Meng is a senior software engineer at Next Big Sound at Pandora.
