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
We’ve posted about this quite a while back but it remains one of the most common questions we get. How can I get the address of people who just unsubscribed, so I can keep my database up to date? Since we first answered, we’ve added a full API which has a method for getting a list of people who have unsubscribed since a specified date. If you have some development skill available, that’s a great way to keep things in sync. However, you don’t have to use the API – a simple way of getting hold of those unsubscribed addresses is to use the custom unsubscribe confirmation page. You can find it under ‘Unsubscribe Options’ for any list, and it lets you enter a URL that we will send people to after they unsubscribe from your list. You can just have a static ‘sorry to see you go’ page there, but you can also pass through the unsubscribing email address, and send it to whichever internal system you have. It’s very simple – just make your unsubscribe URL something like: www.yourwebsite.com/goodbye.php?emailaddress=[email] That [email] tag will be replaced with the relevant address, and passed onto your pag, and from there it’s up to you. Anyone who unsubscribes via a link in your campaign or an unsubscribe form will be handled in this way. Please note: You can’t pass through any custom field values on the query string like this, only the name and email address will work.
I’m going to let you guys in on a little secret. There’s a difference between how an email sender sees their inbox and how an email recipient sees theirs. It’s only a subtle difference. If you blink you’ll miss it. But, it has far reaching implications on how all of us should be approaching email marketing. Here’s a screenshot of it in all its glory. What you see What your recipients see It’s time we all realized just how important this difference is. Getting your subscriber’s permission is only half the battle. If you’re not relevant, you might as well be a spammer. It’s hard for some to swallow, but it’s really that simple. Whenever someone marks your email spam in most of the popular email clients, they let us know about it. If the number of complaints exceeds a certain benchmark, your account with us might even be closed. Inevitably, this can lead to frustration because you’ve done almost everything right. It doesn’t matter if you had double opt-in permission and your email has an obvious unsubscribe link. If you’re not relevant, you might as well be a spammer. From the horse’s mouth… Still need convincing? All of the major ISP’s have reinforced this position in the last few weeks. They’re giving more filtering control back to their users and the “Mark as Spam” button is the glue holding it all together. Yahoo! Mail – Miles Libbey: Anti-spam product manager Operationally, we define spam as whatever consumers don’t want in their inbox. AOL – Charles Stiles: AOL Postmaster “I don’t care if they’ve triple opted-in and gave you their credit card number,” said Stiles, drawing chuckles, but making his point loud and clear: Relevance rules, and catering to end user preferences is his top priority. Microsoft/Hotmail – Craig Spiezle: Online safety evangelist We need to think really a step beyond opt-in and focus on the consumer’s expectations, relevancy, and frequency. Gmail – Brad Taylor: Google Engineer Sometimes people are afraid to report a message because they aren’t sure if it is “really” spam or not. Our opinion is that if you didn’t ask for it and you don’t want it, it’s spam to you, and it should be reported. Do they really want this email? Like most things, this ultimately comes down to common sense. Put yourself in the shoes of your subscribers and think about what they actually need. If it’s a useful article on something that interests them, send away, but if it’s the latest press release from marketing, I’d think again. Perhaps then you’ll start to see the “Mark as Spam” button for what it really is.
You spend a lot of time crafting your HTML newsletter, tweaking the layout from a previous edition or adding new sections. Then you get to the text entry field, and have to layout the same content again under much greater constraints. To give you some ideas about how plain text can be best formatted for readability, we’ve gone looking for some examples of well designed plain text, and then created some simple text templates from them. Our inspiration (and permission) came from 37Signals, Freshbooks and Good Experience, who all have excellent newsletters that we can personally recommend. Next time you are faced with that empty text field, just copy and paste a template and fill in the sections. If you already do a great job of text formatting, we’d love to hear about it too. Would it make it easier for you if you always started with the plain text from your last newsletter for that client? Let us know with a comment below.
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 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.
We’re big Zeldman fans here at Campaign Monitor. His web standards work has been an important influence in our thinking as web designers and web application builders. So we were disappointed to read his recent post, E-mail is not a platform for design. The core of Jeffrey’s argument is this: But when I say HTML mail still sucks, I donâ€™t mean it sucks because support for design in e-mail today is like support for standards in web browsers in 1998. I mean it sucks because nobody needs it. It impedes rather than aids communication. Essentially Jeffrey seems to be making the mistake of equating the work of bad designers with the communication medium of email. Obviously we are going to be biased, but we’ve heard from enough of you guys, and your clients, to know that HTML email can be a great thing when done correctly. To say as a blanket statement that HTML email impedes communication is an extraordinary generalisation. There are many times when a well designed, and well laid out HTML email can be a lot clearer, easier to scan and overall better experience than the equivalent in plain text. As an example, check out the HTML email sent weekly by Threadless on the right. It’s a smart, simple layout that works in every email client out there. Instead of forcing their subscribers to click on a link to check out each new shirt via plain text, they can preview each design right in their email client. Not only is this a better user experience, but it’s also the reason more than half of their recipients click through to their web site each week. You see a design you like, you click it to find out more and make a purchase. Obviously, there is a lot of really over the top, poorly designed HTML emails being sent, but I suspect that the percentage of really badly designed websites would be pretty close to it. Should we say that all websites impede communication because most people don’t design well? Consider transactional emails, things like hotel bookings and purchase receipts. Every single instance should have a plain text alternative of course, but being able to give the key information like booking dates or serial numbers a bit of visual weight is exactly what designers should be doing – making the experience better for the person on the end. Zeldman goes on to explain: Your uncle thinks 18pt bright red Comic Sans looks great, so he sends e-mail messages formatted that way. You cluck your tongue, or sigh, or run de-formatting scripts on every message you receive from him. When your uncle is the “designer,” you “get” why styled mail sucks. It sucks just as much when you design it, even if it looks better than your uncle’s work in the two e-mail programs that support it correctly. I’m assuming that he is exaggerating for effect here because his earlier link to our CSS support in email in 2007 article clearly shows that it is possible to design emails that work well for almost everybody. For even simpler proof, checkout our gallery of email designs, many of which work in every major email client, desktop and web. Instead of trashing the concept of HTML email based on bad designers and personal preference, it would be much more constructive to continue the fantastic work on web standards in browsers and extend it to the email clients. In fact, the W3C has recently held a workshop on HTML email to investigate the issues and possibilities. We should be thinking about what is best for our readers, and not ourselves. Some people don’t want to receive HTML email, and of course, they should not be forced to. Many people prefer HTML for some uses; who are we to tell them they should not want it? Spam is bad. Shoddy design is bad, and no arguments from us. Saying all HTML email sucks based on particular usages and personal preference is also bad. We should all have learnt by now that we as web designers are not in charge of what technology is going to be used for, it’s the people at the end of the chain who get to decide that. 5 steps to better HTML emails Always send a plain text alternative. Choose “HTML and plain text” as your campaign format. Design differently for email. Good design understands the context it will be seen in. Don’t just paste in your 3 column homepage Test in different email clients. Make sure your message can be read by everyone More copy, less images. You can’t rely on images being seen in emails. Listen to your readers. Don’t base your decisions on what Zeldman tells you, or what we tell you. Listen to your customers, they will tell you what they like and don’t like. Email is not a ‘platform for design’. Email is a communication tool, and sometimes HTML can communicate better than plain text. [UPDATE] Jeffrey Zeldman has responded to our concerns with a well thought out and much more moderate post, Eight points for better e-mail relationships. It’s definitely worth reading.
Join 250,000 in-the-know marketers and get the latest marketing tips, tactics, and news right in your inbox.Subscribe
With our powerful yet easy-to-use tools, it's never been easier to make an impact with email marketing.Try it for free