Chapter 16
HTML for Email
Key Skills & Concepts
• Determine Whether HTML Email Is Appropriate for Your Needs
• Don’t Send Spam
• Identify the Necessary Tools for the Task
• Code for Email Readers, Not Web Browsers
• Test, Test, Test
The year 2013 marks 14 years since the first edition of HTML: A Beginner’s Guide was written. Throughout the bulk of those years, the rise of CSS has had the biggest impact on web designers and developers (and ultimately on web users). Perhaps the second most important change for web designers is the widespread support of HTML and CSS by email readers.
Indeed, at the end of the twentieth century your email inbox was a lot less colorful (and most likely a lot less full). HTML emails bring color, images, formatting, and much more interactivity than their plain-text counterparts. While most companies still provide plain-text emails to customers who request them, the vast bulk of business marketing and advertising email now sent is HTML-based.
NOTE
Because the bulk of HTML email is sent from businesses, this chapter focuses on creating HTML emails for marketing and advertising purposes.
For the web designer, this brings a whole new avenue of work opportunities, as well as new headaches. Why? Because an HTML email is essentially just a web page. So if you can design and code web pages, you can design and code HTML email.
The reason for the headaches is this: Support for HTML and CSS is growing among email readers, but it still lags behind on many fronts. In fact, coding HTML for email in 2013 is a bit like coding HTML for web browsers was a decade ago—which means you’ll spend a lot of time testing, and testing, and testing, and revising and testing some more.
Email Standards Project
At the beginning of this book, I discussed the W3C and its role in creating web standards. In November 2007, a group of people got together to form the Email Standards Project. This organization works with email client developers and the design community to improve web standards support and accessibility in email.
Over the past five years, the folks behind the Email Standards Project have talked with Yahoo!, Google (Gmail), and IBM (Lotus Notes) about improving their respective email clients. While this is undoubtedly a slow process, there is great hope among the design community that this organization will help bring the same level of consensus that the W3C brought on the web browser front.
You can download the Email Standards Project’s “Acid Test” to see exactly how they tested each email client. You can also view the results of their tests, and learn more about the movement, at www.email-standards.org.
Determine Whether HTML Email Is Appropriate for Your Needs
Before we jump into the details of coding HTML emails, we need to have a brief conversation about whether it is appropriate for you or your project. To make that determination, consider the following pros and cons.
The Purpose of Email Is to Communicate
At the end of the day, we use email to communicate with each other. While there certainly are many forms of communication, email has traditionally used written language to communicate. All email readers allow users to read written text. This is the most basic requirement of any email reader.
When you start styling that text with color and other formatting, you stop relying on the written word to communicate your message. Suppose, for example, you received an email from a friend. In that email your friend listed the menu for a bridal shower you were helping to throw next weekend, and then included the following line at the bottom: “Thanks for helping with the party! I highlighted the items I still need. Can you help with any of them?”
If your email program is set to read email as text-only, there won’t be any highlighted text in that email. In instances like this, the communication method moves from the written language only to include visual clues like highlighting. Before you make the decision to send HTML emails, you need to determine the specific message of the emails being sent and whether or how any extra formatting will affect that message.
The End-User Display Is Unknown
Unlike web browsers, which have become much more uniform in their display and support of HTML, email readers are plentiful and vastly different from one another. Consider all the ways you read email. If you have a Yahoo!, Hotmail/Live Mail, or Gmail account, you probably read your email in a web browser.
But, you still have the option to read your email in a stand-alone email program like Outlook or MacMail. And if you are like a growing number of people, you might also check your email on a mobile phone like a Blackberry or iPhone. I just named off seven different ways to read an email, and I’m only getting started!
It is virtually impossible to know how your HTML emails will display when read by the end user. Testing in as many of the popular email readers as possible is certainly important, but ultimately you must make smart design decisions that ensure the widest possible audience can still glean the message being communicated. Keep this in mind when deciding whether HTML is the best delivery method for a particular email.
Plain-Text Email Is Safer and Smaller
Due to the proliferation of HTML email spam, the simple truth is that plain-text email is more likely to actually get to the reader. This may mean that the most important email communication with a customer—such as receipts—should be kept in plain text.
For example, many email readers block images and attachments from unknown senders or suspected spammers. One reason this happens is that anything attached to an email is capable of harboring viruses and other malicious code. Also, when you send HTML email with images stored on a web server, you can tell whether an email was opened by simply reviewing the site’s access logs to see if the images were displayed. This allows spammers to differentiate between active email addresses and bad email addresses.
In fact, HTML emails are more likely to be tagged as spam simply for having embedded images. That means your beautifully designed HTML email may end up in a customer’s spam bucket and eventually in the trash without the customer even knowing it.
Another reason HTML email might not make it to the target destination is size. If you get a little crazy with large images and hefty attachments, you can cause someone’s email system to slow down drastically or even crash.
But … HTML Email Marketing Works
Now that I’ve given you several reasons HTML email might not be appropriate, I must state the obvious: HTML email can definitely be more appealing. Let’s face it, most of us react more quickly to an image of a double-dip chocolate ice cream cone on a hot summer day than we might to those words mixed in with other text in a crowded paragraph. As the saying goes, “a picture is worth a thousand words.”
The simple truth is that when done right, HTML email marketing works. Here are a few of the reasons:
• Cost effective Advertisers who used to rely on expensive print-mail campaigns are largely embracing HTML email as an efficient way to get their message in front of customers more quickly and less expensively. While design costs might be similar, the cost of sending a thousand emails is significantly less than the cost to print and snail-mail a thousand postcards to customers.
• Targeted While most companies do target certain ZIP codes when sending snail-mail ads, email advertising allows you to target very specific demographics and behaviors. For example, suppose you are a customer of a certain grocery store who has recently started offering delivery. Being interested in the service, you viewed a page on a company’s web site describing this new service, but you never actually purchased it. Because you were logged in to your account with this company at the time you viewed the delivery page, they decide to send you a targeted email ad offering free delivery on your next order. Such targeted emails tend to be highly successful.
• Timely Email advertisements can be sent within seconds of certain events. Wake up to a snow day? Why not send a special “snow day savings” email to parents of elementary school students? Customers could be reading your HTML email (and making purchasing decisions) before a snail-mail equivalent even reaches the printer.
• Fosters relationships Companies have long known that loyal customers are often the best ones. If you can keep a customer happy, you stand a good chance at keeping her a customer. Email—particularly HTML email with some interactivity—provides an effective tool for building and maintaining customer relationships.
At the end of the day, you can measure the success of any email marketing campaign with the right software. Businesses can tell how many people opened the messages, what links were clicked, who saw which versions (HTML or plain text), and even the revenue each generated. So it is relatively easy to stop sending out campaigns that aren’t working, and to try something new.
Don’t Send Spam
Before you start writing your HTML emails, you must know about the audience. From a legal standpoint, the most important thing to know about your audience is whether you have permission to contact them in this manner and for this purpose. In addition, you must always provide a reliable method for users to opt-out, or stop receiving your mail. In short, spam is any mail sent without the permission of the recipient.
Email the Right People
So how do you gain permission from recipients? Here are a few guidelines in that regard:
• You can send email to current customers. Most people consider anyone who has purchased from you within the last two years to be a “current” customer.
• You can send email to people who request information from you, either in person or online. Keep in mind that you can only send them email about relevant topics. In other words, if someone responds to a job posting on a company’s web site but isn’t hired, you can’t start sending him marketing email about your products.
This means you can’t harvest email addresses off email forwards or those found on the Internet. Just because I post my email address on my personal web site, that doesn’t mean I want to receive marketing email from any business who visits my web site.
While it might be very tempting to send mass emails to strangers in the hopes that one might become a new customer, it is much more effective to target people who have already expressed an interest in your business or product.
TIP
If you’re working with a business that is unsure whether their marketing list is legal, consider checking the guidelines presented by email marketing giant Campaign Monitor: www.campaignmonitor.com/guides/permission.
Always Provide a Way to Opt Out
Federal guidelines require you to always provide a way for someone to tell you he no longer wishes to receive your emails. At a bare minimum, this means you must provide a valid return address to which users can send a “please remove me” email. Most reputable email systems offer efficient unsubscribe mechanisms that allow recipients to opt out through an online form linked from all emails.
Federal guidelines further require you to keep such unsubscribe methods available for at least 30 days after emails are sent. After receiving an unsubscribe request, companies have 10 days to stop sending the recipient email.
Adhere to Other FTC Rules
To avoid your email being considered spam, you also must use legitimate headers and subject lines. In other words, you can’t send an email with a subject of “FREE delivery on your next order” unless the offer is valid and indeed available to recipients. The from and reply-to email addresses must also be active.
Your company’s business name and physical mailing address must also be visible in the email.
TIP
Check out business.ftc.gov/documents/bus61-can-spam-act-compliance-guide-business for more information about the Federal Trade Commission’s CAN-SPAM laws.
Identify the Necessary Tools for the Task
Now that we’ve discussed why you might send HTML email, let’s move on to how. You’ve already learned that you can type HTML code in just about any text editor, but in order to be viewed by a web browser, it must be saved with a certain file extension (such as .html). Similarly, you can type HTML code into an email, but it will just look like a bunch of code unless you send it through the proper channel.
Send Live Web Pages with a Personal Email Account
As I mentioned, an HTML email is really just a web page. Have you ever wanted to email a web page to someone? The method depends on your email software. If you have Apple’s Safari browser, you simply navigate to the page you want to send and choose File | Mail Contents Of This Page. Next, the page will display in an email in MacMail. Simply address it and send it off!
You can also use Internet Explorer 7+ to send a web page via email. If you use the web-based Hotmail/Live Mail, choose Page | Email With Windows Live. If you don’t use web-based email, but have Outlook or some other email software installed and set up on your system, choose Page | Send By Email. (This option is grayed out if you don’t have an email account currently set up on your system.)
These methods are useful when you want to share a web page with family or friends. However, you wouldn’t use these methods to send out mass business email for several reasons. First, most Internet service providers (ISPs) limit the amount of bandwidth you can use on a daily or monthly basis. Sending lots and lots of HTML email will likely have your ISP hounding you pretty quickly. In addition, sending bulk email through your business or personal server runs you the risk of having all your email blocked as spam.
Using an Email Service Provider
The best method for sending bulk HTML email is to use an email service provider (ESP). Similar to an Internet service provider, an ESP handles all aspects of bulk email delivery, from managing the recipient lists (both subscribe and unsubscribe features) to tracking the number of times each email is opened and clicked.
Just as there are hundreds of ISPs out there, you also have your choice from quite a few ESPs. As a freelancer, I have used a fair number of ESPs for different businesses. Each has its pros and cons, depending on the business and its audience.
When researching ESPs, here are a few things to look for:
• Contact management tools to handle your subscriber list
• Email creation tools to help format and lay out the content
• Email sending tools to help you test your emails
• Design services to help with graphic design and creative support
• Email reporting tools to help you track things like click-throughs, opens, and conversions
• Ease of use
• Support
As with any software, I encourage you to try before you buy. ESPs typically charge either a monthly fee or per-email/per-recipient fees (or a combination of both). Many also offer rebranding tools to allow designers to create their clients’ emails, and then give the clients the tools to send and manage them. A few of the most popular ESPs include
• Blue Hornet (www.bluehornet.com)
• Campaign Monitor (www.campaignmonitor.com)
• Constant Contact (www.constantcontact.com)
• Emma (www.myemma.com)
• iContact (www.icontact.com)
• Lyris (www.lyris.com)
• MailChimp (www.mailchimp.com)
NOTE
If you are considering sending bulk mail, run (don’t walk) toward these ESPs as fast as you can. I strongly discourage you from using your personal email account and email software to send any amount of bulk mail. The risks are just too great, and the benefits too small to justify it.
Code for Email Readers, Not Web Browsers
I’m now going to tell you a few things about HTML that apply only when you’re coding HTML for email. For instance, because of the inconsistency of support for HTML5 and CSS3 among email readers, I’m actually going to suggest you use HTML tables for reliable layout! Gasp! While I would never suggest you use HTML tables to lay out an entire web page (as we used to before the rise of CSS), I am suggesting you use tables to lay out complex designs for email. I know it’s a bit backward and awkward, but bear with me for a few minutes.
The most important differences in coding for email readers instead of web browsers are outlined in the following sections. But before we delve into those, we first need to determine exactly which email readers we’re talking about.
According to Campaign Monitor (www.campaignmonitor.com), the top three email clients used in 2011 were Outlook, iOS devices, and Hotmail, with Apple Mail and Yahoo! Mail quite close behind. When we look at consumer recipients, the top three clients remain the same, but change in market share. Refer to Tables 16-1 and 16-2 for the complete lists.
Table 16-1 The Top Ten Email Clients Used by Business Recipients (Source: fingerprintapp.com/email-client-stats)
Table 16-2 The Top Ten Email Clients Used by Consumer Recipients (Source: fingerprintapp.com/email-client-stats)
Ultimately, you must determine which email clients to target in terms of your project’s desired audience. And just as with traditional web pages, you must test as much as possible within your target email clients. As a designer who frequently creates HTML email for clients, I have email accounts set up in all the top five email clients specifically to use for testing HTML email.
Now, on to the recommendations.
Absolute Paths
You must use absolute paths for all links and images. Remember Chapter 7, where I gave you the option of using either absolute or relative pathnames for links? Because your email is downloaded and displayed on the reader’s system, you need to make sure all images are stored on a web server and referenced with complete, absolute URLs (i.e., those that start with http://). Likewise, all links to other web pages or content need to include the http://.
Images
There are three key points I’d like to make about using images in HTML email.
You Can’t Rely on Images to Transfer Your Message
Image blocking is much more common in email readers than web browsers, so you need to provide text-only methods for readers to access your information. This doesn’t just occur when images are placed in the trash or spam bucket. In fact, some email programs (such as Outlook, AOL, and Gmail) have default settings blocking images in email from unapproved senders.
Figure 16-1 shows how an email from an unknown sender shows up in my Gmail inbox by default. After receiving emails like this, the user can tell Gmail to display the images in a single email or always display images in emails sent by this sender (making Sears a “trusted sender”). Tables 16-3, 16-4, and 16-5 cover the default settings in popular email clients, courtesy of Campaign Monitor, as of this writing. Refer to www.campaignmonitor.com for up-to-date resources of this nature.
Figure 16-1 Gmail blocks images by default in email from unapproved senders.
Table 16-3 Image Blocking in Web-Based Email Clients
Table 16-4 Image Blocking in Desktop Email Clients
Table 16-5 Image Blocking in Mobile Email Clients
Now that you know what you’re up against, here are a few steps you can take to help ensure your emails still work if the images are blocked:
• Always include alternative text so that those email readers that do recognize it still show something in place of any blocked images.
• Always provide an alternative way of viewing the information. This may be plain-text content or a link to view the email in a web browser instead.
• Always include every image’s height and width values in the
img tag. This allows the email reader to leave the appropriate amount of space as a placeholder so that your entire layout isn’t compromised.• Always test your emails with images turned off so that you know what to expect.
All Images Must Be Stored on a Live Web Server
I know I already mentioned this a few pages back, but I can’t stress how important this is. In order for images referenced in an HTML email to display once they are downloaded by the recipient, they must be stored on a live web server and referenced with an absolute URL. So, your images will not work if your code looks like this:
Where should you store your images? These are the two most common scenarios:
• Create a folder on your company’s web server to house all email files. In this case, your image references might look like: 
.
.• Store the images on your ESP’s web server. Many ESPs offer space to their clients to house all email-related files. If you go this route, your image references might look like:
Images Should Be Small in File Size
While many people have significantly increased the speed at which they connect to the Internet, email bandwidth is a whole different ball game. Most people do not have an unlimited amount of email storage space. If you send large HTML email, you risk bogging down your recipient’s email, or, worse yet, filling up her inbox.
Tables for Layout
You should use tables for structuring content. If you need to create columns in your email (such as are common with email newsletters), the only widely supported method of doing so is HTML tables.
TIP
When it comes to HTML for email, simple layouts are best. Complex page designs are not only more difficult to achieve successfully in HTML for email, but they are also less likely to be appreciated by users. Always remember how quick you typically check your inbox, and recognize your customers are devoting the same amount of time—not much—to reading their email.
I know, I know … anyone who has been around the web industry for any number of years likely thought table-based layout was a thing of the past. Indeed, so did I! Up until the advent of Outlook 2007, things actually looked promising, and most designers expected to be using CSS for email layout by that time.
But unfortunately, Microsoft built Outlook 2007 to use the Microsoft Word rendering engine for displaying HTML emails instead of Internet Explorer. When this news was announced, there was a ton of uproar among those who code HTML email. If you’ve ever actually viewed a web page inside of Microsoft Word, you probably are already groaning.
Here are the major issues with Outlook 2007:
• No background images in divs or table cells
• No background colors in nested tables or divs
• No support for the
float or position properties in CSS• Very poor support for
padding and marginsThe third bullet point—no support for the
float or position properties—is what causes us to need tables for layout again. Those two CSS properties free us from using tables for pages viewed in web browsers. Without either of them, we must resort to the “old-fashioned” method of putting all the page content within table cells.TIP
Refer to Chapter 11 for a refresher on using tables. For specific tips related to using tables for email design, check out www.campaignmonitor.com/resources/will-it-work/guidelines.
Compare Figures 16-2 and 16-3 to see an example of how a table-based layout might work for an HTML email. Figure 16-2 shows the layout in “Expanded Tables mode” in Dreamweaver, which allows you to see which pieces of the design are in which cells. Figure 16-3 shows the final, completed layout with the table border hidden.
Figure 16-2 With Dreamweaver’s Expanded Tables mode, you can easily see which pieces of the design go where.
Figure 16-3 After the table borders are hidden and the view is returned to normal, the layout is seamless.
NOTE
Always define the width of your table cells when using them for layout in HTML email to ensure your layout stays as you intend it to.
Inline CSS
All CSS should be inline. This essentially means when you are coding HTML for email, you can ignore what I told you in the first few chapters about internal and external style sheets, because many email readers ignore those. As a refresher, here’s an example of an inline style:
Check out Tables 16-6, 16-7, and 16-8 to see how the popular email clients stack up when it comes to internal, external, and inline style sheet support.
Table 16-6 CSS Support Among Desktop Email Clients
Table 16-7 CSS Support Among Web-Based Email Clients
Table 16-8 CSS Support Among Mobile Email Clients
Ask the Expert
Q: In previous chapters, you discussed creating fixed-width vs. liquid pages. How does that argument apply to HTML email?
A: While I encourage you to use flexible (liquid) page layouts whenever possible on the Web, HTML emails are a bit different. In fact, if you receive any amount of business email, you’ve probably already determined that most are fixed-width instead of liquid. This is due in part to the reliance on tables for layout (CSS more easily adapts to varying page sizes). But also, HTML emails are displayed within email readers, with lots of other elements fighting for screen space. Most people have a list of mailboxes, then mail within those boxes, plus other navigation, all surrounding the actual email. Therefore, it is recommended that you not design HTML emails wider than about 600 pixels.
When it comes to height, you must consider how much of your email needs to be visible in the “preview pane.” This is the part of the email that is visible by default before the recipient decides to click and read more. Some research shows the average preview pane to be around 300 to 500 pixels tall. Keeping in mind how quickly people scan their inboxes, it is wise to place the most appealing and compelling aspects of your email in the top portion that is viewable in the preview pane.
In addition, consider including a brief line of text at the very top of your email that gives an overview of what’s included. This is particularly important for Gmail users, who only see the first line of text in their preview pane. A reasonable example might be: IN THIS ISSUE: Upcoming Car Shows, How to Save on Insurance, Car Seat Safety, and more.…
As you probably noticed, Gmail is the real reason I suggest using only inline styles. No currently available version of this popular web client supports internal or external styles.
No Shorthand
While you’re steering clear of internal and external style sheets to reach the widest possible audience, you should also avoid all CSS shorthand. Instead, write out every complete style declaration. For example, while it is perfectly acceptable to write:
this type of shorthand is not very well supported by email clients. So, you’ll need to write each individual property and value, as in:
Reference Guide to CSS Support in Email Clients
Campaign Monitor, a fabulous ESP and wonderful resource for all things HTML email, is part of the Email Standards Project. As such, they have a ton of information about CSS support among the most popular email readers. I’ve included (with permission) some of their most recent research, as of this writing. For updates, refer to www.campaignmonitor.com/css/ and www.email-standards.org/clients/.
First, Table 16-9 lists the most common CSS properties and how they are supported by common desktop email clients. Next, Table 16-10 compares the support of those same CSS properties, but this time among popular web-based email clients. Then, Table 16-11 runs through mobile email client support. I encourage you to consult these tables (and their online counterparts) when deciding how to best code your HTML emails for your target audience.
Table 16-9 CSS Property Support Among Desktop Email Clients
Table 16-10 CSS Property Support Among Web-Based Email Clients
Table 16-11 CSS Property Support Among Mobile Email Clients
Interactivity and Multimedia in HTML Email
After you’ve designed a few HTML emails for someone, they’ll likely start to ask about adding more “pizzazz” to those emails. Thus, the question always comes up about including video, Flash, and forms in HTML email.
Video in Email
Video is not common in email, largely due to security concerns and lack of widespread support. As with all multimedia, you must first consider whether it’s warranted and accepted by your target audience before even worrying about how to add it.
Thankfully, some testing has been done to determine exactly what support does exist. (Refer to www.campaignmonitor.com/videoinemail for the complete test results.) But unfortunately, the results aren’t pretty: The only email tool that supports any sort of video in email is Apple Mail. As of this writing, the only reliable way to include any sort of motion graphics in an email is with an animated GIF. And, there is no support for sound at all in any email reader. So in short, you cannot realistically add video to your HTML emails.
Flash
I’m afraid the results aren’t any better for Flash lovers. In fact, Apple’s MacMail is the only email client to offer native support for Flash files. While you can include a “fallback” image when embedding Flash files in normal web pages, for browsers to display when the Flash player isn’t available, most email clients won’t even let you do that.
So again, you cannot realistically add Flash to your HTML emails.
Forms
Imagine sending out an invitation via email. Wouldn’t it be nice to embed a form inside that email so guests could simply click “yes” or “no” and then hit the Submit button to reply? While the concept sounds great, email clients haven’t quite caught up yet.
Although most of the email clients tested by Campaign Monitor do display forms correctly (all except Outlook 2007), only about half allow the form to be functional. Those email clients that do allow functioning forms include Yahoo! Mail (the new version only), Gmail, MacMail, Thunderbird, Penelope (aka Eudora 8), Outlook Express, Windows Live Mail, Lotus Notes 8, and Entourage. Among the notables left off that list are AOL, Hotmail, and Outlook (both 2003 and 2007).
Given this information, your best bet is to link to a form displayed in a web browser until email clients offer more widespread support.
Test, Test, Test
After you’ve coded your HTML email, the fun really begins. While we’ve come to the point where web pages that work in Firefox and Internet Explorer are considered “safe” for the Web at large, HTML email still requires extensive testing in multiple clients.
Thankfully, many ESPs offer services to make this process easier. For example, Campaign Monitor provides screenshots to show how your email will look in more than 15 of the most popular email clients, including the potential problem areas like Outlook 2007 and Lotus Notes, plus mobile clients too. Visit www.campaignmonitor.com/testing to learn more. Figures 16-4, 16-5, and 16-6 show how the same test email displays differently depending on the email client. These screenshots are samples taken using Campaign Monitor’s testing tool.
Figure 16-4 The sample email as it displays in Outlook XP
Figure 16-5 The sample email as it displays on a Blackberry
Figure 16-6 The sample email as it displays through web mail in Gmail
Another great option is a stand-alone testing tool like Litmus. Billing itself as the “advanced testing tool for web professionals,” Litmus offers testing for both standard web pages and HTML email. Litmus’ basic account offers unlimited email and page tests per month. Additional fee-based options allow spam filter tests and email analytics. Visit http://litmusapp.com for details.
Spam Test
One of the unique aspects you can test is the likelihood of your email being flagged as spam. Many of the popular ESPs offer this testing with their email messaging services. (If yours does not, there are other tools you can use. For example, the Email Spam Test at www.emailspamtest.com is a free service from Blink Campaign.)
SpamAssassin is the most widely used spam filter to process email received by ISPs. If your email gets blacklisted by SpamAssassin, you’ll have a hard time getting your content in front of any of your subscribers. Refer to spamassassin.apache.org to learn more.
Wondering what might cause an email to be flagged as spam? Here are just a few of the many reasons SpamAssassin might give you a higher “spam score.” (And in this case, higher is not better.)
• HTML link text says “click here” (I warned you in Chapter 6 not to do this!)
• A WHOLE LINE OF YELLING DETECTED
• Messages that include “Dear Friend” or “Dear (Name)”
• Message that contains “call” or “dial” or “toll free” followed by 800, 888, 877, 866, 855, 844, 833, or 822 (for example, “Call 1-877-555-5555 for your offer now!”)
• Messages with the phrase “risk free” and other spam keywords
• HTML title contains “Untitled” (always title your web pages, even if they’re being emailed!)
TIP
Want to know more about how spam filters work? Check out www.mailchimp.com/resources/guides/how-to-avoid-spam-filters.
| Try This 16-1 | Design an HTML Email |
Why not give your HTML skills a real test by putting them in front of some good old-fashioned email readers? This project asks you to create an HTML email advertising the new web site you’ve created. The goals for this project are
• Coding an HTML page for email readers, not web browsers
• Testing an HTML page in an email reader
NOTE
This project requires you to upload your test email to a live web server. If you don’t currently have access to a web server, check with your ISP (which may provide space on its site free to customers), school, or business. You will be unable to test an HTML email without access to a live web server because all images in HTML email must be stored on the Internet in order to be accessed by email readers. Alternatively, you could sign up for an account with one of the ESPs listed previously in this chapter.
1. Open your text or HTML editor and create a new HTML page.
2. Add graphics and text created throughout the course of this book to advertise the new web site you set up. Be sure to use full, absolute paths when referencing images and other links.
TIP
In the case of HTML email, less is more. So I suggest using a few key images, and perhaps a screenshot of the new web site, mixed with a brief paragraph explaining the new features of the site.
3. Format the content to display in the most popular email readers, as discussed previously in this chapter.
4. Make sure all the images and some highlighted text link to the new site.
5. Save the file.
6. Upload your saved file to a live web server.
7. Open Safari on the Mac or IE on the PC.
8. Enter the address of the file you just uploaded in the address box in the browser.
9. In Safari, choose File | Mail Contents Of This Page. In IE, choose Page | Send By Email if you have an email account set up in Outlook, or choose Page | Email With Windows Live if you use a web-based email tool. Enter a few different email addresses to send test messages of your HTML email.
10. If you need to make changes, return to your text or HTML editor to do so. After making changes, save the file, reupload it, and switch back to the browser. Choose Refresh or Reload to preview the changes, and then repeat Step 9.
HTML email is a whole different breed. While web browsers are fairly uniform in their display of HTML pages, email readers still have a long way to go to reach this point. Designing HTML email involves lots of patience as you design, test, and redesign. This project gave you a glimpse into that process using a sample marketing email for the company or organization of your choice.
Ready for more practice? I encourage you to sign up for a free test account with one of the ESPs mentioned in this chapter. Then, try re-creating your sample marketing email using their web-based creation tools. Each ESP offers different options, but all provide the messaging services necessary to send bulk HTML email safely and securely.
Chapter 16 Self Test
1. True/False: The W3C maintains a special specification for HTML email.
2. Fill in the blank: _____________ is any email sent without the permission of the recipient.
3. What is the difference between an ISP and an ESP?
4. Fill in the blank: You must use _____________ paths for all images and links in HTML email.
5. Why should you avoid relying on images to translate key messages in HTML email?
6. Which type of style sheets should be used for all HTML email?
A. Inline
B. Internal
C. External
D. Linked
7. Why must we rely on tables for column-based layout in HTML email?
8. Which methods of adding interactivity to HTML email are widely supported by email readers? (Select all that apply.)
A. Flash
B. Video
C. Forms
D. None of the above
9. True/False: It is acceptable to use CSS shorthand in HTML email.
10. Why should you avoid using background images in tables in HTML email?
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.