HTML eMail Troubleshooter

So, you want to send HTML email to your clients, prospects or newsletter subscribers. Marketing has descended from upon high and declared it, the small business client wants it, and an executive in management has read about it.

Well, why not? The clickthrough rates are noticeably higher on HTML email. Statistics show that customers are less likely to unsubscribe from HTML email than from its text counterpart. In my last TemplateKit email newsletter, I had 11 unsubscribes, 10 of which were text recipients. Customers simply respond with more click-through, more sales, and more inquiries for information, but only if your message is in a form that the recipient can easily view and display correctly.

The fact of the matter is that email HTML browsers are simply not equal to their Web browser equivalents. The situation’s made more complex by the wide variety of settings, preferences, security updates, versions, and third-party applications which mean that the user experience is extremely hard to predict. Recently I’ve seen:

Clients try to send Forms via email which terminated in a Web-based email reader
Style sheets which conflict with Web-based email systems (sense a pattern here?)
Redirects that get processed twice and break
A Flash or Shockwave piece that begins streaming in an Outlook preview window, and then starts a second time when the email is opened
JavaScripts blown apart when a viewer’s security settings or a Web-based email client forbid them
Links that mysteriously break under Hotmail’s link accounting system

…And these are just a few of of my favorite phenomena. As they’re the two most common email clients, let’s start by looking at Microsoft Outlook and Outlook Express, and how each will render HTML.

Common Email Clients

Outlook makes a decision to use the full version of IE (depending on the version you may have) or use a “lite” version, based on your current configuration. Two resources that can help you understand these differences are:

When you enter your content, you need to be aware of a couple of potential problems.
There are a number of ways that you can send your mail:

As an attachment
As an embedded document
As raw HTML (consult your individual email program)
Through a third-party application like bCentral’s Traffic Builder, or a robust system such as Xchange – eMessaging

When you enter your HTML into the application, you also need to be cautious if you:

Cut and paste from Web pages
Cut and paste from an MS Office product
Use a previously-mailed document as the basis for your code

Cutting and Pasting from a Web Page

There are a number of ways you can get HTML code from an existing document without using an HTML editor. You can “view source” and copy the code to the clipboard, you can create a copy with the “save as” command, or you can try to select the code from the body of the document and paste it into another program. What you need to be conscious of is how the links inside that document are set up. If your document contains a number of relative links (i.e. /images/yourimage.gif), then you might not be able to find your images when it comes time to preview and test.

You may want to include a BASE tag in your HTML email so your recipient’s browser knows how to interpret document-relative links. The BASE element allows global reference information to be set. Use of the HREF attribute provides a base address for the interpretation of all relative URL references in a document, when that document is read out of context. The TARGET attribute specifies a global frame destination name to be used for page activation changes (in links, forms and image maps).

For example:
<BASE HREF="http://www.florentinedesign.com" TARGET="_top"> This may help your mailings, however I’d recommend that you use an absolute URL for each of your links.

Cutting and Pasting from a Microsoft Office Product

If you cut and paste from Microsoft Word, there’s always a chance that some formatting will not carry over into HTML very well. This is most often seen in the case of auto-formatting, when MS Word converts common keystrokes into symbols, -, “”, Â© and a host of others. These are called Windows Characters, and they’re not interpreted by your browser: Word represents these ASCI characters as numeric values, which a browser cannot understand.

This is why it’s always best to work in text mode, or save your document as a DOS text document and lose all formatting before you transfer it to your HTML email. An excellent Text Editor worth your consideration is TextPad, which will allow you to specify which code set you should use and save your document as. Be aware that to merely paste your code into TextPad, or save your document in MS Word as a text document, is not good enough.

Using a Previously Mailed Document as the Basis for your Code

You may experience problems whenever you try to use code that has already been mailed as the basis for your new mailing. This is most often seen when the code you want to re-use has already been rendered through a Web-based browser. Many Web-based email clients and image hosting companies, such as Netscape NetMail or Akamai, have their own redirection and accounting. These functions will break your links if you try to send them a link that has previously been processed by their system.

So, simply put, do not try to redirect a redirect. This is true for your own redirects as well.

Because these systems assign redirects to any HTML link that they can discover, it is often better to avoid using “named anchors” as well. A named anchor, or “jump anchor”, is a link that takes you to another spot in the same document:
<A Name="foo"> If a redirect gets placed on a named anchor, it will most likely either break the link or spawn a new browser window — with unpredictable results. From a marketing standpoint, if your email is so long that you feel you need to use named anchors, maybe you should consider editing.
<A Href="#foo>This would jump you to "foo" in this email"</A>

Unnecessary HTML in Your Email

Now let’s talk about the different elements that, while often included in mailings, are not really necessary. The following elements should be stripped out before you mail. This will reduce the overall size of your mailing and increase the speed with which it is delivered, rendered, and received by your customers. While this may not seem like a big deal for a hundred piece mailing, imagine sending 5 million or so emails in a single day…

All Meta Tags, Including Refresh Cache & Pragma

Many systems will disable some Meta Tags by default, however when Outlook receives a refresh command it will merely display blank content in both the preview pane and open message. Web-based systems will usually only display content taken from between your <BODY></BODY> tags.

<TITLE></TITLE>

The subject section of your email message takes care of this element.

Long Comments or Commented-out Sections

<!–Nuff Said–>

Programs that Export to HTML

If you’re using Dreamweaver, FrontPage, or Adobe – avoid any references to extensions, styles, or Fireworks/Image Ready tables. This is most common with Front Page extensions, which reference IE-only styles quite often. If you have a document that uses a library item, such as Dreamweaver, you’ll have to break the library item apart and insert your code as raw HTML for your mailing to work correctly.

Redirects

Many Web-based email clients place their own redirects on your links (for whatever nefarious reasons…). So if you place your own redirects on urls, turls, or query strings, they may break, or show up as plain text in the middle of your email.

Extraneous Style Sheets

Make sure that if you use style sheets, they include only the elements that you’ll be using for a particular mailing. This helps cut out bulk and unnecessary code from your mailings. This phenomenon is most often found when a mock-up contains the entire style sheet for a Website, rather than just the styles used in the mailing.

So if you had 100 lines of code that defined 25 styles on your Website, but you were only using one style for your HTML email, you could either mark up the style in HTML code, or you could simply define one style and apply it to the entire email. While this may not seem like a big deal for a couple of hundred emails, again, it adds up if you’re sending a million emails in a day.

Special Characters

Be careful when you use special characters in your HTML email. Special characters include those which must be generated through an escape sequence (ex: Â© = © in HTML), and many email browsers will have trouble reading these characters.

One character sequence to be especially careful of is the non-breaking space character (  ). Many WYSIWYG editors (like FrontPage & Dreamweaver) have fallen in love with this character. Furthermore, many WYSIWYG editors use the Non-Breaking space to wedge open <TD>’s, which will usually close up when viewed by the majority of Netscape browsers. A spacer GIF should be used when you absolutely have to keep a <TD> cell open in order for your design to work.

HTML eMail — Effective Communication

Although it seems that HTML email necessitates a reduced level of functionality, you can still deliver an effective communication to you subscribers if you follow the conventions described above.

In the next part of this discussion, we’ll explore the inclusion of JavaScript & Rich Media elements such as Flash and embedded video in your emails. See you then!