Tag: email design

Guide to a Better HTML Email Design – Part 5

4. Using Forms in HTML Emails
We generally discourage the use of forms in email to prevent delivery or usability problems. However, at times you might still need to use a form in an email instead of directing readers to your Website. Consider these factors before you use a form in your next email message.
Those recipients of your email who use Hotmail or those who use Outlook 2007 will not be able to use the form because:

  • Hotmail displays the form but strips all values from your <FORM> tag and removes the name values of all form elements, rendering the form useless.
  • Hotmail recipients can complete the form, but nothing will happen when they hit the submit button so they will not know it has not been received .
  • Outlook 2007 has limitations when viewing forms in the mail client. Outlook 2007 cannot see data in a “form tag”, when a form is passed via email and viewed in Outlook 2007 as outlook strips out form elements.

Refer:

http://help.isu.edu/index.php?action=knowledgebase&catid=38&subcatid=39&docid=1058
http://www.sitepoint.com/blogs/2007/01/10/microsoft-breaks-html-email-rendering-in-outlook/

Some email clients do not support forms that use “POST” method, which allows form data to appear within the message body. Instead you will need to replace it with the “GET” method, which will write all form content to the query string of the page to which the form is posted.
For example: <form method=”get” action=”http://…..>

Most email clients that provide a preview pane don’t allow you to tab between form elements. This means that when a recipient completes the first field in your form and clicks the TAB key, the focus is automatically shifted to another part of the software. This hinders usability and can confuse your recipient.

 

Form based mailer Format

1. Form tags needs to be defined for the section that has the form details/elements to be captured.
2. Specify relevant names for the data capture elements.
3. All the data validations should be done on the server side at the client’s end.
4. Specify the form Method as GET.
5. Define appropriate action for the form. The action should ideally take them to the page which captures and validates data on the server side at the client’s end.

Once data is validated then appropriate action needs to be taken, the process should be as follows:

– Data should be captured from the GET parameters.

– Once the data is captured, validate the data.

– If everything is fine, then it should take the user to a Thank You page hosted by the client.

– Else, it should redirect to the same or similar form page which will be hosted by the client, where all the errors should be highlighted and data should be pre-populated if needed

6. There should be no Javascript code present in the email html.

Sample code snippet

<form method=”GET” action=”http://” >

<table>

<tr>

<td>Name : <input type=”text” name=”name” value=””/></td>

</tr>

<tr>

<td>Email : <input type=”text” name=”Email” value=””/></td>

</tr>

<tr>

<td><input type=”submit” name=”submit”></td>

</tr>

</table>

</form>

 

Read earlier blogs on the same subject.

Validate HTML Content and Avoid Using Scripts – Guide to a Better HTML Email Design – Part 4


HTML Email Coding Guidelines – Guide to a Better HTML Email Design – Part 3

HTML Email Layout – Guide to a Better HTML Email Design – Part 2

Guide to a Better HTML Email Design – Part 1

Share

Guide to a Better HTML Email Design – Part 4

3. Validate HTML Content and Avoid Using Scripts

The vast majority of HTML emails do not comply with World Wide Web Consortium (W3C) HTML standards. This can cause rendering and delivery issues, particularly at AOL, MSN and Hotmail. AOL, for example, has a that is an HTML validator, which scans incoming messages for HTML syntax and formatting errors. If it detects invalid HTML, it will reject the message.
If you use HTML in your messages, make sure your code is error-free and follows W3C HTML standards. Popular HTML-editing software such as Homesite or Macromedia Dreamweaver already offer effective validation tools and will highlight any errors as you create your message. For a complete reference spec of HTML formatting, visit the World Wide Web Consortium documentation pages. Also, you can use the HTML validator in your email application or a third-party validator such as W3C Markup Validation Service.

Also, avoid scripting. Scripting languages, which can be imbedded within HTML, are often used to add dynamic functionality to a Web page. However, security risks due to script vulnerabilities in email browsers have increased over the years. The result is most scripts, such as JavaScript and VBScript, get stripped out of messages. Some email systems reject messages outright if they detect scripting. For greatest compatibility, avoid using scripts in messages. Instead, drive your readers to your Website, where dynamic components are easily rendered.

 

Read earlier blogs on the same subject.

HTML Email Coding Guidelines – Guide to a Better HTML Email Design – Part 3

HTML Email Layout – Guide to a Better HTML Email Design – Part 2

Guide to a Better HTML Email Design – Part 1

Share

Guide to a Better HTML Email Design – Part 3

2. Email HTML Coding Guidelines:

a. HTML Coding Do’s

  • Code HTML emails as a single Web page with the basic <HTML>, <HEAD>, <TITLE>, and <BODY> tags.
  • Code emails by hand where possible, as WYSIWYG (What You See Is What You Get) editors typically add extra code that creates havoc with certain email clients. If you must use an editor, use Dreamweaver or Homesite, which do not add extra code to the design process.
  • Use HTML tables for the design layout.
  • Keep emails at a fixed width of between 500-620 pixels wide.
  • Instead of defining percentage widths use fixed widths. While this is not optimal, because people can and do resize their email windows when reading, sometimes using a fixed width is the only way for a layout to display properly in multiple email software.
  • Use only the ASCII character set. More advanced word-processing software often inserts odd characters, such as the trailing dot characters or smart quotes (curly instead of straight), which can hamper display or create delivery problems in some email software.
  • If you use CSS, include inline styles. Do not link to an external style sheet nor use embedded styles, as this code is often stripped out by email clients, creating display problems.
  • Make sure all tags have supporting closing tags. The most common HTML errors come from not having a closing </FONT> tag or having open <TD> or <TR> tags in the HTML. While your HTML might render properly in a browser, these errors can cause problems with many email clients.
  • Use the HTML table attributes within the TABLE and TD tags.
  • For example: to set the table border=0, valign=top, align=left (or center, if that is the design), cellpadding=0, cellspacing=0, and so on. This primarily helps older email readers to display the html email in a minimally-acceptable way.
  • Put general font style information in the table TD or DIV or P tags closest to the content. This can mean repetitive style declarations in multiple TD cells or DIV’s or P tag. Put font style definitions into heading (e.g. H1, H2), P, or A tags only when necessary.
  • Use DIVs sparingly to float small boxes of content and links to the right or left inside a table TD cell. Google Mail appears to ignore the CSS Float property but Yahoo! and Hotmail work fine. Outlook 2007 ignores floats.
  • Sometimes it is better to code a more complex table layout than rely on the Float property. Since email is easy to clutter, ask that the design put the floated content in the narrow side column. Floats are the one part of an email design that might require the design be reworked.
  • Animated GIF files are acceptable, but use them sparingly.
  • Use of images maps is acceptable.
  • If there is a spacing issue with the columns in the email design, first tweak the cellpadding and cellspacing attributes of the HTML tables. If that does not work, use CSS margin and padding attributes. HTML spacing works better with older email software than spacing with CSS.
  • If an image is cut up and spread across several HTML table cells, test the email with many test accounts. Sometimes it looks great in Outlook but shifts by 1 pixel or more in Hotmail and other services. Also consider putting the image as a background image on a new html table that encases all the table rows and columns that would display parts of your background image. sometimes this achieves the same effect as cutting an image up but with less code and better results.

 

Note that Outlook 2007 does not display background images. Be sure to test your email code with your target email client software.

  • If you use background images, use the HTML table attribute background= instead of CSS. It works more consistently across email software except Outlook. Define appropriate bgcolor for the TD’s so that the color is displayed when the images are blocked.
  • Be sure all your images use the alt tags, height, and width parameters. This helps with Google Mail as well as when a reader has their images turned off. However, Outlook 2007 does not recognize the alt= parameter.
  • Use the target=”_blank” attribute for the HTML A tags so that people reading with a webmail service don’t have the requested page appear within their webmail interface.
  • Avoid a big image above the fold in the email. This is another classic spammer practice and can increase the likelihood an email will be tagged as spam.
  • Make sure your email content displays fine without images.

For example: if you use a background image to provide a background color with white font color over it, make sure the default background color for that part of the HTML table is dark, not white. Also be sure your alt=, height=, and width= parameters are set for images so they can help readers understand your content without images. Turning off your images will help you catch these issues and ensure the HTML email will display effectively if people see your email with images off.

  • Test your HTML code. Make sure your code conforms to World Wide Web Consortium (W3C) HTML standards
  • When sending a multi-part message, remember to create the text version. Most email clients send HTML as a multi-part alternative by default. Failing to include the text part of the message can cause some filters to treat your email as spam.

 

b. HTML Coding don’ts

  • HTML should not contain any JavaScript or any other script embedded in it. Some email clients do not support JavaScript, and others view it as a security risk.
  • Avoid using CSS for positioning. The support is very limited and will, more than likely, result in a broken layout for most of your recipients.
  • Avoid nested tables if possible. Some email clients, especially Lotus Notes and Netscape Messenger, might not render them correctly.
  • Do not use canvas background images. Most email clients do not display canvas background images. Background images for individual table cells are generally acceptable but might not appear in some clients such as Lotus Notes.
  • Do not apply attributes to the <BODY> tag. Attributes placed in the <BODY> tag are often flagged by spam filters and increase the likelihood of your message getting bulked or blocked.
  • With multiple embedded images, which also might cause the email to be blocked
  • Do not use EMBED tags.
  • Avoid embedding forms, such as surveys, into emails. Some email clients such as Hotmail might not pass the data through to the collection point. Instead, link to a Web form through which the recipient can complete the survey.

 

 

Share

Guide to a Better HTML Email Design – Part 2

  1. Email Layout:
  • Determining the layout design. Single column and two-column layouts work best for emails because they control the natural chaos that results when a lot of content is pushed into such a small space as email. Use a consistent HTML template.
  • Add in a header that contains logo, view online links if the email is not rendered properly on recipient email client, instructions to add sender email id to recipients address book (improved deliverability), etc
  • Body or the main section that contains the main content of the mailer.
  • Footer – should contain unsubscribe, contact us and forward to friend links and sender’s general terms and policies.

 

You can notice the email layout in the images below from Target, a top retailer mailer from USA. The header has all relevant detail of add to address book for inbox delivery, view online version, brand logo, etc.

Email Header

 

The body of the mailer has a consistent look with a single column view, with a clear offer and an actionable main link. You can also notice actionable links to other categories of products on the retailer website. You would also notice more offers, clearance sales, and other attractive discounts at the bottom of the main offer.

Email Body

 

You would notice multi-channel contact points for engagement on other digital channels and fine print of offer details, etc.
Email Body - Social Media Links

 

You would notice in the footer below, all relevant details on why you are receiving this email, to opt-out from further communications, company policies, etc.

Email Footer

Share

Guide to a Better HTML Email Design – Part 1

Email marketing is one of the most powerful and effective forms of marketing today. It is quick to deploy, offers immediate and highly-measurable results, enables advanced segmentation and personalization, and delivers a high return on investment.

However, achieving maximum results from your HTML email requires experience and expertise. Simple mistakes in the implementation of HTML emails can seriously affect delivery or usability and cripple your ROI.

To help marketers optimize results from their email marketing efforts, Kenscio has created this complete guide to create effective HTML email. These technical and design best practices give marketers the ability to improve their own email marketing campaigns. This guide is best shared amongst email marketers and the HTML coding staff that supports your email development efforts.

In this guide we will cover:

  1. Email Layout
  2. HTML coding do’s and don’ts
  3. Validate HTML content and avoid using scripts
  4. Using forms in HTML emails
  5. Font and font size
  6. Color
  7. Background colors
  8. Font colors
  9. Buttons, charts & other supporting images
  10. Style sheets
  11. Images
  12. Image alt tags
  13. Creating a Web version of your email newsletter
  14. Preview panes and blocked images
  15. Number of hyperlinks
  16. Phishing and HTML Links
  17. Message file size
  18. Length of email messages
  19. Personalization
  20. Individualization
  21. Navigation of email messages
  22. Search capability in email
  23. Email format/Versions
  24. Add to Address Book
  25. Forward-to-a-friend functionality
  26. Rich Media/Flash
  27. Video email
  28. Tips Email Deliverability to Inbox
  29. Five common flaws that you can avoid in Email Marketing Campaigns

Everyday we will cover the above topics in details. Keep visiting the Kenscio blog to learn in depth of each topic.

Your feedback and comments are most welcome!

Happy Reading!

@Kenscio Email Design Team

Copy rights to articles on Kenscio blog reserved. Any article from Kenscio blog can be reproduced by providing credits to Kenscio or providing a link back to Kenscio blog.

Share

Guidelines for Email Design – Create effective HTML Emails keeping current best practices in mind.

Guidelines for Email Design – Create effective HTML Emails keeping current best practices in mind.

Long gone are the early days of HTML email marketing, when we could just drop one big graphic in our files with an image map defining the different areas the graphic would link to. Over the years, as a range of email readers multiplied with varying support for graphics, and spammers abused the support of imagery, the rules of using graphics in HTML emails have changed considerably.

Read the entire article on Kenscio website at http://www.kenscio.com/resource-center/Guidelines_for_Email_Design.pdf

 

Share

Copyright © 2017 Kenscio Blog. All rights reserved.
iDream theme by Templates Next | Powered by WordPress