About the Upcoming HTML Email Article
Here's a little more about the article I mentioned on Monday. Realistically it won't happen before the end of April (wedding, honeymoon etc) and this is something really worth noting if you're using or contemplating using HTML emails.
The danger of sending emails in HTML is not knowing whether the recipient will be able to read them, as not all email clients support HTML. For those clients it is suggested that you send a plain-text alternative to prevent them seeing either a) nothing or b) a load of garbled HTML code.
Sending the alternative text doesn't involve sending two email. You simply have to set the content-type of the one email to be multipart/alternative. The email is then made up of two "bodies" - one is HTML the other is plain text. A simple email would contain something like this.
Another good reason to send a plain text alternative and make sure it looks good, is people like me, who like to be different difficult. As a Thunderbird user I have the (global) option of displaying my email in three ways — Original HTML, Simple HTML or Plain Text.
For obvious reasons I tend to leave it on Plain Text for most of the time. Even if you think you whole audience can view HTML emails, don't assume they choose to.
The code used is derived from this snippet on Johan's site. All I did was change the main content-type setting and then add an extra call to body.createChildEntity(). All will become clear in the article.
The obvious downside to doing this way (i.e. the proper way) is that you have to build the content of the email twice. Once with formatting and once without. It's a pain, but it's worth it to know you've done it the right way.
Further reading:
- Sending HTML and Plain Text E-Mail Simultaneously, Web Marketing Today
Skip to the 
You can subscribe to an individual
Back before Notes/Domino had the ability to create MIME content natively, I sold lots of licenses to Midas based on the ability to create MIME e-mail easily (actually I still do, although not as many now), and one part that was usually a real eye-opener to potential customer was this ability to add a plain text part. It actually has two advantages. The first is that you can make the plain text version more coherent than it might otherwise be by default. The second was that you could make the HTML more rich knowing that you did not have to make it comprehensible to a user who only got the text part. I have long advocated thinking of the recipient experience twice, one for those who got the HTML, and another time for those who got the plain text.
Unfortunatelly, I didn't think about the Original HTML vs. Simple HTML issue. How much is stripped out in a "Simple HTML" message? Images? Links? If only images are stripped out, it wouldn't have as big an effect, but if links are stripped out, it would be a big issue.
I guess "simple" HTML is down to interpretation by the agent. In the case of Thunderbird it removes images, colours, fonts and all styling etc. Links are still links and tables are tables. It's a bit like when you disable stylesheets for a webpage.
Curious for your article. Never knew about this html/text approach. Helps a lot.
Do you still plan on finishing this article? Im a little curious about the "All will become clear in the article.".
It's on my to-do list pr0gr4m.
If you're still interested in writing this article, a very useful resource I found is
{Link}
(odd that the article is in Websphere Advisor and not Lotus Advisor).
I tried the snippet on Johan's site but couldn't get it to work for me.