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
Become a better marketer with email marketing content from the Campaign Monitor email marketing team.
Following on from our recent post on automatically generated inline CSS for email templates, another customer has come forward with a cool OSX widget to achieve the same goal. It’s called TamTam, and it’s very simple to use. You simply paste in your html with CSS rules in the head, hit “Inline” and TamTam updates all your inline classes, tags and ids. Thanks to Gary Levitt from MadMimi for a practical (and funky) designer tool.
Update Campaign Monitor now moves styles inline for you automatically – you no longer need to run your HTML email campaigns through an inliner like Premailer prior to send. That’s good news! Creating HTML emails that render well across multiple email clients is complicated by programs like Gmail that strip out CSS styles from the head, and only support inline styles (like <p style=’font-weight:bold;’>A bold paragraph<p>). Our base templates don’t use inline styles because that makes them too inconvenient to easily modify – much simpler to change the design first then apply inline styles at the end. Campaign Monitor customer Alex Dunae has done us all a big favor by writing a sweet Ruby script that accepts a URL, and automatically generates and applies inline styles from the CSS in the head of that page. The script is called premailer and is available for use right now. It won’t always work (with complex CSS cascades), but for most cases it saves you a ton of time. So now you can just build the page in your normal way, then have all the inline style drudgery done for you automatically. As an additional benefit, premailer also checks your CSS against our own guide to CSS support and warns you of possible issues. It’s a great piece of work, and well worth a look. Alex is even planning to release the source code soon.
The response from my call to arms a few days back has been phenomenal. We saw some great comments, loads of inbound links from other designers and some very encouraging “how can I help” emails from many others. As I mentioned in the original post, an important part of moving forward is first establishing a set of baseline standards that we can encourage email client manufacturers to meet. This baseline is crucial as it will form the crux of our recommendations and hopefully shape minimum standards for email rendering across the board. It’s also something you can help with. Working closely with our resident email design guru Mark Wyner, we have established what we think is the core set of features that will form this baseline. What’s important to remember here is that we’re not crossing our arms and demanding perfect standards support. We’re simply asking for the more critical CSS standards to be supported so we can properly separate content from presentation and ensure a simple design will render consistently across all of the popular email clients. With this in mind, here’s the list so far: margin padding float/clear type-selector :hover background-image a:hover background/inline images font inheritance/sizing/line-height UL, OL, DL properties List-style-image background-image positioning borders different link colors content centering This is where you can really help make a difference. Please leave your own comments with anything you think is missing or might not be of crucial importance to standards support in email. Once we’ve received your feedback, we’ll make any amendments and get stuck into the testing/recommendations for each manufacturer. A new site bringing all this together isn’t far off either.
This is a post I’ve been meaning to write for a long time now. I’ve been delaying it purely because I wanted it to be perfect. I wanted to write with Zeldman-like virtue on why email, just like the web, needs to pay attention to web standards. Sadly, in the time between the idea for this post and actually getting it published, web standards support in email has gone seriously downhill. I can’t delay it any longer. My role at Campaign Monitor has given me a great opportunity over the years to research and speak to other designers at length about the standards issue. Each time the topic comes up the result is always the same – getting an email to display consistently in all of the popular email clients is by far the most frustrating part of the job. It’s a painful and always moving target that’s getting harder instead of easier. There’s really no justification for it and it’s about time something was done. Accepting the reality of email today Let me preface this by saying I completely respect everyone’s choice for the email format they prefer to send and receive. I also understand that it probably wasn’t the original purpose of email to go beyond one-to-one plain text messaging. I really do. This is one of the biggest reasons we encourage everyone to include a plain text alternative whenever they send a HTML email. But we need to be realists. Every popular email client supports HTML email and most use that format out of the box. Out of the box means it’s the format of choice for anyone outside of the design and early adopter community and there’s no indication that’s changing any time soon. No amount of angry comments on Slashdot singing the praises of Pine are going to suddenly force email client developers to drop HTML support. It’s just not going to happen. So, it’s not going anywhere and it’s broken. If we can all get past this point together, it’s obvious that the best path forward is to work with desktop and web-based email client manufacturers to improve how HTML emails are rendered, not argue amongst ourselves about personal preference. What’s wrong with the current picture? Today there are at least 10 popular email clients out there, each offering different levels of standards support ranging from perfect to virtually non-existent. I often hear comparisons between the current state of standards in email and the web circa 2000. While there certainly are some similarities, there are also some big differences. The web standards movement faced not only poor browser support, but also an uneducated design community. They had browser makers and designers to convince. Today we’re lucky enough to stand on the shoulders of these giants in a world where web standards have well and truly been embraced by browser developers and the design community alike. People want to build HTML emails using the same approach they build for the web. Another big differentiator is the fact that there were 2 or 3 browsers to consider back then and we knew exactly which web browsers were popular, making it much easier to know where to focus our energies. There is almost no data like this for the email world. Are more of my subscribers using Thunderbird or Apple Mail? It’s almost impossible to know. So, we’ve got 3 to 4 times more variations to cater for and we don’t even know which ones we should be targeting. Because of this huge variation in standards support, email designers have been forced into a corner. There have certainly been valid attempts at encouraging the use of web standards in email, of which I’m proud to say we’ve played a part. The W3C has even jumped on board in realizing something needs to be done here. With the recent and unfortunate news from Microsoft however, it’s been getting harder and harder to justify this approach. What we’re now left with is building for the common denominator. This means bandwidth hogging, image heavy emails with nested tables and font tags. Yes, I said font tags. I see hundreds of these designs being sent every day purely because it’s the only way to achieve consistent rendering across the board. Type in the URL of those creating these designs however and you’ll often find a beautifully coded standards compliant site. Email design truly is stuck in the dark ages. Revisiting the benefits of web standards Many of you are already well aware of the positives web standards offer, but I’ll focus on those I think are particularly relevant to email. It removes the guess work from email design – This is an instant win for designers and everyday email users alike. If all email client developers aimed for something close to web standards, you can design an email knowing it will work for all your subscribers. Stop and think for a second how awesome that would be. Your subscribers will win by no longer receiving garbled, hard to read newsletters because their email client doesn’t support standards. Faster loading and reduced bandwidth consumption – Well coded, standards compliant markup that separates content from presentation is generally much more compact than nested table and spacer-image based markup. Further to this, many designers have given up on rendering issues altogether and send purely image-based emails. This adds significantly to the file size and results in a poor experience for their subscribers because of image blocking. Make your email accessible to all – Using standards does not automatically mean your email will be readable to people with disabilities, but it’s certainly a great start. By separating content from presentation you’re making it much easier for everyone to access your email. Further to these intrinsic benefits of web standards, there’s another significant win that would follow. Using tables for layout is a dying art in the web design community. Many designers who started web design in the last few years have never even coded a table based layout, which is a good thing. The current email environment means a designer not familiar with the table based approach will need to learn a completely different way of creating a page if they want to send HTML emails. We’re fast approaching a fork in the road where email design will become a niche, expensive service that fewer designers can provide. Sure, a few designers win by being able to charge more for their work, but everyone else loses. Where to from here? This much is clear – arguing about HTML vs plain text or complaining about standards support in email isn’t going to get us anywhere. It’s time to get off our butts and actually help email client manufacturers to introduce better standards support. I also think it’s important to realize that these manufacturers don’t have a problem with web standards. Supporting standards might not always be the easiest option, in fact for web-based providers I’m sure it’s quite the opposite. It’s our job to demonstrate why they are important and then make them as easy as possible to embrace. We’ve been hard at work on this for the last few weeks, focusing on the following areas: Establishing a baseline of what standards we need supported in email – We certainly don’t expect perfect standards support across the board initially, but there are a number of key properties that we can encourage manufacturers to support sooner rather than later. Document the important changes each of the major email client manufacturers need to make in order to support web and related standards – Once we’ve established the baseline, we can put together a basic wish list of the changes each manufacturer will need to make to meet this target and then work with them in any capacity possible to help make this happen. Create a simple acid test that makes it easy to see if an email client supports this baseline – Much like WaSP’s Acid2 test, we should make it easy to see if these important standards are being supported by creating a simple test page that can be viewed in that email client to confirm at a glance if the baseline is being met. We plan on bringing this all together in a dedicated site launching soon. Obviously the more of us that can get behind this the easier the job will be. Even the king of web standards, Jeffrey Zeldman agrees (emphasis his): Learn how HTML mail works (or doesn’t) across as many platforms as possible, and work with the manufacturers to improve support for web standards. This is not my job. I did my job where web standards are concerned (you’re welcome!), and turned over The Web Standards Project to a new generation of leadership. And as I never send HTML formatted mails, not only is it not my job, I wouldn’t even be qualified to do it. But standardistas who are compelled by their clients to create HTML mails (or who choose to do so) are gently urged to do their part in diminishing wasted bandwidth and enhancing semantics. We’ll be posting more about this initiative soon, including how you can help make a difference. Jeffrey’s right, it’s not his job – this one’s up to us. Update: You can start helping right now. Check out the initial list of baseline standards that should be supported and add your own thoughts.
On September 5th, New Zealand’s Unsolicited Electronic Messages Act 2007 comes into effect. For Campaign Monitor customers, this should have little impact, because it is essentially just requiring that New Zealand businesses have direct permission to email people, and always provide an unsubscribe link. Our permission policies already extend beyond that, so you won’t need to do things differently, even if you are from New Zealand. However, it is another piece of ammunition for you to use when discussing permission with your clients, to show the growing international agreement on the importance of respecting peoples email addresses and right to control what arrives in it. Mark Brownlow has a good collection of anti-spam laws around the world, helpful if you need to check for a specific countries legislation. Don’t forget though that just complying with the relevant laws is not enough anymore. You have to ensure your emails are relevant too, or risk being blocked and filtered in the same way spam is.
When we launched our new email authentication system last week, we had no idea how well it would be received. To be honest, authentication can be a tricky concept to get your head around and I was a little nervous about how popular it would be. Sometimes I love being wrong. In less than a week hundreds of authenticated domains have been set up, many with an authenticated domain for each and every client. It’s been fantastic to see and a great result for everybody. Your emails have a better chance of being delivered, ISP’s know who you are and your domain is being protected from abuse. A number of customers have also been kind enough to send in instructions and screenshots walking through how they added the records with their own hosts. This is hugely appreciated. If you’ve set things up and don’t see your host listed, we’d LOVE for you to send through the steps and screens so it will be that much easier for your fellow Campaign Monitor designers using the same host. Of course, it hasn’t been smooth sailing for all. Almost every host out there has a different front end for managing your DNS. Some make it a breeze, others like to see you sweat. We’ve even discovered a few hosts that don’t support TXT records (and therefore authentication) at all. Sigh. We’ve put together a quick authentication FAQ for those of you that are having trouble getting your records added. We’ve found that with a little persistence even those claiming not to support it can bend their rules if you ask nicely.
Here’s some more evidence for the great and growing depth of design talent working with email newsletters. The latest few take the total to over 150 different designs. Subscribe to the gallery’s RSS feed to keep up to date as the list grows.
Anyone trying to pay for a campaign for the last few hours would have noticed a frustrating “Server busy” message. Our sincere apologies for this. Turns out our payment gateway is having some unscheduled downtime. We’re working with them as I type this and will post an update here the moment they’re back online. Not that it’s any consolation, but we’ll be moving to a new and more reliable merchant provider in the next few weeks. This one’s frustrating for everyone. Update: We’re back online and accepting payments again. Thanks so much for your patience as this issue was resolved and apologies again for any delays this caused.
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.
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