An Introduction To Html Email

Pop-quiz hotshot!

You've got to send an HTML email to a list of clients

and have it display correctly across a spectrum of email clients

which include Outlook, web-based, frame-based. It has to be Netscape

compatible, Eudora-friendly, Lotus Notes accessible...

What do you do?*

[Author's note:

If you could say "What do you do?" a second time in your

head in your best "Dennis Hopper Voice"™, it would

really help us out.]

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, an executive

in management has read about it.

Well, why not? The click-through rates are noticeably

higher on HTML email. Analysis shows that customers are less likely

to unsubscribe from HTML email than their text counterparts. In

my last TemplateKit

email newsletter, I had 11 unsubscribes, 10 of which were text

recipients. Customers simply respond with more click-throughs, more

sales, more inquiries for information, 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

just not equal to their web browser equivalents. This is further

complicated by the wide variety of settings, preferences, security

updates, versions, and third-party applications which make the user

experience 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 which 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.
• Entire JavaScripts blown apart when a viewer's security settings
  or a web-based email client forbids it.

And these are just a few of my favorite occurrences.

We can start with Microsoft Outlook and Outlook Express to see

how each will render HTML.

Outlook decides whether to use the full version of IE (depending

on the version you may have) or use a "lite" version,

depending on your current configuration.

Two links which can help you understand these differences are:

Outlook

E-mail Security Update Information

How

Outlook Renders HTML

When entering your content, be aware of potential problems

There are a number of different ways for

you to send HTML code to your viewers.

1. As an attachment.
2. As an embedded document.
3. As Raw HTML (consult your individual email program)
4. Through a third-party application

When you enter HTML into your application, be aware whenever you

do the following:

• Cutting and pasting from WebPages.
• Cutting and pasting from a MS Office product.
• Using a previously mailed document as the basis for your code.

Cutting and Pasting from a Web page

There are several ways to get HTML code from an existing document

without using an HTML editor.

You can "view source" and copy the code to the clipboard;

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.

Notice how 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 is 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 interpreting

all relative URL references in a document when the 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.)

Example:

<BASE HREF="http://www.florentinedesign.com" TARGET="_top">

This may help your mailings, however we would recommend 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 is always the possibility

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 are not interpreted by your web browser.

Word represents these ASCII characters as numeric values which a

browser cannot understand.

This is why it is best to always work in text mode, or save your

document as a dos text document and lose all formatting before transferring

it to your HTML email.

An excellent Text Editor to use is TextPad,

which allows you to specify which code set you should use and

save your document as. Be aware that merely pasting your code into

TextPad or

saving 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, which

has already been mailed, as the basis for your new mailing. This

is most often seen with code that has been rendered through a web-based

browser which you wish to use again. Many web-based email clients

and image hosting companies, such as Netscape NetMail or Akamai,

have their own redirection and accounting which break your links

if you try to send them a link which has already been processed

by their system before.

Simply put, do not try to redirect a redirect. This is true for

your own redirects as well.

Since these systems assign these redirects to any HTML link that

it can discover, it is often better to avoid using "named anchors"

as well. A named anchor, or "jump anchor" is a link which

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 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.

That's it for some of the basics. Stay tuned for next week's continuation of this article, where we'll discuss stripping out unnecessary HTML elements and responsible uses of JavaScript in HTML formatted email.