HTML Email – Rich Media the Right Way

As we discussed last time, increasing numbers of email marketers want to use the ‘power’ of the Internet to better communicate with their customers. How can they harness the graphical and interactive capabilities of the medium? Rich media email. But though the decision might be an easy one, the execution of a good rich media email campaign can be tricky. Let’s consider two popular formats and troubleshoot the common problems of each.

Using JavaScript in your HTML eMail

As JavaScripts are predominantly a unique and proprietary element (and by this I mean that you can write 100 different scripts which all do basically the same thing but in a different manner), complex JavaScripts will always spell trouble for your HTML email.

Due to the wide variety of email clients, browsers, security settings, updates, and service packs installed, it’s difficult to predict how a script will execute against any given email client. JavaScripts can cause browsers & Outlook 2000 to disable any active scripting contained in an email document (and there has been an increase in email security due to malicious scripts).

You’d be wise to test any Javascript you wish to include in a mailing. Not all email clients can handle the scripts, and most Web-based systems disable scripts as a general rule, to prevent malicious code from being executed on a system. Javascript navigation forms (such as jump menu forms) can be used, but even these will only work in non-Web-based email clients. And most other navigation forms aren’t supported because they don’t work on the majority of Web-based email clients. However, forms that use the GET/POST method will render and test correctly in Web-based email clients, and you can often use this to get around many Javascript problems in HTML email.

Remember! Most Web-based email browsers are a <FORM> themselves, and use Javascript to power their product in some way or another. For this reason, your script has to be fairly innocuous in order to not interfere with their product.

Flashing your Email: Rich Media & HTML Email

Lately there’s been a great deal of interest in the addition of Flash to your everyday, run-of-the-mill email to impress clients, prospects or newsletter subscribers. However, the fact of the matter is that email HTML browsers are simply not equal to their Web browser counterparts. This is made more complex by the wide variety of settings, preferences, security updates, versions, and third-party applications which make the user experience hard to predict. It’s an interesting problem to contend with when you create, design and market HTML email. You’re probably about to hate what I’m about to say, but please don’t shoot the messenger!

You should never use Flash or any other Rich Media piece in your HTML email unless you’re absolutely certain that the email client your recipient uses can handle Flash content. Further, you should only send Flash/Rich Media content to someone who has requested it, or with whom you have an agreed and well-understood marketing relationship. The first time I had to wait almost an hour to download what turned out to be a Flash Email, I was on a Hotel dialup account. That one Flash Email cost nearly $10.00 and an hour of my time – not exactly the relationship you want to enter into with your customers or clients.

But if you absolutely have to send Flash content via email, remember these tips:

Don’t try to control your Flash with active scripting.

Due to the wide variety of email clients, browsers, security settings, updates, and service packs installed, you’ll never know how a script will execute against a particular email client. JavaScripts can cause browsers, Outlook 2000, and patched email clients to disable active scripting contained in an email document (there has been an increase in email security due to malicious scripts).

Consider attaching or sending a link.

The majority of Web-based email clients (Hotmail, Yahoo, etc.) strip out Flash content. So it’s not uncommon to send embedded Flash content only to have the recipient open it in their Web-based client and see absolutely nothing. Similarly, you can’t rely on a <NOEMBED> to provide an alternate link for the content. Include a text link before or after your Flash content for all Web-based recipients and those whose systems, ISP, network security, or other variables interfere with their viewing of Flash content.

You might be better off to attach or send a link to your Flash content, rather than include the content in the email itself. By sending your Flash content as an attachment or a link, you can work around some of the limitations imposed by email clients and browsers. The Flash content will then render in the browser, rather in your email, and, provided the recipient has the plugin, they’ll be able to view the Flash file.

Make sure your files do not immediately start playing.

Control your content with an onClick, trigger or other event. A simple "Click here for an important message" is all you need. Allow the viewer to start the presentation when they’re ready. A Flash or Shockwave piece that begins streaming if viewed in an Outlook preview window, will start a second time when the email is opened.

This will usually cause quite a mess with the recipient’s sound system and distort your intended message. And nothing will get your Flash email deleted faster than if it causes unexpected sounds to suddenly come pouring loudly from the recipient’s computer during the workday.

Rich Media – the Right Approach

These are just a few things you should watch out for if you plan to design, send and expect responses to Flash emails. Flash and other rich media may all be very Year 2001 – "bleeding edge" for the world of Web browsers. However, unfortunately your average HTML Email browser seems stuck at about early 1998.