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...
do you do?*
[Editor'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, and an executive
in management has read about it.
Well, why not? The clickthrough rates are noticeably
higher on HTML email. Analytics show 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-through, more
sales, 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
just not equal to their web browser equivalents. This is further
made complex 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.
- Styles 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 start a second time when the email is
a web-based email client forbid it.
And these are just a few of of my favorite occurances.
We can start with Microsoft Outlook and Outlook Express and how
each will render HTML.
Outlook makes a decision whether to use the full version of IE
(depending on the version you may have) or use a "lite"
version of it depending on your current configuration.
Two links that can help you understand these differences are:
E-mail Security Update Information
Outlook Renders HTML
When entering your content you need to
be aware of a couple of potential problems.
There are a number of ways for your to send
- As an attachment
- As an embedded document
- As Raw HTML (consult you individual email
- Through a third-party application like
Traffic Builder or a robust system such as Xchange
When you enter your HTML into your application, you also need to
be aware whenever you do the following:
- Cutting and pasting from a 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 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 pasting
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
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
This may help your mailings, however we would recommend an absolute
URL for each of your links.
Cutting and Pasting from a Microsoft Office
If you cut and paste from Microsoft Word, there is 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 are
not interpreted by your browser.
Word represents these ASCI 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 for you to use is TextPad, which will
allow 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
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 with code that has been rendered through a web-based
browser that you wish to use again. Many web-based email clients
and image hosting companies, such as Netscape NetMail or Akamai,
will have their own redirection and accounting which will break
your links if you try to send them a link which has already been
processed by their system once before.
So, 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 that
takes you to another spot in the same document.
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.
<A Href="#foo>This would jump you
to "foo" in this email</A>
That's it for some of the basics, so let's move on to:
in HTML Email:
Back to Articles: Home
||Attention Web Developers! Do you need more
clients for your business? Do you need to make more money? Proposal
Kit helps you demonstrate that you are the right professional
for your customers.
Design Group is a coalition of web designers, marketers, artists,
animators, and other hired guns who work in the start-up arena.
Sometimes cheap, sometimes for free, always getting the job done.
If you can find them, maybe you can hire them....just like the A-Team..grrrr
Proposals, Bids, and other Forms
Cards by Cyber-i,
2001. All Rights Reserved.