An Introduction To Html Email
Posted on 06 Jul 2001
by Tom Granger (FDG_Tom)
Rated 3.9 (Ratings: 10)
- More articles in Code
You've got to send an HTML email to a list of clientsand have it display correctly across a spectrum of email clientswhich include Outlook, web-based, frame-based. It has to be Netscapecompatible, Eudora-friendly, Lotus Notes accessible...
What do you do?*
[Author's note:If you could say "What do you do?" a second time in yourhead in your best "Dennis Hopper Voice", it wouldreally help us out.]
So, you want to send HTML email to your clients, prospectsor newsletter subscribers? Marketing has descended from upon highand declared it, the small business client wants it, an executivein management has read about it.
Well, why not? The click-through rates are noticeablyhigher on HTML email. Analysis shows that customers are less likelyto unsubscribe from HTML email than their text counterparts. Inmy last TemplateKitemail newsletter, I had 11 unsubscribes, 10 of which were textrecipients. Customers simply respond with more click-throughs, moresales, more inquiries for information, if your message is in a formthat the recipient can easily view and display correctly.
The fact of the matter is that email HTML browsers arejust not equal to their web browser equivalents. This is furthercomplicated by the wide variety of settings, preferences, securityupdates, versions, and third-party applications which make the userexperience hard to predict.
Recently I've seen:
- Clients try to send <Forms> via email which terminatedin a web-based email reader.
- Style sheets which conflict with web-based email systems (sensea pattern here?)
- Redirects which get processed twice and break.
- A Flash or Shockwave piece that begins streaming in an Outlookpreview window and then starts a second time when the email isopened.
And these are just a few of my favorite occurrences.
We can start with Microsoft Outlook and Outlook Express to seehow each will render HTML.
Outlook decides whether to use the full version of IE (dependingon 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:
When entering your content, be aware of potential problems
There are a number of different ways foryou 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
When you enter HTML into your application, be aware whenever youdo 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 documentwithout 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 tryto select the code from the body of the document and paste it intoanother program.
Notice how links inside that document are set up. If your documentcontains a number of relative links, (i.e. /images/yourimage.gif),then you might not be able to find your images when it is time topreview and test.
You may want to include a <BASE> tag in your HTML email soyour recipient's browser knows how to interpret document relativelinks.
The BASE element allows global reference information to be set.Use of the HREF attribute provides a base address for interpretingall relative URL references in a document when the document is readout of context. The TARGET attribute specifies a global frame destinationname to be used for page activation changes (in links, forms andimage maps.)
<BASE HREF="http://www.florentinedesign.com" TARGET="_top">
This may help your mailings, however we would recommend an absoluteURL 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 possibilitythat some formatting will not carry over into HTML very well. Thisis most often seen in the case of Auto formatting, when MS Wordconverts common keystrokes into symbols. -, "", ©, and a host of others. These are called Windows Characters, andthey are not interpreted by your web browser.
Word represents these ASCII characters as numeric values which abrowser cannot understand.
This is why it is best to always work in text mode, or save yourdocument as a dos text document and lose all formatting before transferringit to your HTML email.
An excellent Text Editor to use is TextPad,which allows you to specify which code set you should use andsave your document as. Be aware that merely pasting your code intoTextPad orsaving 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, whichhas already been mailed, as the basis for your new mailing. Thisis most often seen with code that has been rendered through a web-basedbrowser which you wish to use again. Many web-based email clientsand image hosting companies, such as Netscape NetMail or Akamai,have their own redirection and accounting which break your linksif you try to send them a link which has already been processedby their system before.
Simply put, do not try to redirect a redirect. This is true foryour own redirects as well.
Since these systems assign these redirects to any HTML link thatit can discover, it is often better to avoid using "named anchors"as well. A named anchor, or "jump anchor" is a link whichtakes you to another spot in the same document.
If a redirect gets placed on a named anchor, it will most likelyeither break or spawn a new browser window with unpredictable results.From a marketing standpoint, if your email is so long that you feelyou need to use named anchors, maybe you should consider editing.