HTML Email
An Introduction
Article Title: HTML Email - An Introduction
Author Name: Thomas Granger
Contact Email Address:
mailto:info@florentinedesign.com
Category: E-commerce
Copyright Date: June 26th, 2001
Internet Address:
http://www.florentinedesign.com/articles
Special Requirements For Reprint: This article may be reprinted freely as
long as article and resource box remain unchanged. All links must be active.
HTML Email: An Introduction
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?*
[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, an executive in management
has read about it.
Well, why not? The click-through 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, (http://www.florentinedesign.com/email_tk/tk_01.htm)
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 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
http://support.microsoft.com/support/kb/articles/q262/7/01.asp
How Outlook Renders HTML
http://support.microsoft.com/support/kb/articles/q249/9/72.asp
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.
- 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 (http://www.florentinedesign.com/bcentral)
or a robust system such as Xchange - eMessaging (http://www.xchange.com)
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 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:
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 possibliity 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. -, "", ©
,b and a host of others. These are called Windows Characters, and they are
not interpreted by your web 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 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.
A Href=#fooThis would jump you to "foo"
in this email
That's it for some of the basics, so let's
move on to:
NEXT! Unnecessary Elements in HTML Email:
Thomas Granger is the chief Brew-ha-ha of
Florentine Design Group and Market Wiz for Proposal Kit, a Contract, Proposal,
and Lead Generator you can download at http://www.proposalkit.com/info.htm
See our CD-ROM business card work at:http://www.cybericard.tv
http://www.florentinedesign.com
Sign up for free Templates for Web, Print,
and Graphic Design at:
http://www.florentinedesign.com/downloads/downloads.htm
20/07/2003
AN OUTPOST PRODUCTION