Straight to your inbox
Get the best email and digital marketing content delivered.
Join 250,000 in-the-know marketers and get the latest marketing tips, tactics, and news right in your inbox.
Subscribe
I sent out the Campaign Monitor newsletter to 30,000 or so of our customers and subscribers last night, which you can check out here. Before I send each newsletter, I normally run it through most of the popular email clients to make sure it still looks fine, plus forward it around to a few members of the team for a good old proofread. Yesterday was a busy one, with the launch of our t-shirt store and some pretty big feature updates happening behind the scenes. By the time the newsletter was good to go, I was the only one left in the office. Wanting to get the newsletter out, I worked through my standard tests, gave it another quick read, got over the famous send button anxiety and sent it out. It took a good 3 minutes after the newsletter was sent before the first email came in. I tell you, send button anxiety is nothing compared to knowing you’ve just sent an email with the word “ass” in it to all your customers. I’ve already received 40 or so hilarious emails from you guys – here are some favorites so far… That’s been making me laugh all morning. Perhaps in your next newsletter you could explain how we can learn to ass our content. That’s the funniest typo i’ve seen in awhile! Thanks for lightening up my morning! Can someone over there show me how to “ass” content? “Just tweak the colors, ass your content and your all set.” Reason #89234 why spell-check is never enough ;) So why am I rubbing this in my own face? Just a friendly reminder from the Campaign Monitor team about making sure you proof-read every newsletter you send. Not everyone needs to learn the hard way.
I would like to preface this article by stating that I use standards-based markup to build my HTML emails and my websites. But for those of you who are familiar with other articles posted here at Campaign Monitor about HTML emails will know that standards-based markup results in formatting not unlike rich-text format (RTF) in many popular email clients. I’m comfortable with this and so are my clients. Well, they are once they learn about how web standards ensures accessibility and cross client/platform/device content-compatibility and helps emails reach legitimate subscribers without being eradicated by spam filters. But not every web designer has the grace and charm of Mark Wyner, and therefore many face clients and bosses who demand they build HTML emails for design integrity at any cost. (Oh how this reeks of the “browsers vs. web-standards” battles of old.) So for those of you who must use tables in your HTML emails, I have some information about how they perform across the board. I ran some tests and discovered that, while I couldn’t find a perfect solution, I did manage to collect some useful tips to make your tables behave for the most part. Table Math, Meet Box-Model Math So it turns out that when one places table widths, td widths, td padding and CSS padding into a blender, the results are quite chaotic. Inconsistent, to the say the least. Take, for example, the following table: [code] <table cellspacing="0" cellpadding="0" border="0" width="400"> <tr> <td width="100"></td> <td width="300"></td> </tr> </table> [/code] Just as intended, the resulting width of this table is 400 pixels and the width of the columns are 100 and 300 pixels: But when some padding is added—via either CSS or HTML—the widths of the columns are compromised: However, when table width is kissed good bye, the results are not unlike a CSS box model. If padding is added to the original example and the table width is removed, the code looks like this: [code] <table cellspacing="0" cellpadding="10" border="0"> <tr> <td width="80"></td> <td width="280"></td> </tr> </table> [/code] And, as intended, the resulting widths are correct for both the table and the columns: But note how the td widths were reduced to accommodate the new padding. This is just like the CSS box model in which 100 pixels wide + 10 pixels padding = 120 pixels total. Nested Tables If a table is nested inside another, the aforementioned rules apply with the exception of a couple important variances: Yahoo Mail (new), Gmail, Outlook 2007 and Eudora apply extra width to account for borders. But only when they are nested, as the parent table behaves appropriately. Applying widths to td tags that also have CSS or HTML padding creates confusion across the board. Nearly every client renders the widths in its own unique fashion. Even without any borders there are variances in width by 2–4 pixels for a nested table with two columns. My tests were inconclusive as to the rhyme and reason behind this unnatural phenomenon. Just know that pixel perfect isn’t an option (unless there is some hidden secret behind this). Clients Tested Webmail Yahoo Mail Yahoo Mail Beta Windows Live Hotmail (old) Windows Live Hotmail (new) Gmail .Mac AOL Desktop Apple Mail Thunderbird Outlook 2007 Outlook 2003 Outlook Express Eudora Lotus Notes So there you have it. Please do your best to educate your clients/bosses about how the benefits of standards-based markup far outweigh design integrity across the board. But if you fall short of convincing them and are forced to use tables for layout, take note of the lessons outlined herein. You’ll save yourself a nasty headache.
We’ve always had a very strict permission policy at Campaign Monitor with clear-cut rules about what does and doesn’t constitute permission. There was however one piece of functionality which perhaps relaxed our high standards a little – forward to a friend reporting. To date, we not only store which of your subscribers forward your email to a friend or colleague, we also told you exactly who they forwarded it to. We certainly didn’t add these friends to a list or anything nasty like that, but we did expose their details nonetheless. To compound the problem, it wasn’t crystal clear on the Forward to a Friend page that your friend’s details were even being captured. Another slap on our wrists. While we never had any negative incidents or complaints around this issue, it’s clearly not best practice and we’ve gone ahead and stopped capturing exactly who forwards to who. Instead, you’ll now see which subscribers forwarded your email and how many people they forwarded it to. This change has also been applied to any previous campaigns you’ve sent. From personal experience, I know how interesting this data was, but individual’s details were being exposed to the campaign sender without their permission. We need to put the privacy of these people first. If you’re hoping to capture new subscribers via the Forward to a Friend feature, we recommend adding a prominent link in each email encouraging new subscribers to sign up, then link right to the subscribe form on your site.
One problem we always had with the Campaign Snapshot is that it wasn’t immediately clear which subscribers you sent that campaign to. Sure, you can see the total number of recipients, but not which lists those subscribers came from. Today we did a little reshuffling with the Campaign Snapshot to make it easier to see exactly who you sent that campaign to. Even if you sent it to multiple lists, some segments and even manually added a few recipients, we’ll show it all here. Here’s a quick screenshot of the updated snapshot for a campaign sent to 3 different subscriber lists: By Clicking on the 3 subscriber lists link in the Sent to row, we reveal exactly which lists were sent to, including the number of subscribers in each: Finally, to make it a little clearer, we also moved the date sent under the Campaign Snapshot title.
The gallery of great designs by Campaign Monitor users continues to expand, showcasing lots of different email design approaches for your inspiration. Follow the gallery’s RSS feed and don’t forget to check out our new free base templates.
After some great feedback from a few customers, we’ve made some further tweaks to the 30 pack of email templates we released last week. These changes improve the results in Outlook 2007 even further, while still maintaining a consistent look in all the other email environments. Along the way we learnt about a number of key quirks in the Outlook 2007 (um, Word) rendering engine, which we plan on posting about in the next few days. We recommend downloading the latest pack to make sure all your recipients using Outlook 2007 get the benefits of these tweaks.
We’ve updated our results for animated GIF support in email. Check out our latest post. I’m not one for Flash, but many web designers obviously use it. Some for interactivity and others for animation. In the web environment, the latter is a replacement for animation formats of days old: animated GIFs. But Flash isn’t supported in the email environment, so for web designers accustomed to using animation to communicate a message are left searching for alternatives. Enter animated GIFs. I’m not going to argue about whether animated GIFs are a sufficient replacement for Flash or whether they are the devil or anything else of that nature. Rather, I’m simply going to share what I’ve learned about support for them in the email environment. The results are dizzying, so try to keep up. The Results Every single email client I tested supports animated GIFs. Well, except for one: Outlook 2007. Big surprise. Though if you carefully plan your animation, this news may not be so bad. Outlook 2007 displays the first frame of the GIF as a static image. So if your first frame works as a static image, you are in good shape. Some Advice I’m like a mother sharing advice you don’t necessarily want but that you do actually need. So I have some helpful tips for you regarding the use of animated GIFs: Don’t forget about accessibility. If you use animated images to tell a story, ensure everyone gets the message. Consider those with low or no visibility, slow connections and those who pay per kilobyte on their mobile devices. Learn from history. Blinking, strobing or streaking text or graphics sucked in 1999 and they suck now, too. Leave the annoying animations behind. Just because you can, doesn’t mean you should. Enough said. Be creative. Just as any tool in web design, we can use animated GIFs to enhance our message in non-invasive ways. So that’s where animated GIFs stand in the email environment. Enjoy if you must.
We’ve just put the finishing touches on a new demo movie for Campaign Monitor. We wanted to put something together that covered all the benefits of using Campaign Monitor in a few short minutes. Check it out now, you’ll need Flash installed to watch it. It’s always a tough call to work out what features to highlight and just as importantly leave out for a demo like this. We’re really happy with how it all came together in the end. What do you guys think, does it sum up the Campaign Monitor experience?
Ensuring your emails look awesome across every major email client out there can be a lot of work. To make your job that little bit easier, we’ve just put together 30 free email templates that look fantastic and have been tested in all the major email environments. Not even Outlook 2007 could stop these suckers looking great. The templates range from simple, single column emails through to more complex 2 column newsletters with different types of content. We’ve also been careful to keep the use of images to a minimum, so the templates look great even when images have been disabled. Changing the color scheme to suit your own brand is as simple as making a few simple tweaks to the code. What are you waiting for? Preview and download the templates now.
As image blocking in email continues to become the norm, one absolute must is to make sure you include the width and height attributes in your image tags. When most email clients (especially desktop based ones like Outlook) disable images, they show an empty image placeholder in its place. Because these email clients don’t actually download the images from the server, the only way they can figure out the dimensions of that placeholder is to look at the included width and height attributes. If none or only one is provided, they just take a guess, which in almost every case results in completely destroying what’s left of your design. Here’s a perfect example of this in action. Just this morning I received an email newsletter that only specified the height for most images in the email, and not the width. When Outlook displayed the email, it got the height right, but was way off on the width side. Here’s how the email looked when I first opened it: To see a comparison of how it’s supposed to look, here’s a screenshot of the email with images enabled: By not including the width attribute in any image tags, Outlook had no idea what width to use and its best guess was unfortunately way off. This made an otherwise readable email a complete nightmare that was almost impossible to get anything out of. To provide a comparison, I checked out the source and added the correct width attribute to each image to see what the new results would be. Here’s a screenshot of the new version that took about 5 minutes to update: The updated version that includes all width and height attributes is a big improvement over the initial version. It clearly resembles the intended design and I can easily scan the table of contents and start scrolling to read the rest of the content. The email is completely usable even with no images being visible. While there are certainly better examples of emails designed to look and work well with images disabled, the point is still very convincing. By ensuring width and height attributes are present for all image tags, we give our subscribers a much better chance of getting a usable email, even with images disabled.
After we posted an update to the CSS Support article last week, a few of you mentioned that the new PDF layout made it hard to make out the results when printed in black and white. Not only this, but it was also a challenge for anyone who was color-blind. About the same time, Martin Focazio from New York based Magnani Caruso Dutton approached us about taking the PDF version a step further (actually, about 5 steps further). Martin reworked the results to make it much clearer which CSS selectors and properties offered the best support across the board. These were then sorted into Safe, Risky and Poorly Supported to make it much easier to decide which properties to aim for. Download the spiffy new results in PDF (91kb) or Excel (80kb) To top it off, the new file also includes the percentage of support each email environment offers. We’ve also updated the original post to include the new version of the findings. A huge thanks to Martin for all his hard work, and to everyone else for giving us feedback on the original version. As usual, we’ll keep our eyes peeled for any changes in each environment moving forward. If you spot anything, let us know. Update: I’ve added the Excel version of the results so you guys can tweak it to your hearts content.
Join 250,000 in-the-know marketers and get the latest marketing tips, tactics, and news right in your inbox.
SubscribeFrom Australia to Zimbabwe, and everywhere in between, companies count on Campaign Monitor for email campaigns that boost the bottom line.
Get started for free