Why the shift to HTML mail after 17 years of plain text? Sometimes you just get dragged into the present, despite your best intentions…
I did one of my occasional romps through the unsubscribe folder recently and found two reasons that accounted for around 90% of the unsubscribes. “I get too much email in general” was the biggest. That’s fairly standard. I only worry about that one when the ratios change. It sometimes means I need to do more nuts and bolts stuff or add more humor.
The second was formatting. That’s new.
There were always a few of those, mind you. Back when plain text was the only way newsletters got delivered, people would complain about line lengths. Others griped about the four dots dividing sections, or the short paragraphs.
Still, this has gotten more prevalent and more specific. People want mail in HTML format, and they want it to work on any device. They don’t want to be chained to their computer. And they’re in the majority now.
Fair enough. Multi-part mail is easy these days.
So, time to do some research. I’ll share some of what I found in the process.
First, you have to ask: What are the benefits of HTML mail?
To be clear, it doesn’t mean abandoning your plain text readers. You can include a text part for folks like me who prefer it. If nothing else, at least include a link in the text part to a blog or other online version.
Next, you can include links to various regular resources without cluttering up your message. That can mean a section with links to recent blog posts, social media, and product pages.
It also makes it possible to track the open rates and clickthrough rates for your messages. In addition, depending on the service you use, it can let you see which links in the message are getting the most clicks.
If you want to know what’s working and what isn’t in your emails, that’s critical. You’ll never get a 100% accurate picture, because of people like me who don’t load images by default. Still, the ratios are enough to give you the data you need.
I’ve heard claims that mail with an HTML part is more likely to be delivered to the inbox, but I have serious doubts about that. What does not appear to be in question is that well-designed HTML mail is more likely to be read and results in higher clickthrough rates.
Better numbers, better ability to track the numbers, and more reader-friendly.
Sounds like a plan to me.
The first thing I did was an informal and thoroughly unscientific audit of the GMail box where I get most of my subscriptions. It gets mail from around 200 legit senders, so it’s a decent sample. At least for this market.
First thing: Very few people send just plain text any more. I hadn’t been aware of how small a segment it was, because I usually read mail in my desktop mailer (Pegasus), and have that configured for plain text. I only notice when there’s no text part.
I was looking more at the formatting than anything else at this point. In my sample, it seems the majority of people who’re branding themselves by their personal name use very simple formatting. It looks like plain text, but with links on words or phrases.
The senders who are branding more on a company or site name tend to use templates. Most of them are responsive.
For the folks who may not have heard that term, responsive email formatting just means the layout adjusts based on the screen size of the device it’s being read on.
As often happens, though, the exceptions explained the rule.
The senders who were branding their personal names used templates if their emails regularly contained multiple topics or sections. The company or site branders tended to use plain formatting if they sent single topic messages.
By single topic, I mean promos, notes about a blog post, and similar emails where the purpose was a click on one specific link.
That makes sense.
Then I dug into what I could find about how people read email on mobile devices. I was not all that surprised to find that a lot of people look at email before they get out of bed in the morning.
I was very surprised to see the high percentage of folks who get personal and business email at the same address. I thought I was an exception in that regard.
It was less surprising to discover how many people make purchases of digital info using a phone. That tells me I need to consider making downloads available in immediately usable file formats, rather than as zip files.
It’s not as secure from piracy, but it would be much more convenient for my customers who use mobile devices.
Gotta think about the best way to balance those.
Okay. That was a good beginning. Guidelines for changes that may need to be made.
Now for the tech.
Looked around at some responsive templates and settled on one as a starter. The goal is to see how people use it, first. Then tinker with it to make it more convenient based on what they show me they want, by watching the numbers.
I also wanted a template that could be trimmed down for one topic messages without losing the consistency.
That part was easy. Getting a “final” template will take some time, but that’s always going to be the case.
The big question was the CSS. Played with that until I got something that worked well enough on the “big screen.”
Before you send it, though, there’s the question: Should you use CSS in the page head or “optimize” for inline styles?
The info I found all suggested that inline CSS was better, and would display more consistently on various devices. I also saw some claims that GMail stripped the head elements from emails, which would render the styles useless unless they were inline.
Do not believe everything you read.
I used MailChimp’s tool to incorporate CSS inline in a message and sent it to a test list. It worked okay on an Android phone, iPad, GMail via the browser and apps, and in Apple’s Mail app.
In Pegasus, though, it rendered lines over the top of each other and just garbled the whole thing.
The same message with the CSS styles only in the page head displayed fine everywhere I tested. Including GMail and Pegasus.
Here’s the kicker. A message using this template and very little content was 15 kilobytes with the CSS just in the page head. Using inline CSS, the exact same message hit 37kb.
It doesn’t take much content at all to push a message over 100kb (non-graphic content) at that rate. Odd things can happen to delivery rates when you get over that mark.
Again, this is hardly a scientific study. Still, it works on my 4-year old Android phone in both email apps, and doesn’t break in any major browser on the PC, Mac, or iPad. It’s probably going to work for the majority of people.
It pays to test things for yourself.
At this point, I’m not seeing any benefit to inline CSS.
The rest is just design stuff. I don’t expect to use a lot of graphics, but you may. Including those is something you need to learn from your list host. It varies, sometimes a lot.
One big issue that would be easy to overlook is spacing links. If many of your readers use phones for email, you will want to leave enough room to avoid accidental clicking of the wrong link.
This is where the “rule of thumb” becomes a literal thing. You want to leave enough room that someone can use their thumb to click without being likely to hit the wrong link, or more than one at a time. For icons, that means about 45 to 50 pixels for women, and around 60 pixels for a primarily male audience.
For menus, that may be an unrealistic standard. It would lead to clumsy and overly simplistic layouts. Still, it is something to keep in mind when choosing or creating a template.
I won’t even get started on graphic widths, other than to say they should be clear and easy to read if rendered at 600 pixels wide. The real key is to keep file sizes down. Every second of download time for an image loses you a significant percentage of readers, and they do not tend to come back to the message later.
For a good compressor that doesn’t screw up image quality, check out “FastStone Photo Resizer.”
The delay in going to this format will seem odd to the folks who’ve known me for a long time. I was one of the first people (if not the first) to offer HTML autoresponders, back in the late 90s. The automation was a pain (read: nearly impossible to do securely) at the time, and too few email clients supported it, so I dropped it.
At this point though, the numbers have completely flipped. Bandwidth and storage costs have dropped through the floor. I can store years worth of email archives in less than 10% of the storage space on my phone.
More to the point, the number of people who can’t read HTML mail is so small it’s not a viable concern from a marketing perspective. Not when using plain text loses more readers than using multi-part mail will.
Layout and content strategy is a whole other issue. There are too many options there that can only be evaluated with testing.
I’ll probably stick to a very simple version of the same format for single-topic emails. The usual stuff, which covers more than one thing, will probably involve a plain text version, along with shorter “catalog copy” summaries in the HTML version, with links to the blog or a standalone page.
Super-short messages, or time-sensitive stuff, may even be in plain text.
And, of course, there’s always the Marketing Prime Directive: “Everything is a test.”
Thoughts on this? Or comments on the format, from you folks who get the newsletter? Fire away.
So, despite the results of my tests, the issue I sent out saying inline CSS didn’t seem important proved that it is.
Gmail butchered the formatting this time. Same layout as yesterday, and the same CSS in the head section. Yahoo screwed it up, too, but that was expected.
[sigh]
Does anyone understand the rationale behind GMail nuking CSS in the head of an email?
Gmail isn’t the only one who will nuke CSS in the head. It is not a matter of nuking it ALL sometimes. Since these email services work in a browser – the browser may read your email as a separate page and REALLY screw up the browser. So to eliminate any chance of the browser doing this; they nuke the code.
The HTML rendering engines in most email clients only support HTML 1 ad CSS 1. For those who deal with “modern” websites, you may be putting in language the email client won’t understand and nuke your email.
If you use this site to check your email (which it does for mobile) it will guide you what will work. A proper “mobile website” is VERY simple HTML since it will render properly in ANY mobile browser.
http://validator.w3.org/mobile/
Here is something you might find useful too.
http://premailer.dialect.ca
I have also been a “text only” email guy since there is no problem with formatting. I have been doing research into this since I was also researching these “mobile” web sites. Since “everyone” says every business needs one. I haven’t actually found too many n the wild though.
It reminds me of coding websites for Netscape… 😉
Very handy stuff, Leonard. Thank you!
It mostly works for me. I use gmail, with Chrome as my browser of choice, usually. Most of the links, like this one http://clicks.aweber.com/y/ct/?l=AS4HN&m=8S7NTqMcYNWcx&b=sDb9_Dg5b5NxtPGTjvmZ2g are botched.
It seems like it should say: “Read More”, but instead it ends with A with a carat over it followed by a double forward arrow. All of the Useful Links are like that. It must be a format code that’s not getting interpreted.
I recognize the A + hat, it’s an “alternative” interpretation of the #160 (I think) code used for a Unicode non breaking space (as used in XML rather than HTML for example).
I has just going to drop a note to say “tiny font in my web browser”
Got the A in the web browser and in Outlook 2007, but the font was “normal” there, though the font face varied a bit.
That circumflexed “A” is the single most common thing mentioned in the feedback. Way more than the switch to HTML, in fact. Strangely, it shows up fine in every browser on my system.
I’ve either got to figure out why it gets encoded this way on sending or just substitute different characters. Anything that distracting has to go.
I like the new HTML functionality of your email newsletter but miss the folksy intimacy of plain text.
Regarding the four dot separations some have had trouble with … they sooth me – keep the content clean & digestible.
Despite today’s shorter attention spans, I’ve yet to find your lengthy content a problem. It isn’t fluff and you are attentive to important detail.
Good work Paul.
One of the smartest people I ever knew always said when you have something that works, why fix it?
[chuckle] True enough.
The problem is, it isn’t working any more. Not when measured against the majority, who seem to prefer the easier reading of HTML.
I personally prefer plain text, but the feedback and previous comments are pretty clear. If it ain’t easy on mobile, it doesn’t get read. And a lot of people are trying to read it on mobile devices.
It would be easier if I knew folks could easily switch to the plain text part. Problem is, that doesn’t seem easy (or in some cases possible) if there’s an HTML version. I can’t find a way to do it on the iPad or my “smartphone” (which is old enough to be senile). I suspect if I can’t find it when looking for it, most folks won’t even look.
Pegasus makes it easy. Click an icon and it switches between formats, just that easy. It’s got me spoiled…
Surprisesurprise …
It’s a curse: everything what can be done must be done, no matter what it is good for. Very often it would be better to leave things as they are, in anything that manhind concerns. In my opinion.
Now if you start even with videos and webinars I will unsubscribe, after many years on your list. This video and webinar epidemic drives me crazy, such a waste of time! Say what you think or have, basta.
If it was a matter of “I can, so I must,” I wouldn’t have stuck with plain text for so long. I knew how to do HTML mail back on 98 or so. Single-part, but I knew how. I was offering HTML autoresponders back then.
I like plain text for most things where it can be used. I can read a lot faster than most people can talk, and most video bores me. But I’m not the market.
I may choose another template, but mail that’s readable on mobile devices isn’t just an option any more. Even some of my oldest subscribers have been pushing for HTML versions.
I knew it would annoy some folks. After 17 years of the same thing, any change will seem big. But that’s not how you keep up in this market.
Most people enjoy not having to be chained to their computers to keep up. There are those of us who prefer to keep work and social separate, but we can still do that.
As far as videos… Might end up with those, but they won’t be the main content unless video is needed to show the process clearly.
Paul, are you no longer using Aweber to send out the newsletter? I’m wondering if the stock Aweber templates resize to allow proper reading in any device?
I’m still partial to plain text emails/newsletter myself, but then I still prefer to read books on real paper instead of monitors or tablet screens.
Yep. Sent that through Aweber. It’s not one of their stock templates, though, so I don’t know how those adjust to mobile screens. I’d think they would, but I can’t say from experience.
You know, Paul, it’s not so much the medium, but rather the message–and most certainly, the messenger. After many years of reading your pieces, I guess I could care less if they were sent on papaya scrolls–as long as they are sent. Seriously, the new format is fine, and it does appear that you have more functionality as a result. You might well discover some new venues to express yourself (might be scary) Best as always.
Thanks, John. There are a surprising number of people who believe my first issue was written in cuneiform on clay tablets and delivered by carrierdactyls. That’s silly, of course, since I quit using carrierdactyls long before cuneiform was developed. 😉
Paul,
I like the new look. Using HTML is fine and it will let you do things you have not been able to do with plain text. Nothing is lost. — Dan
I’ve been looking carefully at a lot of the potential this move opens. One of the big options is including a “play on demand” audio button for folks who are visually impaired, or who just prefer to listen to the content.
Rest assured, I won’t be doing anything that starts an audio file automatically, or that downloads it without reader control. I will not chew up folks’ bandwidth that way without their prior knowledge. The total bandwidth for the option will probably be less than 2k.
I have a face for radio. That said, I have many times been told I have a voice for radio. That makes audio a great option, and leaves the choice to download the audio versions of the articles for listening at the subscriber’s convenience.
Those HTML autoresponders I mentioned earlier? They were designed to be used for audio delivery. This is old stuff for me. Even so, it’s something very few people in this space do.
I suspect it will be well-received.
Really like it, makes it much easier and more interesting to read on my iPad.
No question: you have to go to html.
As for css inline. I send emails to nearly 1m subscribers and frequently have problems with css. Today I have a problem with an email rendering in gmail by filling the available width instead of being width-limited. There is no right/wrong answer but I generally get out of trouble by adding the css inline.
I would point you to https://litmus.com/ where you can submit your email and see how it looks on most browsers and devices.
The big bang for me Paul, as simplistic as it may be, is that I can sit back in my chair & read your newsletter! Just a slight bump in the fonts on this blog would get me leaning back in my chair here too, but the line spacing does help. Great job!
well over 50!
So, using inline CSS sems to make it work for everything. But not with every inlining tool.
The MailChimp CSS inliner does the trick. One of the others I tried was okay for most mail agents, but not for GMail via a browser. And the MailChimp tool ended up not being anywhere near as big an extra load on file sizes as I thought.
Hi,
Slow to the party as have been unpacking after house renovations.
Personally I far prefer text emails but I realise I am old fashioned. Also owing to previous limitations of my screen reader software (I am vision impaired) I have only been able to properly read HTML emails for a couple of years or less time.
In terms of providing straight PDF download files rather than a zip archive check out this tool:
http://pdfwatchdog.com/
It automatically stamps the customers PDF file with their name and any transaction details you specify. Doing that discourages rather than prevents piracy but does let you trace the pirate. The site does have annoying music which I hate auto playing though.
Dale.