Yes, you should get plain text too!
Posted by Mathew Patterson on December 5, 2007
in
Apparently we have not made this clear enough yet, so I wanted to say it explicitly:
Everybody should get the choice to receive HTML or plain text
If you personally prefer text-only email, you should always be able to set your email client to show plain text, and all your newsletters should a have plain text alternative for you to read. We totally agree! The Email Standards Project is trying to improve the rendering of the HTML portion of the email, not to get rid of the text portion, so there is no need to worry.
Well Said,
I personally prefer text only, but all of my clients what to send HTML, so in reality it really makes no difference what I like, they are the ones paying for the time it takes to make an HTML email work, not me.
I’m all for the project, it’s a great initiative and to all the people who don’t like HTML in email, don’t worry about it, just set your email client to show text only… problem solved.
I’m whatching this project very closely, good work people.
Cheers.
User can have preference on what type of email he wants to send, but how will one control what kind of email he wants to receive.One might loose information, if you always try to display the plain text part of the mail, for every mail.
So, I think this needs more preference, like only newsletters from specific receivers.
Also, RFC says to render the best part in an email.
Hence, i think its always a good idea but not a complete solution to the problem.
The problem being we tend to see our biggest sales from HTML emails. However I noticed an increasing trend of people reading email on blackberries and mobile devices. It’s a good practice to include some more evolved text information in your HTML emails just in case this happens.
Thanks guys - although I want to point out that sending a plain text alternative is not something we should do ‘just in case’, it is something we should send as an equally well thought out alternative, for people who prefer it.
I think this post is scratching at a good topic - Multipart Alternative emails. My experience is finding that most email clients don’t support allowing a user to change their preferences from receive HTML part or receive Text part.
I think an entire project could be dedicated to the industry adopting end user support for setting preferences regarding multipart alternative emails.
While my research is not exhaustive… here’s my scratch the surface findings:
*Thunderbird does an excellent job.
*GMail only renders the HTML, but allows a user to view the original un-rendered message, but not the text part by itself.
*I believe the latest version of Y!mail works the same as G!.
*Outlook 2003 only renders the HTML - but has an option where a user can choose to view as text, which rather than display the text part, the app displays the HTML source as text *ugly*.
*Outlook 2007 appears to have done away with this option, only rendering the HTML part.
*Lotus (I believe I looked at 7) appears to have a setting on the server level and not the client level.
I’m glad Jeff brought up Multipart Alternative emails because I have a couple of questions about this.
I’ve read alot of recommendations from alot of people that you should send both plain text and HTML in the same email, something which I actually make a point to do. I even put the plain text part first in the message body, so if there’s a problem parsing and the message is garbled on the client’s end, that a plain text version is “above the fold”.
I’ve even considered using the “preamble” feature in Mime (see RFC 1341) to include text to explain to people with low capability email clients how to re-request the email as plain text only. (I’d love to hear some feedback from people on whether this is a good idea or not)
Recently I did a bit of research to verify if what I’m doing is the “best” way and I came across some recommendations to not bother sending multipart emails because it can increase the message body size increasing the likelihood that it is filtered or blocked. The articles I read also said that the number of clients that can’t display at least a subset of HTML is so tiny that it does more harm than good to send multipart. Their suggestion was just provide to a way for the end-user to set their HTML/Text preference when they provide their email address and/or allow them to change their preferences at any point.
What are your thoughts on this, and is there any “best practice” for dealing with this?
The idea with Multipart is that both HTML and Text versions are sent in a single message, and that the end-user’s email client’s preferences determine which version they see (Note: both parts are still delivered to the user). In practice though, very few users change their email client’s default preferences and in reality it’s usually only the tech-savvy, HTML-loathing users who make the conscious choice to receive Plain Text format emails. However, with more and more users receiving email on the move, via handhelds, PDAs and other wireless portable devices, I think the Plain Text format is still very relevant.
Benefits of sending Multipart:
* Both HTML and Plain Text and sent in a single send
* User’s preferences determine which version they see
* May help increase deliverability slightly
Downsides to using Multipart:
* Users have to download the whole Multipart message, although they will normally only view one part of it. (This is most relevant to plain-text email users who’ll be downloading extra code for the HTML version, which is normally heavier - although I don’t think any external content (e.g. images) would be downloaded unless the HTML part is displayed)
* Although the MIME Mutlipart specification has been around for a long time, some email clients may not be able to handle the Multipart format properly. (Although I haven’t had the time to research or test this recently, I expect problem candidates are clients with poor HTML support like Lotus Notes).
Jeff: Yes, it looks like Outlook 2007 has removed the option to force the receipt of emails in Plain Text format. In Outook 2003 This used to be under Options > Preferences > Email Options. Very annoying!
Dan: The preamble is a great idea, but I’m not sure how well supported it is. I don’t think the extra ‘weight’ of sending Multipart is necessarily a deliverability hindrance; however, as with any email, if the HTML part is very large, it may trigger certain spam-filter flags. A good balance of real text vs images in your HTML format is probably more important than the overall message/file size of the Multipart message.
Allowing users to set their mailing preferences via your site and then sending two seperate broadcasts (one HTML, one Text) is probably the most robust and reliable way to deliver the two formats, but it also requires increased time to manage two lists/databases, two lots of unsubs, resends etc.
The person who invented HTML email and email attachments should have been ripped off teeth one by one and then shot, hung, poisoned and fucked with a piledriver and 16 feet of curare-tipped wrought-iron fence and no lubricants.
Roberto: I used to hate HTML email, too, so can sympathise slighly - but it’s here to stay so fing and blinding isn’t going to change anything, unfortunately. The arguement against attachments, however, is a non-starter - email simply wouldn’t be the ubiquitous tool it is today without the ability to attach files, documents, pictures etc.
The most important thing we can do now is push the software giants to support good, standards-compliant emails (both HTMl and Plain Text) and to increase security for end users without compromising the freedoms we all enjoy.
Thanks for your valuable contribution, Roberto. I’m curious what your stance is on child molesters and serial rapists.
--/ RE: MULTIPART /--
One should use multipart messages to help ensure successful delivery of an email which is also readable. Consider the following scenarios:
* Many less-than-savvy people sign up for email newsletters and don’t realize their email clients don’t support HTML.
* Many savvy people intentionally sign up for HTML emails knowing their email clients support HTML, but then read them from a mobile device while on the move.
* Many people have heavy spam filters. Multipart messages (including standards-based HTML) help the code-to-content ratio; favoring content of course.
--/ RE: PLAIN-TEXT SEGMENTS /--
I believe we should give as much attention to the plain-text component of a multipart message as we do to the HTML component. Plain-text emails can be “designed” to a certain degree. Creative formatting of headlines/subheads, lists, etc. can make a plain-text email really sing.
With HTML, we have an arsenal of tools to help us emphasize specific parts of a message. While plain-text formatting is limited, a little creativity and attentive consideration can go a long way. And for recipients who receive the plain-text segments of a multipart email, this can have a huge impact on the message we’re trying to convey.
Mark: Totally agree that as much care should be taken to format the plain-text version. I’m constantly amazed at how poorly some of my company’s clients deal with this side of things.
Tips for plain text email formatting
------------------------------------
* Keep your line length to around 67-71 characters, as this is the optimum for a range of email clients
* Don’t use TABS for layout as they are treated differently by email clients. Some email clients will collapse TABS, others will display them at different lengths. Since most email clients use a fixed-width font to render plain-text emails, you can use mutliple spaces for layout purposes.
* Ensure your plain-text editor saves your files as PC/Mac ANSI (some people use UTF-8 but this isn’t as well supported in email clients)
* Be aware that the special character range is very limited - many characters supported under HTML encoding mechanisms are not supported in plain-text. Generally, when you copy and paste your copy from, say, Microsoft Word, into your text-editor, unsupported characters will show up as a solid black character. Simply overtype these and replace with whatever works for you as an equivalent from the available character list.
Hi All, just been pointed at this site by a friend and very glad to see this particular thread as well as a general standards based approach. I’m a long time user and fan of the Pegasus email client and I must confess that my thoughts on HTML email have often echoed Roberto’s. (As a CSS evangelist I’d also add in the guys that developed IE6!!)
However it seems we have lost that particular battle probably because the marketing people want the flashiness of HTML for their email campaigns. As an SEO as well as a web designer I can understand that although I will always want to read my email in plain text unless a complete overhaul of the system comes to pass. To me Multipart is essential if we are to retain any sort of universal access to email. If I receive HTML-only it gets deleted unread.
Will be watching this forum with interest.
Cheers
Yes, that’s totally right… actually every email message sent should be based on multipart mime types text/html, as a lot of people including me do check their email accounts using a wap device like blackberry!
Good point, i know from several email clients that i have used that html email often either fail to load or go into the junk folder which i why i usally just go for plain text option.
Everybody should get the choice to receive HTML or plain text - Golden words, 95% of my mail is plain text!
I do agree, it should be the users choice to decide how they want to receive/view their email.