Browse by...
Home Resources Blog

Blog Post

How to Charge Your Clients for Email Marketing

Like most services a web designer can offer their clients, there are many different ways to approach charging your clients for email marketing. At Campaign Monitor, we’re in a unique position in that we speak with designers charging their clients for email marketing all day every day. Over the years I’ve seen a huge range of billing approaches taken, some which make sense and others that seem plain crazy. We occasionally get asked by customers how they should charge their clients for their services. The truth is, there’s no one approach that works for everyone (you knew I was going to say that, right?). Having said that, out of the different models I’ve seen over the years, there are a few that make the most sense. The purpose of this post is to present you with some of these options and let you work out which approach suits you and your client’s budget best. The popular areas to charge for Over the course of pitching to your clients, designing them a template, getting it delivered and then measuring the results, there are a number of points where you have the opportunity to charge for your services. Of course, most designers won’t charge for all of these areas (though some do), these are just examples of what can be deemed billable work. 1. Template Design (flat fee or hourly rate) This one’s pretty straightforward, just like designing a single page site or a landing page, you charge your client for putting the concept (or concepts) together, then coding the approved design and finally testing that design in the most popular email environments. 2. Delivery (usually dependant on the number of recipients) This is where the range of billing approaches starts to surface. Here are a few of the more popular billing approaches for covering delivery fees: Charge your client a flat monthly fee that covers any campaigns delivered that month Charge them based on a pricing bracket for the number of subscribers being sent to. For example, 2,000 to 5,000 recipients is $150. Charge them a set per/recipient fee. For example, 4 cents/recipient with a flat delivery fee on top, such as $10. 3. Reviewing the results (flat fee or hourly rate) Once the campaign has been delivered, the designer reviews the reports and makes recommendations to the client to improve or maintain results for subsequent issues. For example, you might have tried a different design approach for the newsletter’s “featured product” which yielded a 17% better click-through rate. This is explained to the client and further recommendations might be made. 4. Subsequent changes to the creative (flat fee or hourly rate) Obviously each campaign you send for the client will include new content. These changes can be made much more cost effectively than the original template design. If the client approves any recommendations you made after reviewing the results of a sent campaign, these may also be included in any updates you make. Because of this, 3 and 4 or often billed as a single item. 5. Other services we’ve seen designers charge for While the 4 areas above are the most commonly billable areas of email marketing, I’ve seen designers also charge for the following separately: Testing the design in popular email environments. Cleaning and importing the client’s subscriber list into their account. Adding list subscribe forms to the client’s web site. Processing bounces and unsubscribe requests for the client (even though we do this automatically). Giving the client access to web-based reports on the results or sending them a print-based version of the reports (usually a set monthly fee). List and image hosting fees (even though we offer this for free). The email marketing billing cycle Just like most web sites, an email marketing program is an organic thing that changes over time. Each issue needs to include new content or a new offer, there might be a design tweak you need to make or a new email client to test in. As well as improving your clients relationship with their customers or driving sales, an email marketing program can also provide a great cashflow injection each month. Here’s a quick example of how you might charge a client for your email marketing services on an ongoing basis. Campaign Monitor’s pricing structure was a very deliberate decision on our part. We wanted a system that meant you only had to pay when you got paid, and you weren’t left short if you had a quiet month. Because of this, the “Charge them a set per/recipient fee” approach from the delivery options above usually makes the most sense for our customers. Try and keep it simple From my own experience charging clients for email marketing and also the feedback we get from our customers, it seems that simple is almost always better than complex. Splitting the costs into template design, delivery costs and making subsequent charges is about as granular as most of our customers get and that model seems to work best for most. Hitting your clients with fees for every little detail in the process can certainly be a profitable way to offer email marketing, but you’re also running the risk of confusing some customers. Worse still, you may end up alienating some customers by giving the impression you’re trying to milk them for everything they’ve got (even if you’re not). Finally, email marketing is often sold to clients as part of a wider package that might include a web site or some paid search advertising. Billing for the range of these services can get complicated pretty quickly, so the simpler you keep your email marketing component the better. I’d love to hear how you guys go about charging for your email marketing services. Do you use the approaches I mentioned here or take a different approach to billing your clients?

Blog Post

Some Hard Numbers on Preview Panes and Image Blocking in Consumer Emails

As a nice follow up to Mark’s research into the current state of image blocking in email last week, I just came across an interesting study from MarketingSherpa via Tamara’s blog. They surveyed 1,323 consumers over 18 to find out their email viewing preferences in regards to image blocking and preview panes. We already know preview panes are extremely popular in the B2B market because of the popularity of Outlook, but it’s important to note this survey was targeted specifically at the consumer market. A full 38% of online consumers now use preview pane ‘capable’ email clients and 64% of people who are offered preview panes start using them as their default… Can you imagine if people judged your print ads by just a corner of the creative? Or your TV ads by just a few frames? That’s what’s increasingly happening with email. Consistent with our recommendations back in November 2005, this great comparison really drives home the importance of ensuring the best bits of your email are at least visible in a preview pane. To get an idea of exactly which corner many subscribers will be seeing, they also asked the type of preview pane being used. Turns out that just like business email users, home email users also favour the horizontal preview pane, which makes sense considering that’s the most popular default in those email clients that offer one. Because of this, it’s safe to assume that the most important content in your email should be at the top of your email, and preferably top-left to get the best of both types of preview panes. Another interesting find was that between 35-50% of consumers have images off by default in their email clients. Of course, a percentage of those surveyed would enable images for safe senders and images would still be displayed automatically if you were in their address book. Check out the rest of the survey for the nitty gritty.

Blog Post

Image Blocking in Email Clients: Current Conditions and Best Practices

For the most current results on image blocking in email clients, view our updated post. Many people, either by email client defaults or personal preference, are blocking images in the HTML-formatted messages they are accepting. And then there are a small number of people who block HTML entirely. As David Greiner points out, according to a study by Epsilon Interactive 30% of your recipients don’t even know that images are disabled. In any case, it’s logical for recipients to block images and good practice for us to prepare for this scenario. So what happens to our emails when images are blocked? What are the best practices for ensuring accessibility and optimizing presentation therein? What are default settings across the board? Let’s get down to answering these questions. Default Settings in Popular Email Clients Every client has its own default settings regarding displaying/hiding images. And while most email clients have a setting to turn images on or off, some offer conditional settings which are contingent upon known senders or other factors. The following table outlines the default settings of popular desktop- and webmail clients. (Note that I’m reporting the settings of my personal versions of each client and that settings may differ from one version to another.). I have included contextually-relevant references to ALT text as part of this article. For a more in-depth look at how ALT text renders in popular email clients, you may want to read a more comprehensive article I wrote about ALT text. Image Blocking in Webmail Clients Client Default Img Display Trusted-Sender Img Display Renders ALT Text Yahoo Mail on No No Yahoo Mail Beta on Yes Yes Windows Live Mail off Yes No Gmail off Yes sometimes .Mac on No sometimes Hotmail on Yes No AOL on Yes Yes   Image Blocking in Desktop Clients Client Default Img Display Trusted-Sender Img Display Renders ALT Text Apple Mail on No No Thunderbird on Yes Yes Outlook 2007 off Yes sort of Outlook 2003 off Yes Yes Outlook Express on No Yes Lotus Notes on Yes Yes Eudora on No sort of Entourage on No Yes AOL off Yes No So now that we’ve covered the settings in popular email clients, let’s outline how we can help our emails survive image blocking. Recommendations for Successful Deployment From my perspective, an email is successful when it meets the following goals: Retains visual integrity in the most commonly used email clients with images enabled. Retains readability in the most commonly used email clients with images disabled. Is readable to people with visual disabilities and navigable to people with mobility disabilities. Is low in weight for recipients using mobile devices and dial-up connections. Is deployed to a permission-based list of subscribers. Meets CAN-SPAM Act requirements. Legitimately passes common tests employed by spam filters. Looking at this list it becomes clear just how important it is to consider image blocking when designing/developing an email. Dependency on images can lead to failures on many different levels. Preparing for a scenario in which images are disabled puts us at an advantage to oblige the settings/preferences of a broader range of recipients. Become a “Known Sender” Nearly every email client in my test suite enables people to automatically display images when a message is from a “known sender” (senders appearing in white lists, contact lists or address books). Because our subscribers have requested to receive emails from us, they will naturally want to ensure they receive the messages. Spam filters can disrupt legitimate communication when subscribers are unaware of how they function. With a couple, simple notifications we can increase our chances of success: Ask a subscriber to add the email-list address to their address book (right on the subscribe form) and briefly explain why. Enable a double opt-in subscription process, and send a plain-text confirmation which includes a request to add the email-list address to a recipient’s address book. And, again, briefly explain why. Informing a subscriber about this simple step will increase our chances of images being enabled and will help us legitimately pass through spam filters. Prepare for Disabled Images So we’ve created a structurally-sound template, we’re preparing to send our email to a permission-based list of subscribers and we’ve taken steps to see our list email-address into the address books of the said subscribers. There are still a number of people on our lists who will intentionally block images, and therefore we should account for that scenario. I wrote an article outlining a technique for this very purpose. With the releases of Yahoo Mail Beta and Windows Live Mail we lose the ability to integrate the aforementioned technique. However, Ryan Kennedy from the Yahoo Mail team has pointed out that they are looking into potential resolutions for this obstacle. Positioning aside, there are some things we can do to retain the integrity of our emails when images are disabled: Begin an email with HTML text or logical ALT text. We can decide what a reader sees in a preview pane or small message-window. If we’re prepared, we can optimize the experience of scanning messages. Moreover, some applications offer the ability to preview the first few lines of text before an email is loaded/viewed. Use ALT text. This seems so obvious I’m almost embarrassed mentioning it. However, I don’t have enough fingers and toes to count the email newsletters I receive sans ALT text, so there it is. Use captions for contextually-important images. In lieu of proper support for ALT text across the board, we can add captions to images which are vitally important to the content of an email. Avoid Image-Based Emails Again, this is something which should seem obvious. But image-based emails are often practiced as a simple, easy method of delivering a pretty design irrespective of the rendering circus among the array of common email-clients. When we ponder image blocking as part of the rendering equation, it’s easy to see how an image-based email could be completely destroyed with a single preference. Furthermore, this doesn’t take into consideration file sizes for mobile/dial-up recipients, accessibility for those visually impaired or the HTML-to-text ratio that popular spam filters apply with their algorithms. In summary, we should be giving serious consideration to image-blocking and what we can do about it. It’s natural and reasonable why people disable them, but with the right approach we can improve the experience for our subscribers.

Blog Post

Creating and Using Segments

Something you may not have used in your Campaign Monitor account is segments. A segment is a subset of one of your existing subscriber lists. For example, instead of emailing to everyone on your ‘Alpaca owners’ list, you might just want to send an email to the Huacaya Alpaca owners. That’s a perfect job for a segment. Instead of paying to send your email to everyone on the list, send it to just the people who are most interested in your particular topic this week. You save money, and you can make your email much more specific, hopefully leading to better response rates. Creating a segment To get started with segments, jump into your account. Hit the ‘Manage Subscribers’ tab, and then pick the list you want to work with. You’ll find the segments link at the bottom of the right column. Now you can hit the big green button to create a new segment. You’ll need to give it a sensible name that describes the segment so you can use it later. So, in my example, ‘Huacaya owners’. Create the segment, and you are ready to add some rules. Using rules with segments Rules are what you use to select the addresses you want. For every list, you can create rules that are based on Name, Email address and date subscribed. If you have custom fields in your list, you can make rules based on those too. In my case, I want to create a segment of subscribers who have an ‘Alpaca Type’ of ‘Huacaya’. So I drop down the select box and choose ‘Alpaca Type’, and hit Go. Now I can create my Alpaca Type rule. I would select ‘Alpaca Type equals Huacaya’. (It’s not case sensitive) The full list of possible rule types is: Value: Equals Does not equal Is provided Is not provided Number: Is greater than Is less than Email address: Contains Does not contain Date subscribed: Is before Is after Campaigns: Campaign was opened Campaign was opened – Any link clicked Campaign was opened – Specific link clicked Campaign was opened – No link clicked Campaign was not opened You can combine any number of rules to split your segment as far as you like. Not all of them are available for every field or list. You can also add multiple rules for the same field. For example “Email contains hotmail or Email contains gmail” Each time you save your segment, the count at the top right will show you how many people you are selecting with all the rules applied. You can also hit the link there to see who is in your segment. Segments are smart! Once you’ve finished tweaking your rules, you’ll have a set of subscribers. Every time you come back to check out your segment, and every time you send a campaign to your segment, the rules will be re-applied to your list, and the segment will be updated. So now you when you create a new campaign and select some recipients, your new segment will show up as an option. Huacayas owners will rejoice with their own individual email! More ideas for using segments As well as picking your favorite Alpaca owners, segments can be used in lots of different ways to increase the effectiveness of your campaigns. Here are a few ideas to get you started. Send a special thank you offer to your old school members, who signed up before a certain date. A second chance offer to people who did not click through on your last campaign Target campaigns to certain geographical areas Offer special prices to frequent purchasers Send emails to people interested in certain topics FAQs about segments Is sending to a segment charged like a normal campaign? Yes, each time you send to a segment of your list, you will pay the normal rates (USD$5 delivery fee and 1 cent per recipient). Do I have to update them manually? No – segments are automatically updated before you send to them, and each time you view the segment details. They don’t update ‘live’ because of the amount of processing that would require. Can I do a ‘contains’ rule for custom fields? Sorry, no. At the moment, you can only use ‘Contains’ and ‘Does not contain’ rules for the email address.

Blog Post

How ALT Text Renders in Popular Email Clients

We’ve got an updated blog post on ALT text display in email clients – read it here. So off I went to test how ALT text displays in common email clients, only to find that many of them don’t display any ALT text whatsoever. Unbelievable. And to top it off a couple clients replace the author-defined ALT text with their own idea of ALT text should be (tsk tsk). But before we look at the “how,” let’s look at the “why” in ALT text. Why ALT Text? Any web designer attentive to accessibility understands the benefits of ALT text. It’s cardinal purpose, of course, being that it briefly describes an image to someone who is visually impaired via a screen reader. Screen readers read all of the text on a page, denoting lists, links, headlines and ALT text in images. For example, when loading markwyner.com a screen reader would read something similar to the following: Webpage: Mark Wyner Design, Web Design Studio—Portland, Oregon. Link 1: Navigate directly to content. Page headline, link 2: Mark Wyner Design. Sensible design. Accessible content. Usable interface. Global navigation. Home. Link 3: About. Link 4: Services. Link 5: Portfolio. LInk 6: Contact. […] Note how the screen reader announces the page headline and all links, referencing the latter with numbers. Image ALT text is also read aloud, prefaced with the announcement that the forthcoming text is a text alternative to an image. So the following image: <img src="https://www.campaignmonitor.com/assets/uploads/file.jpg" width="528" height="405" alt="[photo: bowler picking up a Greek Church]" /> May be read as: Image: Bowler picking up a Greek Church A secondary purpose, however, is to describe an image to someone who can not or chooses not to view images in their browsing device or email client. Sadly, the latter doesn’t always work out because many browsers/clients either do not render ALT text when images are disabled or render their own variations thereof. In this article I’ll outline how common email clients display (or don’t display) ALT text. Clients Used in Tests Webmail Yahoo Mail Yahoo Mail Beta Windows Live Mail Gmail .Mac Hotmail Desktop Apple Mail Thunderbird Outlook 2007 Outlook 2003 Outlook Express Eudora Lotus Notes Results A trait shared among all email clients—webmail and desktop—is the ability to disable or enable images by default. And nearly every client in my test suite enabled me to load images directly from the message if they were disabled by default. The exception is Windows Live Mail in which images are loaded for known senders and disabled for unknown senders, the latter scenario exhibiting a link to enable them on the fly. These preferences may be more robust/flexible, but I just tested the basics. ALT Text Display in Common Email Clients Client Renders ALT Text Comments Yahoo Mail N/A Yahoo Mail Beta Applies CSS font-styling to ALT text Windows Live Mail N/A Gmail Sometimes Contingent upon text length .Mac Sometimes Contingent upon text length Hotmail N/A Apple Mail Replaces ALT text with question-mark icon Thunderbird Applies CSS font-styling to ALT text Outlook 2007 Sort of Replaces ALT text with security message Outlook 2003 Applies CSS font-styling to ALT text Outlook Express Applies CSS font-styling to ALT text Eudora Sort of Replaces ALT text with URL to image Yahoo Mail Displays ALT text: no Yahoo Mail Beta Displays ALT text: yes The interesting thing about Yahoo Mail Beta is that applies contextually relevant CSS to the ALT text itself. So although it displays ALT text, the potential problem is that large font sizes can push the information beyond the visible border of the image box, rendering it unreadable. But this is, of course, a naturally occurring problem across the board, especially with smaller images and larger descriptions. Windows Live Mail Displays ALT text: no Gmail Displays ALT text: sometimes Initially, Gmail only displayed some of my ALT text and I couldn’t figure out why. Further testing yielded the conclusion that text length was the deciding factor. Whereas most clients display what text they can within the boundaries of a box, Gmail decides that if the text extends beyond the said border it will display nothing. Nice. .Mac Displays ALT text: sometimes .Mac suffers parallel to Gmail when rendering ALT text, in that it reserves text-length contingencies. Hotmail Displays ALT text: no Apple Mail Displays ALT text: no The clients which do not display ALT text typically display gray boxes in place of the images. Apple Mail, however, displays open space and adds a little question-mark icon. I’m an emphatic fan of Apple products and have been using them for roughly 15 years now. Their products are always very usable and beautifully aesthetic. But I must admit that for obvious reasons it was an ill decision to replace images with a question-mark icon. While this isn’t perilous, it is something to note nonetheless. Thunderbird Displays ALT text: yes As with Yahoo Mail Beta, Thunderbird applies contextually relevant CSS to ALT text. Again, there are no paramount consequences of this result, but it’s noteworthy all the same. Outlook 2007 Displays ALT text: sort of I’ll bite my tongue and stick to the facts on this one. Outlook 2007 prefaces all ALT text with its long-winded explanation of why an image was omitted from a message: “Right-click here to download pictures. To help protect your privacy, Outlook prevented automatic download of this picture from the internet.” This falls down in two very specific ways. First, this is the kind of message which should merely introduce someone to a feature. To repeat it for every image in every email indefinitely is a plethora of information. Second, it pretty much wipes out any ALT text which follows it, given the length of the preface and the average image size in an email. Outlook 2003 Displays ALT text: yes While Yahoo Mail Beta and Thunderbird apply CSS font-size and color properties to ALT text, Outlook 2003 only applies color. I can’t think of a scenario wherein this would have a negative impact, but I feel it’s still relevant to my findings. Outlook 2003 is also the origin of the security-message-replacement woes of Outlook 2007. Outlook Express Displays ALT text: yes Outlook Express is parallel to Outlook 2003 regarding CSS font-properties. Eudora Displays ALT text: sort of Eudora replaces ALT text with an absolute URL to the location of a respective image. I assume this informs a reader where the image can be found, if they feel so inclined to view the image in their browser. But given that the path to the images is truncated, I’m left pondering the value of this system. Lotus Notes Displays ALT text: ? I attempted to get results for Lotus Notes but was unsuccessful in disabling images for the test. I found settings to disable images, but the setting yielded no changes in how images were displayed. I even sent a test to one of my clients who I know uses Lotus Notes at work every day. He, too, could not disable images. If someone can share this information, I’ll update the article to include Lotus Notes results and accompanying screen shot.

Blog Post

How Windows Live Mail and Yahoo Mail Beta Shake Out with CSS

Moving past my angst at recent events, I have tested CSS support in two new webmail clients: Yahoo Mail Beta (YMB) and Windows Live Mail (WLM). The results are a nice blend of excellence and incompetence. Surprised? Didn’t think so. Before I dive in, however, I’d like to preface this article with a particular point of interest. With the release of Outlook 2007 looming it feels oh so very awkward to report on how CSS is handled in other new clients. One might even give in to despair with the realization that irrespective of how a standards-based email renders across the board, it simply won’t fare well in a client used in many offices around the globe. But from my perspective, it’s clear that we need to overcome this obstacle like other web standards of the past: we push the web community (browser/client developers and web designers alike) to embrace web standards in avoidance of regression. It’s a long road, but well worth the efforts. If we backed down from the parallel challenge with standards support in browsers, today’s web would be a very different place. I also want to shed some light on the dark caverns of rendered markup in these new webmail clients. There is a current trend in webmail clients which employs a dizzying level of AJAX to make webmail look more like a desktop application. It’s pretty amazing what these developers have accomplished. Anyway, getting to the actual code of a message for viewing rendered markup was quite labor intensive. I owe my gratitude to Chris Pederick who put together the essential Web Developer extension for Firefox which enabled me to get to the source of my test messages. Yahoo Mail Beta Yahoo is a company dedicating itself to progress in web standards. I continue to see advances with CSS and accessibility on redesigned pages on their site and within their new products. (Go, Yahoo team, go!) The new YMB client is no exception. My tests revealed a webmail client with serious support for CSS. In fact, it’s the best webmail client I’ve tested. They prove that you can support CSS in a webmail client while maintaining security, speed and top features. Take a peek at its beautiful rendition of my test email: However, there is one highly unfortunate CSS property that Yahoo still considers to be problematic: position. In previous articles I outlined how Yahoo Mail replaced all instances of position with xposition, thus rendering them inoperable. Now, however, Yahoo takes this approach to a new level. Instead of making the aforementioned modification, it strips the email of all instances of position. And not just in YMB, but in the original Yahoo Mail as well. So with Yahoo Mail and YMB, all positioning is out the window. Hello float. All said, I think this is pretty minor in the scheme of things. Thanks, Yahoo. Yahoo Mail Beta’s score: “excellence.” Windows Live Mail Where do I begin? I must give the WLM team credit for their advances in support for CSS, succeeding Hotmail by great strides. Not surprisingly, however, they have failed to offer support for many core CSS properties. In some ways this is worse because Hotmail’s handling of CSS-formatted emails yielded an acceptable email, comparable to a rich-text document. With a half-hearted attempt at CSS support, the result is problematic. Let’s take a look at where WLM falls down. Margin Good bye margin. Yep, it’s gone. Every instance. The most significant problems arise when we need to trim default margin to elements like blockquote and need to add to the default margin of elements such as a div: After WLM eradicates my margin declarations, my blockquote encroaches on the sidebar. And note how all of the text is pushed to the left edge of the window because the margin I applied to my paragraphs and headers has been axed. Albeit we still have padding, this creates its own complexities when working with even a moderate level of design. Image Caching Okay, email service providers, get ready to scream. Ready? When WLM opens an email it grabs linked images and downloads them to a local application-directory. So those tracking images you use to report how many times and email has been opened? You only get one hit irrespective of how many times a message is opened. Okay, let it out. Scream! This is how it works: src="https://www.campaignmonitor.com/assets/uploads/logo.gif" Becomes: src="https://www.campaignmonitor.com/assets/uploads/logo.gif" Why does WLM do this? Presumably to cache them for speed. Of course I’m giving them the benefit of the doubt here. (Don’t get comfortable, WLM team—I’m not finished with you.) Personally, I think it’s a nice uppercut to all of us. But I’ll let you folks decide how detrimental this is to what we do. Conversion of Quotes This one is rich. I hope you only want to use fonts with single names such as Helvetica or Georgia. CSS requires that when declaring a value for font-family, two-word names must be enveloped in quotes. So Trebuchet MS must be declared as follows: font-family: "Trebuchet MS", sans-serif; WLM says “no” to quotes in values, so the aforementioned sample becomes: font-family: &quot;Trebuchet MS&quot;, sans-serif; This renders the declaration inoperable, rendering fonts to the browser default. So if our design employs Lucida Grande or Trebuchet MS, per se, we must either accept WLM’s presentation as is and proceed with our two-name fonts or compromise our design with a single-name font. Background WLM strips all instances of background. Good bye background images. While this is problematic for our pretty designs, it poses a threat to a more significant issue: accessibility. WLM strips the entire background declaration, which includes any colors therein. So if you have white text atop a colored background, you’re left with invisible content when WLM is finished beating you up. There is hope, however, in that we can exchange shorthand for longhand when declaring background properties. So: background: #c1d7ed url("https://www.campaignmonitor.com/assets/uploads/bqTop.gif") no-repeat; Becomes: background: url("https://www.campaignmonitor.com/assets/uploads/bqTop.gif") no-repeat; background-color: #c1d7ed; This enables us to retain background colors amid WLM’s background-image cleansing. The result, while less than satisfying, is more or less acceptable. Let’s compare. My test as seen in Yahoo Mail Beta: The same test as seen in WLM: Headers By default, headers (h1–h6) inherit font properties as previously defined in a style sheet. But with WLM, nothing is inherited. So it is important to redefine font properties as necessary. Fortunately the named value inherit does function within WLM. So font-family: inherit; works as intended. Phew. ID Replacement This is by far the worst of the lot, and is reminiscent of the .Mac problem I noted in a previous article. Webmail clients have evolved to ensure that type selectors do not override CSS declarations for the client itself (a problem for which I have illustrated a considerate solution). The common solution on part of webmail-client developers is to add an all-encompassing div to an HTML email, give it an ID or class, then prefix all class- and id-selectors (from the email) with the ID or class from the new div. So the CSS/HTML pair: #Content { } <div id="Content"></div> Becomes: #EC_Content { } <div id="EC_Content"></div> A reasonable solution if it were properly implemented. WLM and .Mac both have their faults in that they fail to appropriately match new parent div elements. Where WLM falls down is that it only applies its prefix in the CSS to the first ID/class selector in an element, leaving child ID/class selectors behind. So the CSS for: #Content #Primary {} Becomes: #EC_Content #Primary {} But in the HTML: <div id="Content"><div id="Primary"></div></div> Becomes: <div id="EC_Content"><div id="EC_Primary"></div></div> Obviously this renders all child ID/class selectors inoperable. The good news is that WLM does not prefix type-selectors in either the CSS or the HTML. So: #Content h1 { } <div id="Content"><h1></h1></div> Becomes: #EC_Content h1 { } <div id="Content"><h1></h1></div> I think we dodged a bullet on that one. Why webmail-client developers can’t get this right is beyond my comprehension. It is vitally important and is an obvious oversight which is now becoming commonplace. Windows Live Mail’s score: “incompetence.” In Summary It comes down to this: Yahoo is leading the way with their support of CSS and web standards, while Microsoft has once again proven they are falling behind. I would gladly stand up and applaud Microsoft for development of a product which offers a high level of support for web standards. But with Windows Live Mail, this is a big “no can do.” As for the Yahoo team, allow me to celebrate your efforts. The first round is on me next time you’re in Portland.

Blog Post

The Truth behind the Outlook 2007 Change and What You Can Do about It

When I posted about Microsoft’s decision to use Word instead of Internet Explorer to render HTML emails in Outlook 2007, I certainly didn’t expect the storm of controversy and (sometimes) constructive discussion that eventuated. The post has already breached 300 comments and made the front page of Digg, Del.icio.us and Techmeme within a few hours. Heck, we even managed to land the number five spot on Alexa’s fasting moving sites on the web. This is clearly a topic many of you are passionate about. So why did Microsoft make this change? In my post, I chanced a guess at Microsoft’s motivations for this change: By default Outlook uses the Word engine to create HTML emails, which it’s done for years now. Perhaps Microsoft figured that in order to keep the look and feel of emails consistent between Outlook users they’d display emails using the same engine that created them. As diplomatically explained by Molly Holzschlag, it turns out that this is exactly why Microsoft made the change. It has nothing to do with security or the remnants of an anti-trust decision. I’m not going to harp on about what I think about this decision – I can certainly understand Microsoft’s motivation for making the change. It’s been made, and the best thing for us to do now is deal with it and use our frustration to constructively encourage Microsoft to resolve the existing issues with the Word rendering engine. What can you do? Molly is currently working closely with Microsoft as part of the Microsoft/WaSP Task Force and points out this refreshing fact – Microsoft is prepared to listen. Please comment as to your experiences and include any links to problem cases. I promise to make sure the top priorities and concerns get in front of the right eyes. Microsoft was very clear in letting me know that if we want a feature and need it and get an organized list to them, those issues will be addressed and prioritized as the new engine develops in response to developer needs, too. As email designers, all we have to do is provide examples of our older CSS based designs that are now breaking in Outlook 2007. The obvious challenge there is that most of us don’t have a copy yet (it’s being released publicly next month), so these reports may take some time to trickle through. At any rate, I encourage anyone who has noticed any discrepancies in their email designs using a pre-release version of Outlook 2007 to chime in on Molly’s post with the URL of your email and a short explanation of what’s breaking. If you don’t have a copy yet, you can also test Outlook 2007 support using SiteVista, which we reviewed recently.

Blog Post

The Email Design Gallery Grows Up

Every few days for the last 2 years we’ve been showcasing the amazing email designs you guys have been producing and sending through Campaign Monitor. This gallery has now grown to well over 100 entries and was really starting to outgrow the current blog format. Because of this, we’ve been hard at work on a brand new email design gallery that’s much easier to browse and really does justice to the quality of work you guys are pumping out. We’ve gone back and tagged every design we’ve featured to date making it much easier to find just the designs you’re looking for. Want to just see 1 column email designs? How about all the newsletter style emails we’ve featured? No problem. On top of this, we’ve now got a dedicated RSS feed so you can get an update every time we feature a new design. We’ll be rolling out a few more features in the coming days that will let you browse the gallery by popularity. To top it off, we’ve got a backlog of some awesome new designs that we’ll be featuring over the next few days and weeks. Enjoy.

Blog Post

Microsoft Takes Email Design Back 5 Years

As I type this post I still can’t believe it. I’m literally stunned. If you haven’t already heard, I’m talking about the recent news that Outlook 2007, released next month, will stop using Internet Explorer to render HTML emails and instead use the crippled Microsoft Word rendering engine. Now c’mon, how bad can this be? First things first, you need to realize that Outlook enjoys a 75-80% share of the corporate email market, which is similar to Internet Explorer’s share of the browser market – they make the rules. We’ve been doing some early testing, as have a few other brave souls, and come February, here’s just a taste of what won’t be supported: No background images – Background images in divs and table cells are gone, meaning Mark’s image replacement technique is out the window. Poor background color support – Give a div or table cell a background color, add some text to it and the background color displays fine. Nest another table or div inside though and the background color vanishes. No support for float or position – Completely breaking any CSS based layouts right from the word go. Tables only. Shocking box model support – Very poor support for padding and margin, and you thought IE5 was bad! Microsoft have released a full run down of what is and isn’t supported, including a downloadable validator that helps you validate your HTML for their engine. Word of warning though, it only works with Microsoft software and Dreamweaver. To give you a quick example of just how far backwards we’ve gone, here’s a screenshot of the Campaign Monitor newsletter (which uses CSS for layout) in Outlook 2000 and 2007. Yes folks, that’s seven long years difference. Outlook 2000 Outlook 2007 This really is a game changer. Previously you could send a HTML email in the comfort that the majority of your recipients would have very good CSS support. Other email clients were also catching up. Thunderbird uses the Firefox rendering engine, the new Yahoo! Mail beta has great CSS support. Things were looking good for us CSS based email designers. Unfortunately, that all goes down the toilet now. If your email breaks in Notes or Eudora, it was often an acceptable casualty, but if it breaks in Outlook, you’re more than likely ostracizing too many recipients to justify your design approach. This certainly doesn’t spell the end for HTML email, it just takes us back 5 years where tables and nasty inline CSS was the norm. Imagine for a second that the new version of IE7 killed off the majority of CSS support and only allowed table based layouts. The web design world would be up in arms! Well, that’s exactly what the new version of Outlook does to email designers. What’s the reasoning behind this? After picking up the contents of my desk off the floor and taking a few deep breaths, I tried to come up with a few decent reasons why Microsoft would go in this direction. Here’s what I came up with. Security – But wait! Microsoft have touted Internet Explorer as “a major step forward in security”. Surely they’d just replace the IE6 rendering engine with IE7 and be done with it. I’d also love to know how float and position impacts the security of an email in any way. Consistent rendering – By default Outlook uses the Word engine to create HTML emails, which it’s done for years now. Perhaps Microsoft figured that in order to keep the look and feel of emails consistent between Outlook users they’d display emails using the same engine that created them. But what about the millions of other email newsletters out there that aren’t created with Outlook or Word? If an email is created with Outlook, then surely it should display perfectly in a modern browser like IE7. They hate us – OK, this one might be pushing it, but I’m running out of explanations here. Don’t get me wrong, we’re not Microsoft bashers here. Both our products are developed on Microsoft’s .NET platform and we’ve been a fan of their development environment for the better part of a decade. But seriously, they’ve taken 5 important years off the email design community in one fell swoop. At least they’ve still got Hotmail, right? Well, no. We’ve been doing plenty of testing with the new version of Hotmail (Windows Live Mail) for an upcoming article and it turns out that like Outlook 2007, Live Mail is actually a step backwards for us email designers. At least Hotmail ignored all CSS (except for inline CSS) and you could force it to roll back to a nicely formatted rich text email. Instead, Windows Live Mail displays some CSS but, you guessed it, limited support for floats and no positioning. It’s looking like table based layouts all round at Microsoft for the next few years at least. Where to from here? We’ve been spending the better part of the last 2 years encouraging designers to embrace accessible and standards compliant email design, but frustratingly that position may no longer hold much weight. Just yesterday, Jonathan Nicol said: None of these limitations is going to make the task of designing HTML emails impossible, but they will ensure that no advances are made in this field for a good number of years. Remember, it’s been four years since the last version of Outlook was released, so I‚’m going to guess it’ll be at least six years before Outlook 2007 drops off the edge of the map. Sadly, I couldn’t agree more. While this is certainly a big blow, the reality is that many of us are going to have to scale back our email templates to years past and stick with tables and inline CSS if we want consistent looking emails in Outlook and Windows Live Mail. For a quick example, our sample email templates use a table based layout combined with some simple CSS. Template changes aside, I don’t see why we have to take it lying down. I’d love to hear your thoughts on this news. Perhaps if we get together as a community and explain to Microsoft how damaging this change really is, we can encourage some real change, or at the very least get the discussion started. What say you, email designers? Update 1: Welcome Digg users. With the anti-HTML email comments rolling in, I just want to clarify one thing here. This has nothing to do with the text/HTML email debate and won’t stop people sending HTML email. All it means is that a lot of HTML emails in Outlook will be garbled and difficult to read. Nothing more, nothing less. Thanks also to those posting constructive comments. It seems this situation might have plenty to do with Microsoft having to separate the browser from the OS for anti-trust reasons. Update 2: We’ve just posted a follow up article that explains Microsoft’s reasoning behind this change and exactly what we can do about it if we want it changed. Update 3: The time for complaining about this change or debating HTML vs plain text has passed. Read why we need to look forward and start doing our own part to improve standards support in HTML email.

Blog Post

SiteVista Launches a Cool Email Testing Service

If you read Mark Wyner’s recent email testing opus you may have despaired at how time consuming and complex it all seemed. Even though you know it is sensible and necessary, it seems like a lot of work. Fortunately for all of us without Mark’s commitment to excellence, SiteVista have today released the first version of their email testing service. SiteVista’s web page testing service has had great reviews, and this new service looks set to match it. So what is an email testing service anyway? Basically, it’s a quick, simple and efficient way to find out how your carefully crafted HTML email is going to be variously displayed or mangled by different email clients. You put your email in, and you get back a bunch of screenshots, just like a web page testing service. Right now you get screenshots from: Outlook 2000 / XP / 2003 / 2007 Outlook Express Hotmail Gmail Apparently more will be added soon, including Apple Mail, AOL, Yahoo! Mail, Entourage and Eudora. For each client you get one screenshot of your email in the inbox / preview pane, and one of the email as it appears when opened. So within minutes you can find out how Hotmail users will see your email, whether your header fits into the Outlook preview pane and what kind of ads Google is likely to run next to it! If you’ve ever had subscribers emailing you saying they couldn’t see that photo, or your text was unreadable, you know why this is a vital service. How does it work? SiteVista have made this incredibly simple. The signup process is quick and painless, and literally within one minute I was testing my first email. To start a new test, you are given a specific email address to send your email to. You fire off your html email to that address, let SiteVista know, and you are immediately taken to the results page. Over the next few moments (from seconds to a minute or two) all the spots in the grid are filled as the screenshots appear. You can click on each one for a full size view, and it is worth noting that you can see the full email, not just a screenful. SiteVista rather grandly call this ‘FullPage technology’. Any problems are easy to spot, and you can then go away and make whatever corrections are needed before running another test. Your account contains a record of all your previous tests, so you can go back and check your results at any time. It’s all fantastically straightforward and logical. How much does it cost? If you are a freelancer, you can have up to 50 tests a month for USD$49, which is great value. Even better, if you sign up by this Friday the 12th, you can lock in your account at USD$39/month for the life of your account. Businesses can have unlimited access for up to 10 people for USD$149/month. For the full details, including annual rates at a discount, check out the pricing page. So you like it then? Yes, we all think it is a great service. There’s a couple of questions I’d like to see the SiteVista site cover, like what screen sizes and resolutions the email clients are at. I also would like to know if the email clients have been left with their default settings or not. Other than that, SiteVista’s email testing service looks like a really useful tool that can save you a lot of wasted time and money testing and sending emails. If you want to make sure you are giving your email campaigns the best chance of success, you need to test them. SiteVista have given us a simple and cost effective way to do that. What do you think? Do you do any cross-client testing for your emails now? Would you give SiteVista’s service a try?

Blog Post

New Legal Requirement for UK Based Customers

A quick one for all our UK based customers. A recent Companies Act amendments now requires additional content to be included in every email you send. As of the 1st January this year, each email sent by a company must now include: Your registered address (not just a valid company address) Your company registration number Your place of registration On top of appearing in all emails, this content must also be included on your web site. From what we’ve read, this doesn’t mean every page on your site, but just your about or legal page for example. You can find out a little more about this over at The Register.

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

Get started with Campaign Monitor today.

With our powerful yet easy-to-use tools, it's never been easier to make an impact with email marketing.

Try it for free