|HTML email templates
||[Mar. 23rd, 2009|12:29 pm]
Know much about designing them? I think I've made a bad one. Text only email clients are hacking mine apart. Have you made one before? Any advice for me?
And soon? A Phost.
Oh, is there any way to detect if a client wants Text Only and send them that instead, or do you just let it mangle your HTML?
MIME stands for Multipurpose Internet Mail Extensions
And it was defined specifically to allow email to be exchanged in such a way that different clients could interpret different parts.
When you get an attachment in an email, you're seeing a multipart MIME message at work. The email client magically separated the attachment from the body and displayed them correctly.
With a good mailer client (sadly, most common office software email clients will not do this easily) you can define both a "text-only" message and an HTML message as "multipart/alternate" content, so that the client will only read one of them.
I hate to say it, but I'm pretty much limited to what I can do with Outlook 2007 at this point and Outlook 2003 and 2007 are the majority of the clients we expect to receive, but I wish I knew what percentage of clients was what for sure, how many would be reading on mobile devices, etc. For this context I don't think MIME is an option and just a fairly decent Office 2007 template may be the best I can do.
Well, actually, Outlook already sends MIME messages. :)
But Outlook does NOT send great multipart HTML/text-only messages, sadly. At least, not in any method I've been 100% happy with. What is *DOES* is it automatically creates one using just the text part of your HTML message. That's fine if your HTML message is mainly text, but if it has any other layout items (like a menu bar for example) that could mean a poor automatic translation.
MOST modern email clients will be able to read the text-only inclusion, though, even modern clients that are limited to text-only. The problems you might run into are people reading their email on a mobile device, or deaf users using a screen-reader. I'd recommend you try to test for those devices if you really want to ensure wide acceptance.
Not deaf, BLIND users. *facepalm*
Yeah, Deaf users generally don't do as well with the screen-readers. :) I understood what you meant. I think that offering the link to read it in a browser will work for most people I did put in alt text and appropriate metadata and title info for things, so I hope that helps some.
All of these HTML issues remind me of why I love PDF so much. :)
I would agree. I have always loved the idea behind PDF.
In the final sum, "fancy" HTML email is probably going to leave behind your text-only users. So if the intent really is widest-possible distribution you either need to:
a) get a more sophisticated mailer, and create good text and HTML content,
b) stick to less-fancy layouts where the HTML content is still mostly textual, letting Outlook create your text-only version from that,
c) poll your email contacts for which format they'd prefer to receive and conduct two mailings, or
d) accept that you're deliberately leaving behind some contacts.
Thank you for this! I'm actually working with a partner and kind of laid out these options for them. I added in a "view PDF" link to both the website AND the email thinking that was a nice compromise and a simplified the HTML as much as I could from the total mess it was but I think in this case option D is the real best choice for now.
I like the idea of investing more in the web experience and having the email be JUST text with a text only outline and a link to the webpage which also has the PDF link in it. While this approach is decidedly more googley off me, I just think it's the best compromise, but I think the person I'm working with may go for choice D. Long term I think detecting what the client has and presenting the right info for them is the smartest design, and this seems to be an issue that all those who distribute formatted text and image content must still struggle with to some extent when control over the client is non-existent.
It absolutely is an issue... at least with web you're told the browser version when they ask for the webpage.
With email, you have no way to know anything about how they receive it... it's "fire and forget". Makes the whole job of tailoring your content very difficult.
As a side-tip, if you want to study how other companies do it, you'll need to examine their emails with something that lets you look at the full raw source of the incoming email, multiple MIME parts and all. I don't recall offhand if Outlook really does that, or if it just shows you headers and the source of the MIME component it decided was your text.