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.