UPS Silverpop

www.silverpop.com 1866SILPOP (7468767) © 2009 Silverpop Systems Inc. All rights reserved. The Silverpop logo is a registered trademark of Silverpop Systems Inc.

Email Marketing Guidelines & Best Practices


INTRODUCTION TO THE EMAIL CHANNEL ............................................................................................................... 3

BASIC DEFINITIONS ............................................................................................................................................ 4

CONSIDERATIONS FOR THE MARKETER................................................................................................................. 5

Design & Layout Guidelines..................................................................................................................... 5 Fshape Reading Pattern......................................................................................................................... 6 Subject Line ............................................................................................................................................ 6 Contact Information ................................................................................................................................. 7 Words and Phrases to Avoid.................................................................................................................... 7 Optout Links........................................................................................................................................... 7 Test Send Day and Time ......................................................................................................................... 8 What about Outlook 2007? ...................................................................................................................... 8

CONSIDERATIONS FOR THE DESIGNER.................................................................................................................. 9

How Will My Message Look?................................................................................................................... 9 Be Careful with Type Treatment............................................................................................................... 9 Designer Considerations for Images ........................................................................................................ 9 Message File Size ................................................................................................................................. 10 Text Version Different than the HTML Version? ..................................................................................... 10

CONSIDERATIONS FOR THE CODER .................................................................................................................... 11

Basic Coding Suggestions ..................................................................................................................... 11 Document Type Definition and Validation............................................................................................... 11 Flash, JavaScript and Forms ................................................................................................................. 11 Use of CSS ........................................................................................................................................... 11 Inline CSS with Font Styles.................................................................................................................... 12 Style Border .......................................................................................................................................... 12 Coder Treatment of Images ................................................................................................................... 12 Adjustments for Outlook 2007................................................................................................................ 13

TEXT MESSAGE DESIGN & LAYOUT GUIDELINES .................................................................................................. 13

Windows Latin 1 Characters (Special Characters).................................................................................. 14 Forced Breaks....................................................................................................................................... 14 Formatting............................................................................................................................................. 14 Links ..................................................................................................................................................... 14

CODER'S APPENDIX........................................................................................................................................ 15

SILVERPOP EMAIL QUICK LIST...................................................................................................................... 17


Introduction to the Email Channel Since the mid 1990s marketers have been using an exciting new way to reach customers and prospective customers: the email channel. Email is unique in the marketing mix in that it is cheaper, faster and more adaptable than virtually any other marketing channel. And it can also be one of the most effective.

Such a powerful tool isn't without risk. Email has its own unique rules, problems, and complexities. This document provides basic guidelines that you need in order to adhere to best practices in the email marketing messages you send to recipients in the United States, with special attention given to layout, coding and deliverability. It does not provide international considerations and detailed evaluations related to delivery, although most suggestions surrounding other best practices still apply.

This guide contains six main sections:

• Considerations for the Marketer • Considerations for the Designer • Considerations for the Coder • The Coder’s Appendix designed specifically for programmers of HTML emails • Text Message Design & Layout Guidelines • Silverpop Email Quick List a onepage reference guide for all things email


Basic Definitions Like any industry, email marketing uses its own vernacular that those new to the space may not be wholly familiar with. Even if you have been following email for years, terms still can vary widely from person to person. Below you’ll find several words and phrases commonly used in email marketing, and how they are defined for use in this document.

• Browser: A Web browser is a software application that enables a user to display and interact with text, images, videos, music and other information typically located on a Web page at a Web site on the World Wide Web or a local area network. Web browsers format HTML information for display, so the appearance of a Web page may differ between browsers. Some of the Web browsers available for personal computers include Internet Explorer, Mozilla Firefox, Safari, and Opera in descending order of popularity as of late 2007.

• CSS: Cascading Style Sheets (CSS) is a stylesheet language used to describe the presentation of a document written in a markup language. Its most commonly used to style Web pages written in HTML and XHTML.

• Email: Short for electronic mail, email is a storeandforward method of composing, sending, storing, and receiving messages over electronic communication systems.

• Email client: A frontend computer program used to manage email. It refers to true email clients, such as those used by corporations (Exchange/Outlook or Lotus Notes), as well as Webbased email programs called Webmail. Webmail includes the ability to send and receive email from anywhere using a single application via a Web browser. Well known U.S. Webbased email clients include AOL Mail, Gmail, Hotmail, and Yahoo! Mail.

• HTML: HyperText Markup Language, or HTML, is the predominant markup language for Web pages. It provides a means to describe the structure of textbased information in a document by denoting certain text as links, headings, paragraphs, lists and so forth.

• ISP: An Internet Service Provider, or ISP, is a business or organization that provides consumers or businesses access to the Internet and related services. Wellknown U.S. ISPs include AOL, Comcast, Juno, NetZero, Verizon, Yahoo.

• Phishing: Phishing is an attempt to criminally and fraudulently acquire sensitive information, such as usernames, passwords and credit card details, by masquerading as a trustworthy entity in an electronic communication, typically in an email. A phisher is a person who initiates a phishing attack.

• W3C: The World Wide Web Consortium, or W3C, is the main international standards organization for the World Wide Web (abbreviated WWW or W3). W3C was created to ensure compatibility and agreement among industry members in the adoption of new standards. Prior to its creation, incompatible versions of HTML were offered by different vendors, increasing the potential for inconsistency between Web pages. The consortium was created to get vendors to agree on a set of core principles and components, which would be supported by everyone. The W3C Web site can be found at: http://www.w3.org

• XHTML: Extensible HyperText Markup Language, or XHTML, is a markup language that has the same depth of expression as HTML. XHTML is a proposed successor to HTML. As such, many consider XHTML to be the current or latest version of HTML. However, XHTML is a separate recommendation; the W3C continues to recommend the use of XHTML 1.1, and HTML 4.01 for Web publishing.

• Email Spam: Technically, spam is unsolicited bulk email (UBE) or unsolicited commercial email (UCE). “Spamming” is the practice of sending these messages in large quantities to an indiscriminate set of recipients. Most marketers consider spam to be any messages sent without permission, whereas the majority of consumers have a much broader, less tolerant definition. They define spam as any message irrelevant enough to waste their time, regardless of whether they optedin to receive it.


Considerations for the Marketer Design & Layout Guidelines Approximately 90 percent of email subscribers will be looking at your email through their preview pane. The preview pane is a small portion of the available screen where the recipient can view the message without actually opening it. This viewable space is often referred to as “above the fold,” and can be horizontal or vertical. Either way, the top 24 inches (400500 vertical pixels) of your message will be all that is visible. Key content such as message navigation, calls to action and logos should be visible in this critical space.

Inbox and preview pane in Microsoft Outlook 2003

Email clients are sensitive to the width of an email message. Typically you shouldn’t design emails to be much wider than 700750 pixels (though most clients display more than 800 pixels). A historical and more conservative approach would be to limit message width to 600 pixels. This is especially true if you know that a majority of recipients are using Outlook or other clients with a preview pane. In those cases it is possible they may view the message solely from the preview pane.


People rarely read an email in its entirety, so it is a good practice to use summarized information that provides the reader with links to additional information. Studies show that the average reader spends less than three seconds scanning a message in search of something that grabs his or her attention. If someone takes an action, such as clicking a link, that person is likely to invest two to three minutes or more. When crafting your message, begin subheads, paragraphs and bullet points with informationcarrying words that the reader will notice when scanning the left side. Recipients will read the first two words of a line more often than any other part of the line on average. Understanding how readers view email will help you design an effective message.

Fshape Reading Pattern Users first read messages in a horizontal movement, usually across the upper part of the content area. Then they read down the page a bit and read across a second, shorter horizontal line. Finally readers scan the contents left side in a vertical movement. Together this pattern forms an F shape seen in eyetracking heatmaps of user behavior.

Heatmaps from user eyetracking studies of three web pages illustrating the Fshape pattern

Source: Jakob Nielsen, http://www.useit.com/alertbox/reading_pattern.html

Keeping the F shape in mind the first two paragraphs should contain the most important information in your message, and they will most likely read more of the first than the second.

A final note on the F shape is that images, boxes and interesting headlines can break the pattern and prove interesting to readers. The more interesting the message looks the longer the users will dedicate to finding more information they find important. Be sure to take the age of your readers into consideration whenever possible; younger viewers tend to prefer images to text.

Subject Line For marketing messages it is certainly fine for your subject line to convey a sense of urgency, but be wise in word choice. Your subject line should be direct, timely and have relevant impact. To reduce the probability of your subject line being truncated in the inbox, limit subject lines to less than 46 characters counting spaces.

The best practice for subject lines is to test, test, and retest. Sample test several subject lines to a 10 percent random selection in your list and evaluate the effectiveness of each subject line in terms of open and clickthrough rates. After you have tested a number of times you will gain a sense for what works for your subject matter and audience. Keep in mind that subject line effectiveness may change over time, so as a best practice you will want to reevaluate on a regular basis.


Another method for testing subject lines is an A/B test. Create a baseline creative and test it in an email so you know how your audience reacts. Then craft two different subject lines to test, and send a sample of your audience, usually around 10 percent, the same creative using the subject line A and another sample the subject line B. Your control group will receive the standard subject line. Make small changes, one at a time, and track the changes over time.

Contact Information Always include a valid physical postal address in every commercial email you send. It not only provides legitimacy for your content but could be required by the CANSPAM Act of 2003. You should also provide an email address, call center contact information or both. Remember to note hours of operation. And, because email can be a sensitive subject, reassure your readers by giving them a brief description of your email privacy policy and providing a link to your full privacy statement in case they want to learn more.

Words and Phrases to Avoid In years past, it was relatively easy to create a list of words and phrases that legitimate email marketers needed to avoid in order to differentiate their email from spam. However, as the email landscape grows increasingly diverse with more companies turning to email and spammers becoming more sophisticated, the old standards are no longer always as applicable or relevant.

Using the word "free" used to be a oneway ticket to the junk folder, but as more filters move toward reputationbased delivery, this trusted rule is on the retreat. In fact, recent research indicates that many old phrases such as "free" and "click here" are so common that spam filters may not apply any weight to them at all. Using the word "free" in a subject line is probably still not a great idea, if for no other reason than its rampant overuse by marketers, but doing so may no longer affect your path to the inbox.

Generally, words and phrases that are financial, realestate related or sexual in nature will increase a spam score and the probability that an ISP will filter your message before it reaches the inbox. This poses a particular challenge to legitimate marketers in industries that may naturally endure lower delivery rates. But if you can avoid words or phrases commonly used by these industries, you are well on your way to a safer message.

The bottom line is to apply common sense to your message. If it reads like spam then it will likely be interpreted as spam by ISPs and recipients.

Optout Links One practice to consider is to place an optout link at the top and again at the bottom of your email so that your recipient can optout easily from your list. Under CANSPAM law, senders of commercial email must always inform recipients of their right to opt out and provide a functioning optout mechanism that can process optout requests for at least 30 days after an email is sent. Because many email clients disable images by default, be sure to provide a textbased optout link that will still function if graphics are disabled. Transactional email, as its name implies, refers to communications regarding current, agreedupon transactions between the sender and recipient. Transactional messages are exempt from some of the more arduous provisions of CANSPAM. Most notably, senders are not required to provide an optout. The law narrowly defines what constitutes a transactional message.*

Even the best newsletter or marketing message will have individuals who want to unsubscribe. Don’t take it personally. Make your optout conspicuous and easy to follow. If an individual wants off your list you should remove them immediately. Depending on your unique business situation, you may also deem it appropriate to send them an email confirming their change in status. When you receive an optout request, CANSPAM law gives you 10 business days to stop sending email to the requestor’s email address. However, keep in mind that even if you abide by the letter of the law, continuing to send email in the days following an optout almost certainly will annoy your former recipients and may even lead to spam complaints to the ISP. By following best practices you can leave one last favorable impression that may even be able to encourage former recipients to join your communications at a later date.

* Information regarding regulatory issues is provided here only for discussion purposes. You should consult an attorney who is familiar both with the applicable regulations and your unique business situation before taking any action.


Test Send Day and Time To ascertain the best time or day of the week to send your email marketing message, test your message at different times or different days of the week. This will allow you to measure the ideal moment to send your final mailing to your target audience. Do not count on old rulesofthumb or blanket generalizations. The performance of an email message will vary greatly from industry to industry and audience to audience. The only way to truly know the best time and day to send your message is to test it.

To avoid introducing too many variables, don’t try to test your optimal send day and time while simultaneously testing creative and subject lines. Approach your testing scientifically, creating a baseline, and then testing one variable at a time.

What about Outlook 2007? Many marketers have expressed concern about Microsoft's release of the Outlook 2007 desktop email reader platform. Microsoft holds a dominant share of the desktop email reader market. Some estimates put it upward of 6070 percent, which means that for BtoB and BtoC marketers, a good portion of recipients will view messages using an Outlook product.

The source of the worry is Microsoft's decision to abandon Internet Explorer as the rendering engine in favor of the engine from its popular word processor, Word 2007. Although several inherent limitations in Word 2007 can affect email messages, the negative impact will be minimal for marketers who follow the best practices for design and code outlined in this document. The majority of adjustments is around the coding of the message itself and is outlined in greater detail in the Considerations for the Coder section of this guide.

The change will only affect recipients who use Outlook 2007. The Outlook 2007specific recommendations offered in this guide are not necessary for Outlook 2003, Outlook Express 6, and Outlook XP users, but will not alter rendering in those products if employed.

Also note adoption from the previous version, Outlook 2003, was sluggish in 2007 and early 2008 but is expected to grow nearing the next version expected in 2010.


Considerations for the Designer How Will My Message Look? One of the more frustrating aspects of email is trying to anticipate how the message will look when it reaches the recipient. With television or print you can be confident that what you have designed is what will be delivered to the recipient. It is simply not the case with email.

Rendering variations are a friction point between the marketer, designer and coder, and those variations are largely beyond their control. You cannot assume that a design viewed in the design software or test message viewed in an inbox is exactly what each recipient will see. Instead, you must accept that it is merely representative of what recipients will see.

Rendering inconsistencies are complicated because they are influenced by message design, code, email client used to view the message, browser and browser version, and user settings. The two biggest factors that impact renderability are the code and the receiving email client.

Poorly crafted code that employs technologies not supported in email is the easiest to correct. The best practices suggestions in this document will provide you with the greatest chance of having your message render correctly over the widest variety of possibilities. However, even if you adhere to best practice guidelines, your message still may not render perfectly across the overwhelming myriad of possible permutations in which the message could be viewed.

Different email clients, such as Outlook, Hotmail, Lotus, Gmail etc., render code differently and, different Web browsers and versions of those browsers view Webbased email and interpret code differently as well. In fact, even within a single Webbased ISP, multiple email servers with subtle configuration differences can affect your message. What you must keep in mind is that what displays in one email client/browser may not display in another and almost certainly won't display identically.

Be Careful with Type Treatment Traditionally the use of allcaps for type, especially in the subject line, would increase your spamfiltering score. Additionally the use of some colors for HTML fonts can cause problems with deliverability. Bright reds and blues are two such colors. These rulesofthumb may not carry the same weight as they did in the past; however, the use of allcaps is generally regarded as "yelling" in the electronic world, and messages composed of bright red type will naturally look a little suspicious. Use common sense and keep in mind that you are competing in the same inbox as real spammers, so don’t allow your message to look anything like theirs.

Also avoid using unique or nonstandard fonts in an email message. Similar to Web pages, recipients will only be able to see fonts that are resident on their machine. Otherwise, the computer will select a default font, typically Helvetica. To ensure your message looks as intended, choose standard system fonts such as Arial and Verdana in a font size no smaller than a value of “2” for typical body copy.

Designer Considerations for Images Images should be hosted and never attached to an email message. Hosting can be done by your company or by your email service provider. Silverpop includes content hosting as part of its Marketer solution. This allows the images to be downloaded from a Web server when the recipient opens the message. However, many email clients suppress images by default and require users to actively enable images in your message. What is the best way to handle images?

First, view messages without images and construct your email so that it functions even if images are suppressed. If the entire top portion of your message is an image and the recipient views it in a preview pane, he or she will see nothing. Design your message to include some informationcarrying words such as your company name or branding at the top so the reader has a better idea who the message is from and what it is about.


Avoid using background images. If using a background image is unavoidable, be careful to design the message such that the communicative value is not compromised when the image is suppressed. A backup plan is to code a HTML solid color as the background of the table or cell. That way when the image is suppressed there is some color as a backdrop to your message.

Line artwork and text headings should be saved as GIFs and photos or images with gradients can be saved as JPEGs at medium quality optimized for Web content.

Use of animated GIFs is not recommended because most clients will only display the first frame of the animation. That said, if an animated GIF is used, ensure the first frame of animation communicates the purpose of using the image since it is likely all that the recipient will see.

Avoid using images that contain important copy because the copy won't be seen when images are suppressed. Additionally that practice also raises the ratio of images to text, which will increase your profile to spam filters. A good general guideline is to use an imagetotext ratio at 30/70 or below to avoid unnecessary attention by the filters.

Message File Size Message file size can have a direct impact on the success of a mailing. Message sizes over 120K will likely get your message blocked or filtered by a variety of ISPs and email clients. If the message is delivered, the reader may be suspicious of its size, thinking there may be a virus hiding inside. Ideally you will want a message smaller than 75K and around 35K is recommended.

However, those limitations can create a problem when you are composing a message with images to make it more interesting or to break up the Fshape pattern. The way around the problem is to ensure that your images are optimized for use on the Web. Weboptimized images have smaller file sizes and will help keep the overall file weight of your message down to a reasonable level.

Text Version Different than the HTML Version? If your HTML message has a lot of copy, consider that your text version could be an edited version. The text version of a message should be plain and simple. A heavy HTML message will start to look like a book if if you shift every word over to the text version, and that could prove overwhelming to most recipients. Shorten your text version by making bulleted lists and directing your readers to links where they can find more information.


Considerations for the Coder Basic Coding Suggestions The first thing to understand is that HTML coding for Web pages or Web sites is not the same HTML code that should be used for email. As a rule email code is a relatively unchanging technology. Web sites have advanced to include newer versions and styles of HTML. Marketers have become more sophisticated in how they use the information stored in their databases. And, the tools marketers use to send email have incorporated features to meet their growing demands. However, the HTML code appropriate for use in email is very much the same as it was in the late 1990's.

The old tools of the trade for Web page creation, such as font tags and tables, are a staple of email design because they comply with the requirements of most any email client or browser. The quality of your code has a direct impact on how recipients view your messages, and indeed whether they reach them at all. Below is a short list of items to keep in mind. At the end of this document is an addendum with a complete guide to help the coder.

• Choose standard system fonts such as Arial and Verdana in a font size no smaller than a value of “2” for typical body copy.

• Avoid DIV or SPAN tags. • Don't use EMBED tags. • Use inline versus embedded CSS if you have to use CSS at all. It is best to limit the CSS to font treatments

backed up by standard HTML in the event the style is not honored. CSS used for space and positioning should be kept simple limited to basic padding, left, right, and center.

• Limit nested tables to no more than three levels deep. Nested tables may not work at all in Lotus Notes.

Document Type Definition and Validation The first and arguably most important rule for HTML email is to code with the HTML 4.01 Transitional Document Type Definition or lower (see http://www.w3c.org for details on the 4.01 Transitional DTD). Declare the DTD at the top of the code. This practice is valuable in informing the receiving email client what code is being sent and is required for code validation.

Code validation requires very little time and effort but is a critical step not only for message rendering but message delivery. Many email clients and ISPs evaluate the quality of the code of an incoming message as a first test of a marketer’s integrity. Sloppy, errorladen code is associated with spammers, and as stated earlier the goal of every reputable marketer should be to avoid being perceived in such a negative light.

Before testing or launching your message, be sure to validate the code and correct any issues. The best source for code validation is the World Wide Web Consortium (W3C). You can visit http://validator.w3.org/ to validate code by URL, file upload or direct input. Irregularities stemming from proprietary encoding such as those found in Silverpop's Engage product can be ignored.

Flash, JavaScript and Forms Most email clients do not support Flash content. In most cases Flash content will appear as an X or even as raw code. Most clients also do not support JavaScript.

Silverpop does not recommend using forms in an email. Spammers and phishers have used forms to trick recipients into giving up personal information for malicious purposes. Consequently, forms are viewed as negatively as attached images by virus filters.

Think of an email as a stepping stone to a Web page where you can exercise more control over the user experience. Refrain from using fancy code in your email messages, and wait until they arrive at your Web site first.

Use of CSS Modern webpage development has driven coders of HTML email to rely more and more on CSS. As previously mentioned, use of Cascading Style Sheets (CSS) is not recommended. In an email message it is common for information

http://www.w3c.org/


in the head tag of the code to be stripped out completely, so an embedded style sheet will not work. Due to the nature of email, reference to an external style sheet absolutely will not work with most email clients.

The only way to use CSS, if it must be used at all, is in the form of inline CSS. Although you will lose some of the advantages that lead you to use CSS in the first place, using inline CSS is acceptable if you limit your styles to font and basic formatting.

Inline CSS with Font Styles Cascading Style Sheets (CSS) is typically used with specific font references (i.e. 11px) versus the old integer reference (i.e. size="2"). Many email clients will honor a font style, but in case they do not, you should back up the font style with a standard HTML integer size. For example: . This will impart some control of font size where the style is not honored.

When you are working with font tags, especially if also using inline styles, you should get into the habit of putting all paragraph elements in the same order, i.e., in case you need to make documentwide changes. This tip to help ease the pain of not using embedded CSS.

Style Border Perhaps your message creative requires a border. One way to address this problem is to add border images in table cells. However, border images raise the HTMLtotext ratio, and will not be seen when images are suppressed, and can complicate revisions if body copy grows or shrinks, necessitating a resizing of the image. (See the Outlook 2007 section on the dangers on stretching images.) The best way to handle images is to code a table border. A commonly used and web acceptable CSS way to code the border is:

style="border: 1px solid #000000"

However, the shorthand style will cause problems with several popular email clients. You can code the exact same border more reliably with the following syntax:

style="borderstyle:solid; bordercolor:#000000; borderwidth:1px"

Similar to the HTML 4.0 days, email rendering is more reliable when tag attributes are called out individually. It may take a little longer to write but the benefits of sending messages that render usefully for recipients is well worth the extra effort.

Coder Treatment of Images If you are validating your code you will have to include ALT tags on all of your images. According to the Disabilities Act (section 508) all images should include ALT tags even if they are used as spacer GIFs. In the case of spacer GIFS and images that don't lend themselves to description, use an empty tag. When dealing with a logo, banner, or a calltoaction graphic, be sure to include a brief ALT tag. Not only is it required for validation, but many clients will display the ALT tag even when the image itself is not enabled. That may provide the user with enough information to trust your message and want to see more.

Always use height and width attributes on images tags. Specifying the height and width will instruct the code to maintain the position on the page. That can help your message hold its form with images and text even when the images are suppressed. The wireframe effect will help the user know what the message is about and increase the likelihood of enabling the images and continuing to read your message.

If you know that a good portion of your list is going to a corporate client using Outlook, here is a trick to help your messages look better. In most cases Outlook will default to suppressing images. The images are replaced by the display “Rightclick here to download pictures. . .” You can control the way that text looks by adding a style color attribute to the IMG tag. If you don’t want that text to appear on every image, you can set the color to match the color of the solid background behind the image, usually white. Or you could have it appear as another color. Again this trick only works on Outlook clients.


As stated in the designer section, avoid using background images if possible. If using a background image is unavoidable, code a HTML solid color as the background of the table or cell. That way when the image is suppressed there is some color as a backdrop to the message.

Adjustments for Outlook 2007 The recommendations in this document are part of email coding best practices because of their consistency and reliability. When you follow these practices the majority of what is needed to accommodate Outlook 2007 is already done. Nevertheless, you will need to make limited adjustments to help ensure reliable rendering.

As with all other messages:

• Avoiding CSS (or using basic inline CSS). • Avoid DIV or SPAN tags. • Do not use Flash, JavaScript or forms. • Host all images. Do not attach images. • Do not use background images. • Include alt tags for all images including those used for formatting. An empty tag is acceptable. According to the

Microsoft Developers Network the alt tag is NOT supported (http://msdn2.microsoft.com/en us/library/aa338201.aspx), however all available testing has shown that is not the case. Since an alt tag is required to validate your HTML code, be sure to include it.

Specific to Outlook 2007:

• Specify the width and height of all images and make sure the correct dimensions are part of the file properties. Stretched images such as bars or borders may not render correctly even when defined by the HTML code.

• Margins are ignored for images. Consider adding white space to the image. • Align="absmiddle" for images is ignored. • Valign for images is ignored. Outlook 2007 does honor vspace, however the attribute is not compatible in Firefox

or Opera and is not recommended. • Float style is ignored. Use align="left" or align="right" instead. • List styles are ignored, meaning no images for bullets, square bullets or lists without bullets. • Outlook 2007 imposes a minimum height of 2 pixels on all cells, hence a 1x1 pixel transparent GIF with a

background color commonly used for formatting or borders will appear thicker than expected • For best results use width attributes on cells. Outlook will not always size cells appropriately if not defined. • Cell padding is not reliable. Outlook 2007 may place your padding OUTSIDE the cell rather than inside the cell.

Your best bet is to avoid situations where tight spacing is required.

Text Message Design & Layout Guidelines For the email marketer the simple text message is still a necessary evil. It won't include the color and formatting of the HTML version, but some studies report users who prefer it, and text emails sent to mobile devices can have more reliable rendering.

Silverpop Engage as well as most other email providers sends text messages as a multipart MIME message. Multipart MIME refers to sending both an HTML and TEXT part of an email message in a single email. When a subscriber’s email client receives a multipart message, it accepts the HTML version if it can render HTML, otherwise it presents the plain text version.

As more and more clients are able, and even default to displaying HTML, the text message may go by the wayside. This is even truer as more mobile devices become compliant to standard HTML. Today the responsible marketer should still include them.


Windows Latin 1 Characters (Special Characters) Wherever possible use a text editor such as Windows Notepad to create your text messages. Programs like Microsoft Word use a character set called "Windows Latin 1," which introduces special characters that appear as a block or question mark when sent in a textonly email message. Also known as "special characters," typical examples include curly apostrophes or quotes, trademarks, service marks, copyright and registered marks.

If you build your message in Microsoft Word you can turn off these characters through the AutoFormat and AutoCorrect options. Note that you must turn off these options before you compose your message. Additionally if you receive a document with the characters enabled, they will persist and need to be corrected before you send your textonly message.

Regardless of what program created your text version, a good rule is to paste it into a basic text editor. If your apostrophes or quotes appear slanted you should replace them with a straight (vertical) quote by retyping the character. Convert ® or © to (R) and (C). If you see your trademarks or service marks as superscript you will need to retype them as well.

Forced Breaks Do not try to force breaks in your text versions. The problem with forced breaks is to know exactly how to make the break. There are a many different screen resolutions and your user may have the viewing window set to a variety of sizes making your choice no better than a guess. Limit brakes to subheadings and paragraphs, and always put links on their own line.

Formatting Make it easy for the recipient to find important information by utilizing bullets and visual markers. A series of hyphens or equal marks are popular choices to separate sections. To avoid the same issue you would have with forced brakes, limit a row of these characters to about 50 characters.

As with HTML messages, bulleted copy is a good way to make messages shorter and easier to read. Use an astrick (*) or hyphen () to call out each bullet. Do not use the greaterthan (>) to call out bullets. Neither Microsoft Outlook client will properly display a series of > symbols stacked on one another.

Links Always put links on their own line. The main reason for this is if your links appears in a part of the paragraph that wraps to the next line. If your link is broken to two lines it won’t work and it would force the recipient to have to cut and paste the fractured link between your message and their browser navigation bar. Clearly this will not be a good user experience. Putting the link on its own line at the end of the paragraph is the best practice method because it will permit you the maximum amount of space for your link to avoid wrapping, as well as draw attention to the link separated from the paragraph.

Do not use abbreviated URLs beginning with www in the text version. If you are using an email service provider and intend to track the links in your message, you will lose some of your tracking potential because many browsers accessing Webbased email clients will automatically turn anything leading with www into a link. The recipient can follow that link and bypass the tracked link you have placed at the end of the paragraph.


Coder's Appendix

HTML and DTD

• Always validate your code at w3c.org and address any issues before link or image encoding. • Use the HTML 4.0 or 4.01 Transitional DTD and include the declaration.

Body and Head

• Include a "bgcolor" attribute in the main table tag. This will avoid having an unexpected background color when the user has specified custom windows settings. Note do not put this attribute in the body tag because many clients strip all attributes from the body tag.

• Do not use the body tag to set any essential attributes. Many email clients will strip them out completely. Code the desired attributes as standard HTML.

• Be sure to include a <title> tag. Structure

• Specify all alignments and do not rely on a default alignment. Some email clients (Gmail in particular) will center align if not specified.

• When specifying active, and visited link color place them inside the <a> tag. • Avoid DIV, SPAN, or EMBED tags. • Do not use GENERATOR tags. • Avoid specifying TD or TABLE height. • Never use HTML comments to hide structure in an email. Many email clients will show the commented out

structure anyway. If you don’t want it; remove it. • Specify the top level TABLE width.

Tables

• Specify TD widths wherever possible. • Limit nested tables to 3 levels, three maximum. • Do not include any empty cells. Typically used for spacing, an empty cell with height or width attributes is not

following true table structure and will cause problems in some email clients. An empty cell can contain a non space break ( ) with formatting such as font size or an inline style reference.

Images and Fonts

• Avoid using background images. If a background image MUST be used, back the cell with a standard solid color background that will complement the message if the image is not rendered.

• Do not use animated GIFs. • Do not use shorthand values for color attributes (#FFF versus #FFFFFF). • Always specify an alt attribute for images. • Specify the height and width of images so that the code “reserves” the space for your images when they are

suppressed by the email client. • If font styles include size references (11px), back them up with a standard HTML size. For example . This will give some control of font size where the style is not honored.

• When working with font tags, especially if you are also using inline styles, it is helpful to get into the habit of putting all paragraph elements in the same order, i.e. in case you need to make documentwide changes. This is a tip to help ease the pain of not using embedded CSS.

• Avoid allowing a space after a closing , and before a closing or </td>. In some situations the last line in the paragraph will be bumped down from the rest of the copy because the height of the unmanaged space will be higher than the font size used.


CSS / Styles and Other Technologies

• Only use inline CSS. • The "margin" style attribute is unreliable across many clients and is not recommended. • In Outlook only, adding a style color attribute to an <img> tag can allow you to control the color of the text that

appears prompting the user to download suppressed images. Using the same color as the solid background color, usually white, can make the text appear to disappear.

• Do not use Flash content, JavaScript, or forms.

Non ASCII or Special Characters

• Code & to & • Code © to © • Code ® to ® • Code TM to ™ • Do not use smart quotes (curly quotes) or curly apostrophes.

Outlook 2007

• Specify the width and height of all images and make sure the correct dimensions are part of the file properties. Stretched images such as bars or borders may not render correctly even when defined by the HTML code.

• Margins are ignored for images. Consider adding white space to the image for the desired effect. • Align="absmiddle" for images is ignored. • Float style is ignored. Use align="left" or align="right" instead. • List styles are ignored, meaning no images for bullets, square bullets or lists without bullets. • Outlook 2007 imposes a minimum height of 2 pixels on all cells, hence a 1x1 pixel transparent GIF with a

background color commonly used for formatting or borders will appear thicker than expected. • For best results use height and width attributes on cells. Outlook will not always size cell appropriately if not

defined. • Cell padding is not reliable. Outlook 2007 may place your padding OUTSIDE the cell rather than inside the cell.

Your best bet is to avoid situation where tight spacing is required. • Do not use the greaterthan (>) symbol to call out a series of bullets in text versions.

Lotus Notes

• HTML comments must open and close on the same line. Comments with a carriage return within the open and closing element are not honored and the comment will be rendered.

• Do not use nested tables. • Shorthand CSS padding (x,x,x,x) is not honored in many clients including Lotus Notes. • The style element and any style attributes are not supported in Lotus Notes.

Text Version

• Always put link URLs on their own line and not within the paragraph text. • Do not use shorthand URL references leading with www. Browsers will turn these into links that can be followed

by the recipient and won’t be tracked. • Separate major sections of the text with visual elements on their own line such as a series of ========== or

to make the document easier to read. Around 50 characters wide are sufficient. • Avoid forced breaks. Allow text to wrap according to user resolution and window size. • After all editing is complete, turn off text wrapping to help ensure that each paragraph is on its own and free of

breaks. • Convert any symbols to a text equivalent: © to (C) and ® to (R). • Do not use the greaterthan (>) to call out a series of bullets due to issues with Outlook clients.


Silverpop Email Quick List

• Design messages to use the top 24 inches (400500 vertical pixels) for the preview pane.

• Design emails to be no wider than 700750 pixels (though most clients display more than 800 pixels). A more

conservative approach is to limit message width to 600 pixels.

• Limit the subject line to 46 characters including spaces.

• Get in the habit of testing subject lines often.

• Begin subheads, paragraphs and bullet points with informationcarrying words that the reader will notice when

scanning the left side.

• Avoid words and phrases that would appear financial, real estaterelated, or sexual in nature.

• Avoid the use of allcaps in subject lines or body copy.

• View messages without images and construct your email to work when they are suppressed.

• Avoid using images that contain important copy for situations where images are suppressed.

• Avoid using background images; be comfortable with your design if they do not appear.

• Include a valid physical address, contact information and link to your company’s privacy policy.

• Include an optout link for all commercial messages.

• Construct overall message size to be around 35K to 75K.

• Use a text editor to create text versions and be sure to clear out any special characters.

• Put text links on their own line.

• Code with the HTML 4.01 Transitional Document Type and be sure to declare it.

• Validate your code before you send.

• Choose standard system fonts in a font size no smaller than “2” for typical body copy.

• Avoid DIV or SPAN tags; don't use EMBED tags.

• Do not use Flash content, JavaScript or forms

• Use inline versus embedded CSS if you have to use CSS at all. CSS used for space and positioning should be

kept simple limited to basic padding, left, right, and center.

• Limit nested tables to no more than 3 levels deep. However, nested tables won't work in Lotus Notes.

• Images should be hosted and never attached.

• Include ALT tags on all of your images.

• Use height and width attributes on images tags.

• Look closely at your performance and test creative often, one variable at a time.

Date post:	08-Feb-2016
Category:	Documents
Upload:	david-ogilvy
View:	39 times
Download:	0 times

UPS Silverpop

Documents