Q and A: Email Newsletter
February 10, 2006 at 5:09 PM
Ok, continuing with our rounds of Q and A some good feedback was given regarding our Email Newsletter. A few readers reported that its hard to find the new article information within the newsletter. I agree, it's a bit hard to find in between the sponsor ad and the other information. Another reader suggested offering the option of a HTML version of our newsletter. Good idea. Hmm, maybe we can nail two birds with one stone here... you bet we can. Thanks to Mark Wyner volunteering his time and his awesome HTML Email skills we are going to have a nice new HTML Email version of our newsletter for you as an option. The new newsletter will be significantly easier to read and find information. As I told Mark, both me and David Greiner over at Campaign Monitor are about as excited as a kid in a candy store about this new newsletter design. We'll make a big announcement when it is ready for public consumption.
maybe we can nail to birds with one stone here Two perhaps? ;) Anyhow I look forward to seeing the new look newsletter. :)
Mark: you are making some horrible assumptions about how this will be implemented and how email readers handle HTML email. You can still remain subscribed to the text-only email newsletter subscription list... everyone who is subscribed to that existing list will remain subscribed. We will simply be adding a 2nd email newsletter for HTML email where people can choose that newsletter from the subscription form. We will not implement this for existing subscribers. If existing subscribers want HTML email they will have to subscribe to the HTML version and probably will want to unsubscribe from the text-only version. Interesting point about RSS. Interesting because a lot of people are taking the RSS file and styling it into the format of a web page for users who don't understand how to use RSS. Anyway, we don't intend to send anyone to a web page to read the newsletter, if we did we'd send them to the archives. I think I have researched this pretty well. Mark Wyner has also been doing this for years and is pretty experienced with what it can and can not do, what readers do and do not render the HTML, what layouts will and won't work, etc. I suggest you re-check your facts. I'd suggest you start by reading the posts in the Campaign Monitor blog... specifically the post entitled Optimizing CSS presentation in HTML emails by Mark Wyner himself.
Both articles I wrote about using CSS in HTML emails ignited heated debates about whether or not HTML emails shoud exist at all. While I welcome these debates, I think Mr. Harris' comments are abrasive and lacking sustenance. "The only way to block it is to disallow HTML email." Interesting. I am subscribed to a handful of email newsletters in HTML format, yet I am successfully blocking spam every day. And when I don't recognize the sender of a message or read a subject line which is obviously spam, I don't open it. With spam filters and common sense, you see, we can "block it" without having to avoid HTML emails altogether. "...but hey, didn't we invent RSS so that we didn't have to do that anymore?" Oh, so that's why RSS was invented. Nice. "Nick, I thought you were one of the smart guys..." I would hardly discredit Nick's intelligence over this matter. "...but you don't seemed to have researched this properly." While some people avoid HTML-formatted email newsletters, many choose to embrace it. And given the fact that no existing plain-text subscriber will begin to receive the HTML format, I find it challenging to see how this decision is poorly researched. Digital Web's decision to create a new list for HTML subscribers is, from my perspective, perfect. Those wishing to avoid HTML email can do so without having to take a single action on their part. "...as I plan to opt out." Wow. Mr. Harris is currently receiving a plain-text version of the Digital Web email-newsletter, will continue to receive the plain-text version after the launch of the HTML version and will never be forced to receive the HTML version. Yet he intends to opt out. Now that's a smart, well-researched decision indeed. Nick and company: I commend you for your careful consideration about how to handle your existing subscribers. Your efforts will be well received by the majority of your audience, and I will do my best to ensure the new HTML-version is accessible to everyone who wishes to adopt it.
Just a wee bit defensive there, boys. You both miss the point. Email = text, HTML = web Just because you can, doesn't mean you should. And if you think that was abrasive, Mark, you've obviously not spent much time in Usenet, or on a debate team.
Mark, we get that Email is for text and HTML is for web. What I don't think you get is that readers are asking for this functionality (HTML email newletter, easier to read newsletters, better newsletter design and layout, etc). If the readers didn't want it we wouldn't be doing it. Anyway, Mark, please go back and read the article I linked to. Seriously. Do it. It's clear you haven't yet.
Nick, I did read Mark's column - it was the spur for my commentthat "Just because you can, doesn't mean you should". Did the readers ask for HTML email? Or an HTML newsletter? Is the problem that they can't find the information they want in your current newsletter? If so, doesn't that point to a problem with the way your newsletter is structured, rather than the format? Communication transends the medium. A good newsletter would be good carved on clay tablets. A badly structured newsletter won't be improved by CSS and HTML (Not saying your newsletter is bad - I have had no problems with it). If the problem people are having is to do with the information being inaccessible or unusable in some way, look at how you structure that information first. Otherwise you're in danger of putting lipstick on the pig.
It seems that some people aren't aware, but as a multi-part email you can deliver a plaintext and a html version at the same time. If your client is switched to 'html off' then the plaintext version is presented, and if it's set to 'html on', you should always provide a 'cannot read this email? click here' link at the top... to a webpage displaying the same html, where the browser can support it properly. If you'd like a demo on this, give me a shout!
Mark: you make some valid points about content and medium. I fully agree. People are specifically asking for an HTML email version of the newsletter. Chris: Good point. Yes, that will be done for the HTML email version of the newsletter, but we will not do that for the text-only version of the newsletter. To be clear, these are basically two totally seperate newsletters, one for those who wish to have HTML email in their inbox (this is the new one we are working on) and one that is just nothing more thant pure plain text (our existing newsletter that has existing subscribers). We don't plan to "port" subscribers to the new version, we don't plan to force people to have to switch of HTML email or anything of that sort.. the two camps are totally different. To your point, yes, we "could" do that, but we will not... there are just to many complications with various types of email clients (Outlook, Hotmail, Mail on the Mac, Yahoo! mail, etc etc)... not every client works the same way.
Nick : Agreed about the differing versions of clients and their respective rendering engines. This is something I deploy on a weekly basis for GE healthcare and found the best contingency-design was to provide a 'cannot read?' link at the top of the html version.
Chris: I agree, the can not read link is important, especially for those who signed up to the wrong list not knowing that their client or service won't properly render the HTML email, etc. I am pretty sure Mark Wyner has already planned to put things in place such as this. That said, the can not read link is still no solution to clients that can't read HTML and that is why we will still always offer the plain text version.
I am designing Multipart-E-Mailings for almost 3 years now and i know by a lot of client testing that its not this easy to include some harmful code inside a mailing - clients disallow it in the same way as they do it with a simple tag. I agree with Nick & Mark Wyner: It is a really usefull decision to bring up this html-format option. It's a big plus in presenting and structure the content of a newsletter. Those who dont want to receive html-newsletter should stay with the text-version and better disallow html in their clients. You have the choice...it's soooo easy! Regards Tino