“Blown away by how easy your system is to use”

“This is my first time using Campaign Monitor after loving your MailBuild service. Again, I was blown away by how easy your system is to use!! After coming from a competitor and having to manually hard code each image reference, it was a beautiful thing just providing you with a URL and you taking care of the rest with a single click. I love it!”
Shona Friedman — Eye Design Studio
Read this post Posted by David Greiner

How to test HTML emails

Whether I’m developing a website or an HTML email, I spend a good deal of time testing. I run my files through a large suite of browsers and email clients, and my process is thorough. There are some things I test for globally and others which are specific to the target audience. In any case, my process is extensive because my goal is to maximize accessibility.

I am often asked how I test emails. This article will outline that process including what I look for when I test, how I test for various viewing scenarios, what techniques/utilities I use for debugging and what email clients I use in my suite. You might recognize the process as part of your own, learn something new about testing or even curse my efforts as useless. I feel that my testing process is efficient and effective, but I’d love to learn something new about how my peers are testing. Comments are a good thing.

My Suite of Test Devices

To ensure my work accommodates people using all of the three most common desktop platforms (Macintosh, Windows and Linux) I have them all at my disposal. I design/develop on my Mac (as I have for over a decade) and have the other two on standby. Because I use a Mac Pro I can run all three platforms on a single computer (I’m running Ubuntu—an amazing and free Linux platform—and Windows XP), thanks to the glorious Parallels application:

[screen shot: Ubuntu platform]

I also test on as many alternate devices as possible. This is most challenging because there are a plethora of mobile devices with an equally intimidating number of browsers and email clients. I do what I can with my Zaurus (Linux), my Treo (Palm OS) and my Blackjack (Windows). And I profusely apologize to my colleagues and friends as I occasionally beg them for test runs on their devices. Quite an annoyance, I’m sure.

My Suite of Test Clients

There is a lot of data to support a general consensus about the most widely used email clients and web browsers, but I also ask around to learn what people are using. This gives me a great foundation for where I should focus my efforts. However, with strict goals for accessibility I test for an extremely broad collection of clients/browsers. Some may call it extensive or even gratuitous, while I call it thorough and considerate. My suite of encompasses the following clients:

Mac OS X

Apple Mail 2.1
Entourage 10.1

Windows XP

Mozilla Thunderbird 1.5
Outlook 2002
Outlook Express 6
Eudora 7
Lotus Notes 6.5
AOL 9

Linux

Evolution Mail 2.8
Mozilla Thunderbird 1.5

Webmail

.Mac
Gmail
Yahoo (original and new beta)
Hotmail
Windows Live Mail
AOL

Handhelds

Palm Versamail (Treo smartphone)
Linux EMail (Zaurus PDA)
Outlook (Windows mobile)

Deployment of Tests

For Campaign Monitor customers who are logged in to the admin system, sending test emails is effortless. Simply navigate to the “test campaign” utility under the “create/send campaign” tab, enter the basic information and you’re set:

Sending a test in Campaign Monitor - updated

I point all of the desktop/handheld clients in my suite to an IMAP account which I’ve created solely for testing. This enables me to send tests to a single address, then view the results across the board. Webmail accounts, however, are unique and consequently need to be tested individually. But the aforementioned test utility allows concurrent delivery to three addresses. So testing in six webmail clients is still simple and quick.

Through countless tests I have learned (as we all do) what general markup will succeed and fail in various clients/browsers. This knowledge enables me to send an initial test which most often works fairly well across the board, sans a handful of unanticipated hiccups. Then, as I work to resolve the complications, the testing suite dwindles until I am satisfied with the results in each client. Campaign Monitor’s test utility enables me to quickly resend tests, and the IMAP setup enables me to view the results only in clients needing attention.

My Approach to Presentation

There are two fundamental ways to markup the presentational layer of an HTML document, each having its own benefits/compromises: standards-based CSS for all presentation, or table-based layouts which envelope font/color tags for text formatting. From my perspective, there is no contest between the two approaches. However, for those less educated about the pros and cons I'll outline the basic concepts.

Font Tags and Tables

While this approach offers a fairly consistent visual presentation across most email clients, it comes at a high price:

  • Embedded presentation layers weigh down an email, slowing down rendering times for mobile devices and people with dial-up connections and increasing fees for people using pay-per-kilobyte mobile plans.
  • Table-based layouts render horribly on small-screen devices and are nightmares for disabled readers who must navigate using key/verbal commands.
  • Table-based layouts are challenging to integrate into CMS solutions and to segment for templates.
  • Redundant, inline presentational-markup complicates maintenance.

Standards-Based CSS

While web professionals are increasingly adhering to web standards, the debate about using them for HTML emails is still quite fiery. And because of my articles on the topic I’m typically a target for misinformed, plain-text-email evangelists. The benefits of web standards in the email environment is no less impactful than on websites. If anything, they’re more important because of the increasing number of people using mobile devices to access email.

The benefits of using web standards to mark up emails is obvious:

  • Reduced file sizes are considerate of mobile readers who pay for every kilobyte they download and for people using slower, dial-up connections.
  • The content is accessible to everyone, is fluently read by aural devices and is easily navigated by those using assistive devices.
  • Clean segmentation enables easy integration with CMS solutions.
  • Presentation is maintained in a single location, ensuring global changes are quick and simple.

There are a couple of compromises one must accept when using CSS for presentation:

  • Visual design is reduced to something not unlike a rich-text format in some clients.
  • Formatting is lost when forwarded from many clients.

A Word to the Wise

Irrespective of my stance on this debate, there will always be a client who believes design integrity across the board is significantly more important than accessibility or catering to a mobile-device audience. Consequently I have learned that it is vital to discuss these approaches with my clients before engaging in a project. Failing to have this conversation upfront will inevitably result in hearing a client say “this doesn’t look good in Hotmail” or “when I forward this from Outlook, the formatting is lost.”

My Goals

There are many viewing scenarios to consider which vary more wildly in the email environment than within web browsers. This is primarily because security and spam are of great concern in our inboxes, but also because of the increased use of mobile devices. I believe my approach to preparing for each of these scenarios yields appropriate results across the spectrum of clients. I have specific goals for each scenario—all focused on accessibility—and test for these specific results accordingly. Following, are some of these specific scenarios.

Text-Only Clients

Many people use non-graphical email clients, especially in the mobile arena. These clients either display the plain-text segment of a multi-part email or extract text from the HTML. Take a look at how Lynx (popular non-graphical browser) renders HTML into a text-only presentation:

[screen shot: email in text-only format]

Note how there is some formatting which helps the reader distinguish headlines (flush left) from paragraphs (indented). This is possible because the headlines are marked up appropriately with H1, h3 and P tags. Font tags and tables would produce something much less readable. Also note how I compose ALT text, using all-encompassing brackets. This is something I do by default to help readers distinguish ALT text from regular content when viewing HTML sans images. And I prefix ALT text with a description of the image (in this case “photo:”), which denotes what type of image has been omitted.

I test for text-only presentations using Lynx, Palm VersaMail and Linux EMail (default email application on my Zaurus handheld).

Disabled Images with CSS Support

Images can be manually disabled, and are disabled by default in a handful of clients. As David Greiner brings to our attention, Epsilon Interactive conducted a study which reports how 30% of our recipients may not even know images are disabled. My approach to image integration is pretty simple, I use CSS backgrounds for all images which are part of the core visual design and only use embedded images (<img>) for contextually relevant images.

The big challenge surfaces when images are disabled in a graphical-client that supports CSS. In this scenario, CSS-background images would disappear leaving no ALT text. However, there is a solution to this problem which I outline in another article. I believe it yields acceptable results:

[screen shot: email with images disabled and CSS enabled]

The title of this email, “Digital Web Magazine,” is exhibited with an image of the publisher’s logo. With images disabled in a client that supports CSS we retain visibility of a title. Perfect.

I am able to easily test how my email will appear with disabled images using an amazing Firefox extension which is invaluable even beyond testing for disabled images. I highly recommend it for every web designer.

HTML Capable Clients with no CSS Support

Many HTML-capable clients do not support CSS. In this scenario, CSS shines bright. “Why?,” you say. “It’s gone.” I use CSS for my entire presentation and semantic markup for the content, so when the CSS is removed from an HTML document the result is a readable email, visually similar to that of a rich-text document:

[screen shot: email with HTML formatting and no CSS support]

This is where those seeking pixel-perfect designs across the board begin to recoil in horror. I feel this is an acceptable sacrifice to ensure accessibility for everyone, though many clients would disagree. And this is where the aforementioned pre-project discussion will come in handy. My clients are prepared for this scenario, safeguarding me from a mid-project debate and potential situation requiring me to recode an email using font tags and tables.

Testing for this scenario is simple using the aforementioned Web Developer Extension for Firefox, wherein CSS can be disabled with a single click. But it is advisable to set up Hotmail and Gmail accounts for real-world testing. Both of the said webmail clients support HTML and disable CSS by default.

Screen Readers

Aural devices obviously ignore all visual design. But that doesn’t mean all visual elements disappear completely. For example ALT text and link titles are read aloud and lists are denoted as such. Thus it becomes obvious just what kind of impact our markup can have on a visually-impaired reader.

Testing for aural devices is incredibly challenging because they simply aren’t widely available without paying significant license fees. The popular screen readers on the market are well worth their weight in gold to those who need them, but for developers the expense can be intimidating. However, there is an open source screen reader available for the Linux platform called Emacspeak. Thanks to the aforementioned Parallels application and respective Ubuntu Linux-platform on my Mac Pro, this is what I use to hear my websites and emails.

Spammers and Standards Compliance

I would like to conclude this article with a note about the deployment of mass emails, just so we’re all clear on my intentions.

I have written a handful of articles about techniques for successfully deploying standards-compliant emails. Consequently, I have been labeled a “spammer,” an “email marketer” and outright “evil” in blogs around the web. I have also received some emails exhibiting a level of anger I would expect if I were clubbing seals. And the debate about whether or not we should even have HTML emails fuels the fire for these evangelists.

My articles are intended to help legitimate companies send legitimate emails to an audience of subscribers. Permission-based email deployment is not evil and spammers do not take the time to ensure their emails are standards-compliant. I welcome a debate about use of HTML in the email environment, but I would like to ensure that my intentions are not misconstrued.

I have clearly outlined the importance of CAN-SPAM ACT compliance, do not work with clients who disregard the importance of a permission-based email-communication system and do not support use of rented lists for mass marketing. The benefits of web standards are clear, and my hope is that this information will encourage people to accompany their standards-compliant websites with standards-compliant emails.

I’ve said it before and I’ll say it again: if we have to build HTML emails, we may as well do it right. I am willing to go the extra mile to ensure accessibility—how about you?

Read this post Posted by Administrator - 27 Comments

Getting opt-in permission offline

Professional trade show presenter Heidi Miller based a recent episode of her “Diary of a Shameless Self Promoter” podcast around the concept of email newsletters and spam. Heidi, who collects a lot of business cards through her work, had mentioned previously that she was considering taking email addresses from those cards and signing them up to her newsletter.

Several callers to her show suggested (correctly) that without explicit permission from those contacts, subscribing them to her list could be considered spamming. One of the callers described a great method to handle this specific situation.  When she meets people, she specifically asks them if they would like to receive her email newsletter. If they say yes, she has them write ‘Yes to Newsletter’ on the back of their business card. Conversely, if they say no, she notes that on the card instead.

That way, when she processes the new contacts after a convention or show, she has a clear indication of who has opted-in and who has not. Nobody is accidentally subscribed and she always has the original permission to refer to. If you deal with a lot of offline permission situations, you might consider adapting this to your situation and put it into use.

When you add new subscribers to Campaign Monitor, our anti-spam policy requires that you have clearly explained that you will be contacting them by email. This technique could be part of a good permission management process.

Do you have any experience dealing with getting permission offline? What’s your process?

Read this post Posted by Mathew Patterson - 6 Comments

Image blocking, alt tags and why CSS rules

For the most current results on image blocking in email clients, view our updated post.

I read an article on Clickz today by Jeanne Jennings on the current state of image blocking in email. Jeanne tested 30 random B2B and B2C emails in her inbox on their approach to image blocking.

While the results were mixed, I was very surprised to see her suggest that image alt tags might not even be worth the effort. She cited the instructions Outlook 2003 places before the alt text for every image (explaining the image is blocked and how to show it) as the reasoning behind this.

It’s a mouthful. And it precedes any alt tag text the sender might have included. So even when there were alt tags, they weren’t prominently placed or easy to read or skim. Based on this, the value of alt tags is minimal. I’m not sure I’d bother.

The only problem with this assertion is that not everyone uses Outlook 2003. In most of the popular email environments, such as Yahoo, Gmail, Thunderbird for example, alt text is displayed unimpaired for every image in your email and can go a long way to encouraging your recipients to enable images. But there’s another benefit that needs to be considered.

What about accessibility?

To many email readers, there’s an even more important reason to ensure descriptive alt text for every image in your email - accessibility. Any of your recipients who are visually impaired use the alt text you specify for each to get a better understanding of your email content, especially if that image has some relevance/importance to the content of your email.

Jennifer Kyrnin has put together some nice suggestions on how to write alt tags for accessibility that are worth a look.

The magic of CSS

While alt tags are extremely important, there’s an alternative CSS technique we can use in our HTML emails that in my opinion beats the pants off the old images/alt text approach.

This technique, explored in detail by Mark Wyner a few months back, includes the use of background images via CSS instead of simply placing the image in your XHTML/HTML content.

Using this approach, Mark can display styled and well formatted alt text when images are off, replaced with the image itself when images are on. No ugly placeholder images with a big red X, no messy instructions in Outlook, just a nicely styled text alternative or the image itself. Further to this, the content is completely accessible for the visually impaired. Talk about a win/win! So, I guess the takeaways are:

  1. Always use alt text for the images in your email
  2. Try to keep them as descriptive as possible (see here for more on this)
  3. If possible, try and use the CSS background image approach to avoid the ugly placeholder issue altogether.
Read this post Posted by David Greiner - 2 Comments

Gallery: Buyolympia.com Newsletter

See the complete email designIf you are looking for something a little bit different for your email template, you’ll enjoy this design for buyolympia.com, a 2 person provider of all kinds of interesting things from Olympia, Washington.

The two column layout is busier than the typical newsletter, and almost feels chaotic, but it suits the quirky products and friendly style of the company.  There is enough structure there to hold it all together and keep it readable. A great example of designing for a specific context and a particular audience.

Designer:  Pat Castaldo  |  See the complete design

Read this post Posted by David Greiner

Gmail testing just got a whole lot more important

GmailLet’s face it, a big chunk of us designers love and use Gmail. While it certainly doesn’t have the market share of the big guys like Hotmail and Yahoo! Mail, it’s definitely a favorite amongst the design and early adopter communities. If you’re reading this blog, you’re probably also well aware of the fact that Gmail plain sucks to send HTML email to. It strips out all but inline CSS often murdering that nice email design you’ve spent so much time crafting.

At least it’s always been pretty easy to identify what percentage of your subscribers are using Gmail and make a decision on how much compatibility work to do accordingly. Well, those days are limited.

A few days back, Gmail launched MailFetcher,  a great new service that allows you to check all of your POP email accounts within the Gmail interface. This means regular old emails sent to bob@jones.com or even bob@yahoo.com might actually be opened in the Gmail interface, and as such be butchered accordingly. If you haven’t already, this is even more reason to add Gmail to your email testing roster, which we’ll be writing more about here shortly.

Read this post Posted by David Greiner - 3 Comments

Gallery: La Cloche Newsletter

See the complete email design

Today we’re highlighting a very slick monthly newsletter for New Zealand based La Cloche French Delicatessen. This is no average deli either, with Wellington’s finest selection of wine, cheese, and fine French food on offer.

The newsletter promotes any special upcoming events their customers might be interested in, such as an upcoming tasting evening. To tie it all together, the email also features a great background about the specific region of France the tasting menu is sourced from.

The design itself is simple, easy to read and looks fantastic. A regular newsletter like this is a great differentiator that keeps the La Cloche offerings fresh in the minds of their customers.

Designer:  Chris Webb  |  See the complete design

Read this post Posted by David Greiner

Update: Maximum number of custom fields doubled!

When we overhauled our custom field support back in February, we made the decision to cap the maximum number of custom fields to five (which we explained here). Over the last ten or so months, the ability to support more than five custom fields has been one of the most requested new features we've had. Ever. Now that we're successfully purring away on our new hardware, we figured it's time to double the number of custom fields you can have from 5 to 10. Hopefully that makes things a little easier for those of you who need to store a little more information on each subscriber.
Read this post Posted by Ben Richardson - 5 Comments
  1. 1
  2. 2

Sign up for free.
Then send campaigns for as little as $9/month

Create an account