Once there was this girl, let’s call her Susan, who knew how to code sites. Susan had plenty of contract work and good HTML knowledge. She came to work with us. The job was to code html emails and we were coding a lot.
Like with anyone who comes into email her first reaction was like “tables? seriously?”, and when she saw her first, five hundred lines of code template to work on, literally her jaw dropped. And that was easy work, just changing some links and swapping images.
Actually, when I recall my first contact with email, my reaction was similar. But I remember that funny times of 90’s with invisible gif spacers, table layouts, and
’s all over the place. So it wasn’t so strange to me back then.
Anyway, later on, when Susan had worked on a few templates and got a hang of it, we gave her an assignment to create a new template from scratch, for a new client. It was a disaster. Well, maybe not a disaster (there was help on the way :) but it had taken a lot more time than anybody anticipated.
So, what was the problem?
No one took the time to teach her what are the concepts behind slicing designs for email. Or how to position content correctly. We gave her ‘good practices’ and some half-assed CSS code guide, but never really explained why one should do something in a certain way. And that lack of the backbone and knowledge is something I see a lot these days. No one has the time to teach the principles.
When you get on the web, and search how to code html email, you get those articles with vague advice of some ‘internet gurus’ who coded like one email template in their entire life, and they say “just use tables!”, “inline your CSS!” or they give you a link to Campaign Monitor’s CSS guide and say “here, use this!”.
Clearly, this is not enough.
People obsess over tips and tricks, but they forget about basics. Good developer needs to know how things work, so he can avoid troubleshooting weird errors caused by poor coding habits.
How many times did you heard or read about how to prepare and test containers to cut development time? How many times did anyone said that having a good concept of slicing content is the key to fast-coding a high quality newsletter?
- a) they don’t have a clue, or
- b) don’t want to share the edge they have over the competition.
So, how you should approach coding emails, assuming you are just starting out? Let’s dive a little bit deeper and understand the process involved here. Usually it will look something like this:
- you are sent a design to code from the project manager, a graphics designer, or a client
(or you design yourself if you work alone)
- you slice it
- you code the stuff
- you run the code through various validation tools
- you test in email preview software and also send tests to your test inboxes
- you send back the files to the project manager or a client, etc.
As you can see, before you do any coding you need to see the design. You need to evaluate how you will cut it into pieces. Where you can use fonts, where you can use CSS, and where you will need to use images. And how do you evaluate this? What are those invisible guidelines?
Evaluating a design is especially hard when you are just starting out with html emails. You just don’t know what will and what will not work, and in many cases your experience with coding for the web will not help, but hurt your efforts. Many developers, usually because of lack of time, end up just slicing everything into really big image chunks and put those in a one big
<table>. Let’s be honest here with ourselves – newsletters like these are half-assed effort.
They load up longer – if the content will take too long to load, the user will skip the newsletter altogether. With images blocked, because there is no text visible, the user has no way of telling if the content is useful. The text elements (the copy) and interesting design (expressed via correct use of HTML attributes & CSS) should be there to encourage loading up images and seeing that banner and the rest of the graphics.
Also, if you code your newsletter right, and it is sent frequently (for example weekly) you can automate generating the next issue.
Evaluating design for email slicing
The principles for slicing design correctly are as follows:
- determine the width of content, and add proper margins to that, so you’ll have even rendering among all major email clients
- determine what kind of wrapper you will need to implement
- determine where to position main horizontal and vertical slicing lines
- determine where you should break containers and wrappers
- determine where you can use standard fonts and where you will need to use images
Mind The “Real” Width
For example, lets say you have a design that is 600 pixels wide. By that I mean that not the file itself is 600 pixels wide, but the graphics or text in widest place have that value. Usually it will be graphical element, like banner or some sort of container holding text copy. If you code this as tables 600px wide, your layout will look unaesthetically in some email clients, that do not add margins/paddings to the preview pane.
To cure this, you should always add margins on each side of your tables. After sending hundreds of ecommerce newsletters, I have found that 10 to 20 pixels is that sweet spot. It makes your newsletter look good everywhere, no matter if the email client centers your tables or aligns them to the left. So, getting back to our example, your 600px wide email will now have width of 620 to 640 pixels with margins on each side.
Mind that what I call margins here, are actually empty table cells – CSS margin property will not work here.
Aside from margins there may be a case when you will need a 100% background behind the content (usually near the header, preheader, or footer of the html email newsletter). In that case you wrap your container with margins with another table which have its width set to 100%.
<!-- The first table is a wrapper which adds background color which stretches full width of the email program preview pane. --> <table align="center" bgcolor="#999999" width="100%"> <tr> <td> <!-- Here we have the table that adds 20 pixels of margins on each side of the nested table (600px + 20px + 20px = 640px). --> <table align="center" width="640"> <tr> <td> <!-- We achieve margins on both sides by centering table #3, and setting correct width. --> <table align="center" bgcolor="#eeeeee" width="600"> <tr> <td>Content</td> </tr> </table> </td> </tr> </table> </td> </tr> </table>
The Next Step
Quality newsletters doesn’t come from implementation or hacks, but from the good concept before coding ever begins.
Now improve your slicing concepts by subscribing to my newsletter. There’s a lot of content on the way, you certainly don’t want to miss that! After you subscribe you will get my Email Master Checklist to kickstart your coding efforts. If you are on the list already, skip below and share your thoughts on email coding!