Results 1 to 2 of 2

Thread: How To Code HTML Emails

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Jan 2011
    Posts
    4

    Default How To Code HTML Emails

    How HTML email works, basic concepts, best practices, tips and tricks
    Want to learn how to code your own HTML email campaigns? You've probably Googled all kinds of web pages that give you countless "what works, what doesn't" charts. They tell you which CSS definitions break, how Lotus Notes never renders HTML properly, and how Outlook can't send email campaigns right.

    But instead of focusing on specific tactics, let's go over some fundamental principles...

    Prerequisites
    One thing I have to stress is that in order to code your own HTML email, you really, really, really need to know how to code HTML. You should be able to code web pages "from scratch" without the help of any WYSIWYGs (like Front Page, or even DreamWeaver). If you're that good, then you really don't need to worry about a million little rules (like what CSS definitions work in this email program, but not in that email program). Just being able to understand "the fundamentals" will save you a lot of time and frustration.


    Not an expert coder? No worries. Most email marketing services provide you with built-in templates that you can use instead. MailChimp actually gives you an HTML Email Designer that you can use to create as many HTML emails as you want, without even knowing how to code.

    HTML Email In A Nutshell
    An HTML email is nothing but a web page. That's it. I'm sorry if you thought there was more to it than that. So if you can code your own web page, you can code your own HTML email templates. There is a little catch, though. You have to code like it's 1996 (I'll explain later).

    HTML Email: Proper Delivery via Multipart/Alternative MIME
    What makes HTML email so hard for most people is not the designing and coding part. It's actually delivering it properly. You can't just attach your HTML file and images to an email and send it. When people open the HTML file, your images will all be broken (because their email program has stored them in a temporary folder somewhere on your hard drive.

    Even if you do manage to get your HTML email to display properly, there will be some recipients who can't (or won't) view HTML email in their email programs. So you need to send your HTML email along with a plain-text alternative version of your message. Then, your recipients' email programs will automatically determine which format to display. In the early days, email marketing services would call this "HTML email sniffers." As in, "our solution comes with sniffers that automatically detect which version to display for your recipients." The truth is, the "sniffer" is on the recipient side, not the sender. It was just easier to explain that way. Nowadays, just about everybody can receive HTML emails. Some still choose not to.

    So how do you properly send an HTML email along with a plain-text alternative version? Simple. You send it in "Multipart/Alternative MIME" format. If you're a programmer, this is where the gears in your brain start spinning. So go ahead and bookmark this web page, so you can come back to it later. Now, go on and Google "multipart alternative" and figure out how to send them from your own server. You may find some PHP or Coldfusion or ASP scripts out there. You may even find a way to rig Outlook or Thunderbird to send multipart messages. Go ahead and get it out of your system now. Then, when your ISP shuts you down for sending too many emails from your account and hogging up all their bandwidth, or when you realize that properly cleaning bounces and unsubscribes and tracking opens and clicks is a lot of work, or when you get blacklisted because your server wasn't reputably configured, come back to this page.

    Back again? Cool. By now, you've learned that delivering HTML email is the hard part, and it's not what you were hired to do. That's the part you want to outsource to an email service provider (ahem, like MailChimp). Email service providers (the good ones) work alongside ISPs and anti-spam groups and maintain their servers for deliverability.

    So you can design and code your own HTML emails. Just use an email service provider to handle delivery. FYI, MailChimp comes with built-in templates, but also lets designers use their own code.

    Enough about delivery. Let's move on to the fun stuff...

    Coding Your HTML Emails: Fundamental Principles
    Like I said earlier, coding an HTML email is basically like coding a web page. Only you've got to do it the old fashioned way. Remember back in the 90's when there were no WYSIWYGs yet, and you had to code everything by hand? Remember the Internet Explorer vs. Netscape wars? Remember how you had to test your work over and over and over again? HTML email is a lot like that. Times 10.

    The most important thing (if you wish to preserve your sanity) is to keep it simple. Focus on your message, not your craftiness.
    Images should be posted on your publicly accessible web server. In your code, use absolute paths to point to them. Attachments are often stored in randomly named temporary cache folders by some email programs. They also hog a lot of bandwidth (especially when they bounce) so attachments are not the way to go.Tip: One common mistake is to post your image files on an intranet, extranet, password-protected server, a secure server that's extremely slow, or a free hosting site (images my not show due to bandwith issues). Post images on your fast, public-accessible web server.
    TABLES and SHIM.GIFs are your friend. Keep it simple, because email programs use different HTML rendering engines. Some of them use Internet Explorer, Firefox, or in the case of Outlook 2007, Microsoft Word (what a headache!). Some of them use their own proprietary renderers (Lotus used to do that, which is why you'll find lots of old rants on out there about Lotus and HTML email problems).
    Don't code your emails too wide. Most people view messages in their preview panes, which are narrow and small. Don't ask me if you should code for 1024x768 screens or 800x600. Puh-lease. This is email we're talking about here. The preview pane in AOL 9 is less than 200 pixels wide, my friend. Think small. The templates we design at MailChimp are never more than 600 pixels wide, or they're f luid-width.
    Test how it renders. Your email will display differently in all the different email programs out there. So testing is a must. And we're not talking about IE, Firefox, and Safari. We're talking about Outlook, Outlook 2007, Outlook 2003, Outlook Express, Thunderbird, Apple Mail, Eudora, Lotus, Gmail, Yahoo!Mail, AOL, AOL Web, Hotmail, MSN, Comcast, Earthlink, and on and on and on. How to cope? Keep it simple. TABLES. 600 pixels wide max. You can also test how your email renders in all the major programs with the MailChimp Inbox Inspector. Click one button, and we'll give you screenshots of your campaign in all the major email programs in just a few minutes.
    Webmail services are deceptively tricky. Email services that are browser-based, like Gmail, Yahoo!Mail, Hotmail, etc., will strip out your DOCTYPE, BODY, and HEAD tags. Makes sense---they don't want your code to potentially override theirs. Anything you'd normally code inside those tags (bgcolors, embedded CSS, JavaScript, background music files, etc) will also get stripped.
    Think like a spam filter. You have to consider spam filters and spam firewalls when you code. It's pretty obvious that spammy words like "Viagra" or "V14GR4" will get you spam filtered. But spam filters also look for stuff like, "do you have too many images, and not enough text?" If you're sloppy with your code, you'll look like a sloppy spammer. See: How spam filters work.
    99% of your CSS won't work (especially not in the browser-based email services like Gmail, Yahoo!Mail, etc.). That means no CSS-positioning, DIVs, etc. Before you ask me for a detailed list of what works and what doesn't, just remember this (it'll save us all a lot of time): When your email is opened in Gmail, for example, the CSS in your HTML email could potentially override the CSS on the rest of their page. So they disable a lot of it. Inline CSS is safer, and plain-old FONT tags are safest (code like it's 1996, remember?). Or check out MailChimp's CSS inliner tool.
    continue>>>
    Last edited by rameshxavier; 03-19-2011 at 10:54 AM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •