TEMPLATE GUIDELINES OCTOBER 2013
CONTENTS Introduction... 4 Creative... 5 Template Dimensions & Image Headers... 5 Preview Pane & Positioning... 5 Graphics... 6 Optimization and File Size... 6 Background Images... 6 General Build Information... 8 File Format... 8 Template Layout... 8 Nested Tables... 8 Spacer Graphics... 9 What are Emails, Templates and Derived Templates?... 9 Multiple Content Area emails... 11 Fonts... 12 Cascading Style Sheets (CSS) and Inline Style Sheets (ISS)... 12 DIVS... 13 Images... 13 JavaScript & Forms... 18 Animation & Flash... 18 Email links... 19 Anchor Links... 20 Image maps... 20 Unsubscribe Links... 20 Personalisation... 21 Data Capture Points... 22 Delivery... 23 Preview Panes & Disabled Images... 23 Disabled Images... 24 Designing for Outlook 2007 / 2010... 26 Mobile Optimised / Responsive Emails... 28 What about email?... 29 So what are the pros and cons?... 31 2
How can I build a responsive template?... 32 Designing for mobile first... 32 Coding a mobile template... 34 How can I build a responsive email?... 41 UK Companies Act 2007 Legislation... 45 3
INTRODUCTION Communicator is a powerful and easy to use online email and mobile software platform specifically designed to enable effortless management of your digital communications. This document outlines the guidelines and recommendations that must be followed to ensure that your email templates are designed, built and imported to allow a seamless introduction to the Communicator platform. 4
CREATIVE TEMPLATE DIMENSIONS & IMAGE HEADERS It is recommended that the pixel width of important content within email templates should not exceed 600-650 pixels, this is due to the size and width constraints of most commonly used screen resolutions. This pattern has shifted majorly over the last few years with an extremely high percentage of computer users now using a screen resolution of 1024 x 768 or greater (98% - November 2012 Source: w3schools.com). Ideally, you want the end-user to be able to view the whole width of your email without having to scroll horizontally. Additionally, a number of popular Web mail clients utilise sidebars and navigation, which takes up valuable screen space and this must be taken into consideration. If an email is intended to be printed out then it is recommended that a maximum email width of 468 pixels should be used. This is the equivalent of 6.5 inches, leaving a 1inch margin either side of the email when printed on an A4 sheet. PREVIEW PANE & POSITIONING A large number of email client users view their emails using a preview pane layout. This, on average, halves the height of the on-screen area that an email can be viewed in. If your email design is to use a graphical header it is recommended that the height of the header image(s) does not exceed 250 pixels. It is also highly recommended that a company logo or easily identifiable brand mark is located within the first 250 pixels of the email. This re-assures the recipient that the email is from a source that they have signed up to and is not an unsolicited email. Example preview pane images are available in the delivery section of this document. The majority of people who view their emails using the preview pane will only see between 600-650 pixels across, by 250-300 pixels deep. Using HTML elements (background images, colours etc ) makes this area functional and attractive, even without images. Along with the 250 300 pixel header section and preview pane, you must consider where best to position such elements as navigation, corporate logo, personalization and imagery. 5
It is common for users to read the email from left to right and top to bottom, with this in mind, try to position the most important / interesting content at the top and preferably to the left. This could include latest news or the main article of the email. GRAPHICS OPTIMIZATION AND FILE SIZE Communicator Corp recommends that file size of all images are kept as small as possible without compromising the output quality. Applications such as Adobe Photoshop and Adobe Fireworks with their 'Save for Web' features are particularly useful for minimizing file size whilst keeping the quality of your graphics at a high standard. The use of JPGs, GIFs and PNGs can also aid in reducing the overall file size of the template. GIFs and PNGs can be used more frequently for less complex graphics such as navigation or background colours. JPGs can be used for full colour photos and graphics, with large graphics being sliced to reduce file download time. Graphics should be supplied in a.zip file along with the designed template and named appropriately i.e. 'Newsletter_November2008' and where possible aim to keep message file size less than 100 KB. Images should be in the root of the zip and not inside an individual folder to ensure images display correctly when uploaded into the platform. Although most desktop and Web-based email clients no longer question downloading large files, recipients using a 3G connection (or even dial-up connections) might not have the patience to let a big file load, especially one 100KB or larger. For more information about designing for mobile devices, please see our Responsive Design section. Try to keep emails less than 50 KB if possible, but larger emails up to 100 KB generally won t cause filtering or loading problems. The benefits to clients are quicker load times for recipients which is particularly important for very large dispatches. BACKGROUND IMAGES Background images are supported by Communicator and most email clients but to guarantee delivery and display, they must be coded properly. Outlook 2007 / 2010 does not 6
support background images (apart from when placed on the <body> tag). Please consult the Outlook 2007 / 2010 section of this document for more information. The length of the background and potential template must be taken into consideration - allowing sufficient room for extending content areas. As a guide add an extra 500 pixels to the length of the image for future emails. The background should be output at around 1-10px wide depending on the pattern as it may reduce the file size. More complex background patterns such as gradients or half tone patterns can be used and combined with using a number of 100% tables to create more impressive background graphics. But backgrounds must not detract from the main message and content of the email. Animation can also be used to create a more attention grabbing background or call to action however, care must be taken to ensure that these graphics repeat correctly as any errors will be more noticeable. The method for coding background images using 100% tables is explained fully in the build section of this guide. 7
GENERAL BUILD INFORMATION FILE FORMAT Communicator currently only allows the import of files named with the.html.htm file extension. We recommend users use the XHTML 1.0 Transitional doctype to minimise problems with certain email clients. Any email which validates to these standards have a higher chance of rendering properly. TEMPLATE LAYOUT When creating a new template ensure that all margins around the html are set to 0 and ensure the template is centred for delivery. This will improve the consistency of the email layout across different email clients, both web and desktop based. <body marginheight="0" marginwidth="0" topmargin="0" rightmargin="0" bottommargin="0" leftmargin="0" style="padding:0px; margin:0px;"> As tables are added ensure that the correct table structure is chosen before you begin and that all repeating main background images and header graphics and content areas have all been taken into consideration. As a rule of thumb single tables are a much more efficient way of building a template as it reduces the number of deliverability issues brought about by using numerous nested tables. NESTED TABLES Minimizing the use of nested tables in favour of separate tables can aid in the debugging of potential delivery issues as less code will have to be examined and tested to find the root of the issue. 8
SPACER GRAPHICS To ensure that all templates deliver across all email clients and maintain a consistent table layout we recommend you limit the use of transparent spacer graphics to keep formatting of table height and widths. We also recommend as best practice that any non breaking spaces ( ) are removed from table cells with small specified widths and heights. WHAT ARE EMAILS, TEMPLATES AND DERIVED TEMPLATES? EMAILS Emails are, what we would have called at one point, a locked email. These are mainly used for one off announcements where the content isn t intended to change i.e. specific offers etc Emails are designed with all of the content pre-built into them. This allows for greater creative control over what the end-user will see but removes the ability for greater personalisation within the email. Limited manageable functionality is allowed to personalise the email before being dispatched. This is explained later in this document. Umbro.com Email example: 9
TEMPLATES Templates are what we would have called at one point, an editable email. Templates are emails which can be used again and again by simply editing the content using the Communicator Message Editor. This is achieved by adding a custom HTML placeholder tag into the source code of the email template. This tag will be picked up by the Communicator application when the template is imported. The tag should be positioned in the exact location where content is to be entered. To do this, simply add the following line into your source code ensuring all spaces are included. As well as this, if possible, we recommend adding the width of the placeholder to the placeholder name for debugging purposes: {{PlaceholderName1_420}} An example of a template can be found below: Sport England Template (left) & Template with Populated Content (right) 10
DERIVED TEMPLATES New introductions to the Communicator platform are derived templates. Derived templates are essentially templates that are based off another template. For example, an original template may just have a header, a single placeholder and some legislation. Now, with the derived template feature you can use the same template to create as many different variants as you see fit. MULTIPLE CONTENT AREA EMAILS Multiple content area emails are based around a basic content-free template, which requires several different areas of the email to be used again and again. These areas can be edited by simply using the Communicator application. Multiple editable content areas are achieved through the inclusion of custom HTML placeholder tags in the source code of the email template. If entered in the correct format, these tags will be picked up by the Communicator application when the template is imported. The tags should be located in the exact position where content is to be entered and follow the format shown below. Please note that it is essential a different {{PlaceholderName}} is used for each editable area of the template: {{PlaceholderName2_420}} 11
FONTS The Communicator platform supports all standard web safe HTML fonts including: Arial, Comic Sans, Courier New, Edwardian Script ITC, Garamond, Geneva, Georgia, Gill Sans MT, MS Sans Serif, Segoe UI, Tahoma, Times New Roman, Trebuchet MS and Verdana. If a specific typeface which isn t web safe is to be used in an email, this can be achieved by creating the text as a graphic. Replacing text with graphics does have its downsides, for example if a user chooses not to download images then they will not be able to read any text that has been converted to graphics. Graphics, also, cannot be re-sized for partially sighted users or those who set their browser to show larger sized fonts It is also important to make sure you correctly encode all special characters, such as ( ), ( ), ( ) etc CASCADING STYLE SHEETS (CSS) AND INLINE STYLE SHEETS (ISS) It is strongly recommended that cascading style sheets are NOT used in any email templates. Most web-based email clients strip out any external style sheets from the email header resulting in the email being displayed incorrectly using the default browser fonts. In addition, Communicator s Message Editor only supports Inline and Embedded Style Sheets. Where possible, we recommend that Inline Style Sheets be used, applying the style attribute to relevant HTML tags to style specific elements. This method is not as versatile as using Embedded Style Sheets but it does mean that email formatting will display correctly in the majority of both Desktop and Web based email clients Inline Style Sheets should be placed in the <body> section of the template on the individual elements that you wish to style and not the <head> section of the html as most email clients can strip out any code from this section leaving your template to display without the correct formatting. An example of an appropriate Inline Style Sheet looks like the following: style="font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #333333; line-height: 18px;" Clients with a large number of recipients who use Orange (née Wanadoo) to receive their emails should be aware that, at last check, text is automatically outputted in black and therefore templates should be designed accordingly. 12
<font> tags can also be used to format text and links which can improve the consistency across many different email clients who may remove link formatting and colour (in particular Lotus Notes). This is explained further in the following email links section. DIVS We advise against building templates using DIV s as it can cause delivery issues ranging from misalignment, missing elements and finally, unformatted text. Instead, we recommend creating emails using individual tables formatted using ISS (Inline Style Sheets) as mentioned above. IMAGES Images can be used in HTML emails the same way as they are in web pages. However, the main difference applies to the way in which you reference the image location in your email HTML code. ABSOLUTE PATH Absolute Path uses the full location URL string to reference the images in your email if they are stored on another server to the Communicator application, for example: http://www.myserver.co.uk/emails/mytemplate/image_01.jpg Images must be stored on a web server and cannot be referenced locally, for example file:// will not work. Another important recommendation comes with the new release of Outlook.com. Some users may report spacing issues between images, to fix this add display:block; on to the inline style of the image, for example: <img src="stgys03.gif" width="35" height="25" style="display: block;"> LOCAL ZIP FILE OF IMAGES & TEMPLATE If you don t have access to your own server to store your images on then there is an alternative. When you create your email template if you store ALL of your images in the same location as your HTML file i.e. don t put the images into their own folder, then you can then create a ZIP 13
file containing all your images as well as your template, which you can upload to Communicator. The application will then automatically extract the images from the ZIP file and store your images on our server alongside your new template. This applies to all types of image;.gif,.png,.jpg,.jpeg etc... 14
IMAGES AS WEB LINKS It is possible for images in HTML emails to have links applied to them, which can link externally to another webpage. This is done simply by using the standard <A> HTML tag. Additionally Communicator will automatically convert these links into trackable links. These links can then be tracked every time a user clicks on them, the results of which can be seen in the Communicator Response Engine. A further improvement to the Communicator application is the ability to track image map links. 100% TABLES AND BACKGROUND IMAGES To ensure that background images appear and deliver correctly across multiple email clients it is important to code them correctly. Creating a 100% table, then placing remaining tables inside is a tried and tested technique. Please note that Outlook 2007 / 2010 does not support background images and if used they will not display. However, background images can be used on the <BODY> tag when designing for Outlook 2007 / 2010 but be aware that Outlook 2007 / 2010 adds extra padding to the top of the email which can cause issues. CODING THE TEMPLATE BACKGROUND <div style="background:#ededed;"> <body leftmargin="0" topmargin="0" marginwidth="0" marginheight="0" background="background.gif" bgcolor="#ededed" style="padding:0px; margin:0px;"> <table width="100%" height="100%" cellpadding="0" cellspacing="0" border="0"> <tr> <td valign="top" background="background.gif"> </td> </tr> </table> </body> </div> When checking the html preview (after import), first ensure that the background image is visible and then look to see that the background image repeats correctly with no overlaps or missing pixels, and also that the background image is sufficiently long / wide enough to cope with the addition of content or imagery. 15
Background images can also be applied to individual table cells as follows: <td width="165" height="120" valign="top" background="background.jpg" style="fontfamily: Arial, Helvetica, sans-serif; font-size: 14px; color: #333333;">Example Body Copy</td> CORRECT USE OF BACKGROUND IMAGES: INCORRECT USE OF BACKGROUND IMAGES: 16
ALT TAGS As all users may not choose to download images automatically, ALT tags should be added to all relevant graphics so that the user can still get understand what the image is referring to - even if the option not to display graphics has been selected. Alt tags describes an image or an action when the image doesn't display because of slow loading time or default image blocking. Example ALT tag code looks as follows: <img alt="communicator Corp Logo" src="http://www.communicatorcorp.com/image/01.gif" border="0"> An example use of an alt tag would be entering the link name of a navigation graphic, or labeling an image in the template. If you were to create an all graphic template which includes a lot of body text it may be necessary to include all text from the template in alt tags to allow users to read the information again without needing to download images. Recipients using dial up or other slow connections may not see images for a few or several seconds. Displaying alt tag text can at least convey a sense of what is to come, while the recipient waits for the image to load. Many email clients such as AOL and Gmail have images disabled by default, or display a warning message asking the user if they'd like view the images. Please note that Outlook 2007 / 2010 does not support ALT tags and instead removes them completely or if they are used on a link then replaces them with the designated link URL. 17
JAVASCRIPT & FORMS Nearly all Web mail clients and some Desktop clients remove all JavaScript contained in HTML emails, rendering any functionality in the email requiring JavaScript useless. It is therefore recommended that JavaScript is NOT used in HTML email templates for any essential functionality within the email. JavaScript has been used in the past in emails as a method for spreading malicious code to an end-user s computer that can destroy data and cause the computer to stop functioning correctly; therefore email clients have cracked down on the use of JavaScript to help prevent this happening. In addition Perl, VBScript, ActiveX and IFrames should all be avoided as many email clients will ignore or strip out the respective code which will subsequently bring about delivery issues. If a form element is needed we can offer alternatives such as a call to action with a following popup window containing a form, or linking to an html page with the relevant form as many email clients won t render forms correctly or pass the data from an email form to your Web site. Communicator can also offer to create a Data Capture Point whereby the form would be created inside the application and all information collected is stored and accessible through the application. Please note that Outlook 2007 / 2010 does not support JavaScript or Forms, please see the Outlook 2007 / 2010 section of this document for more. ANIMATION & FLASH Macromedia Flash can be an effective tool to use for email marketing but as of yet only Mac Mail supports Macromedia Flash fully, so we advise against its use where possible. Alternatives can include: Incorporating animated gifs which are supported fully by all email clients except Outlook 2007 / 2010. The use of a call to action link in the design which will then open a subsequent scaled popup window which can include relevant flash animation. Linking to a web based flash animation which is currently hosted on a webpage. Please note that Outlook 2007 / 2010 does not support any animation or flash elements, please see the Outlook 2007 / 2010 section of this document for more information. 18
EMAIL LINKS When assigning formatting to links whether it is the colour, size or underline deliverability must be again taken into consideration as email clients all vary on how they can handle and display links. For example Windows Live Mail ignores the <BODY> section of the html which can revert all link colour and formatting to hyperlink blue. Further information on other email clients is available at the end of this document. To overcome potential link issues ensure that all links are coded as follows: <a href="http://www.communicatorcorp.com/" style="font-family: Arial, Helvetica, sans-serif; font-size: 12px; color: #FFFFFF; text-decoration: none;" target="_blank"><font color="#ffffff">click here</font></a> Always set links to open in a new window as if links are set to open in the parent window this can cause the user to navigate away from the template without reading further items. CORRECT LINK CODE APPLIED: MISSING LINK CODE: 19
ANCHOR LINKS For longer templates, anchor links are a great way to allow users to 'jump' using the main navigation to the area of interest they have just clicked. Anchor links themselves are compatible with the vast majority of email clients but not AOL, so bear this in mind if a high percentage of your list includes AOL addresses. Code is applied to the main navigation as follows: <td> <a href="#tab4"> <font color="#ffffff"><strong>example Link Name</strong></font> </a> </td> Then an additional line of code is added to the title of the area you would like the navigation to jump to: <td> <font color="#ffffff"> <strong> <a name="tab4"></a>example Link Name </strong> </font> </td> IMAGE MAPS A further improvement to the Communicator application is the ability to track image map links, something that was not possible before. UNSUBSCRIBE LINKS 20
Communicator operates a strict policy allowing users the ability to Opt-Out (remove) themselves from the emails they are sent from the Communicator application. Unless users form part of an internal mailing list e.g. staff, ALL emails MUST carry a visible, easily recognizable and working Unsubscribe link. Additionally, the term Unsubscribe MUST be used in the unsubscribe link, this link should be added to the href property of the <A>: e.g. <a href="unsubscribe" target="_blank" style="font-family: Arial, Helvetica, sansserif; font-size: 11px; color: #a8a8a8; text-decoration: none;"><font color="# a8a8a8">click here to unsubscribe</font></a> Example text for how an unsubscribe link should be presented: You are receiving this email because you have subscribed to be on this list. If you would like to be removed from this list, please click here and you will be removed immediately. Thank You. PERSONALISATION Personalisation helps to increase the appeal of an email to the recipient by making them feel that message has been written specifically to them. Additionally it helps stop valid emails being regarded as spam by the filters of the email client. Personalisation can be built into your email templates. Personalisation is based on the field names of the information contained within your Communicator tables. To include personalised data into your email simply add the following inside your placeholder: [[TableName.FieldName??Fallback]] Where TableName is the table name within the Communicator platform, FieldName is the name of the field within that table and Fallback is the fall back text should no personalisation be available. For example if you wanted to personalise an email to a recipient s first name, your template code may look something like: [[EmailData.Forename??Sir / Madam]], Please note that fields must be referenced with the exact name contained in the table and personalisation is case sensitive. When the email campaign is dispatched, all First Name 21
information relating to the specific recipient will be automatically populated into each individual email and then sent. DATA CAPTURE POINTS Data Capture Point's or DCP can be created at any size but as a popup the size must be taken into consideration for those on lower resolution monitors such as 800 x 600 and again for the content of the DCP. When building the DCP it should include a placeholder to include the relevant content which will normally entered inside the application. Example DCP: 22
DELIVERY PREVIEW PANES & DISABLED IMAGES As mentioned previously in the design section of this document - individual email client's different preview pane sizes should be taken into consideration, the preview pane is the amount of the template that is visible when the user clicks to open the email. Preview panes can vary quite significantly depending on the users monitor resolution, the browser they are using and also if the user chooses to download images automatically or not. Generally preview panes leave between 600 650 pixels of viewing area depending on the size of other tabs, content areas and monitor resolution. More than 9 of 10 email users have access to a preview pane, and 7 of 10 say they frequently or always use it. More than half of those who read email in a business-oriented client such as Outlook or Lotus Notes do not see images in email because their clients block them. However, 3 of 10 readers have manually changed their email settings to allow downloading of images and graphics. The heights of few selected preview panes can be found below: Gmail Preview Pane: Outlook.com Preview Pane: Outlook 2010 Preview Pane: 23
Examples of horizontal & vertical preview panes (Outlook 2010): DISABLED IMAGES If a user chooses not to download images for emails then this can dramatically affect how the email will appear visually as well as affecting how much information the user can take from the email **it its base form. For these reasons we try to ensure that from the initial design the email will have relevance to the user by making good use of logo positioning, template title, imagery near the top of the email as well as 'subject' and 'from' address lines. To minimize the delivery issues caused by users choosing not to display images as default follow the below points: Where possible try not to use images for important content such as headlines, links and any calls to action. Use alt text for all images Always add the height, width and style= display:block; to images to avoid any graphics throwing tables out of sync 24
Umbro.com - Disabled imagery: Umbro.com - Enabled imagery: 25
DESIGNING FOR OUTLOOK 2007 / 2010 With the introduction of the latest versions of Outlook and looking at their capabilities and how they will affect email design and deliverability, we have extensively tested templates using 2007 / 2010 having included the most commonly used elements in email design including Cascading Style Sheets (CSS), Inline Style Sheets (ISS), imagery, backgrounds, flash, varying text formatting and styles. The following information will ensure your emails will deliver as intended to users with Outlook 2007 / 2010 as well as continuing to deliverability rates to all other email clients. During the Outlook 2007 / 2010 testing period we discovered that 2007 & 2010 do support Cascading Style Sheets (CSS) but please be aware that most other clients will strip out or ignore CSS tags even if they are embedded in the template. In addition 2007 / 2010 do not support the use of padding from the top of a table; this will result in what appears to be a blank table above where the padding-top code is used which will be free from any formatting which may have been added such as a border element, etc. To get around this delivery issue we advise that all top padding be replaced with a blank table with a designated height to replace the need for padding. Email and web addresses that have not had a link applied are automatically given a blue hyperlink when viewed in 2007 / 2010 even if <font> tags are added to maintain colour. Adding a link to these text URL s will ensure that these blue hyperlinks will not disrupt the design of your emails upon delivery. Below is a list of the key points to recognise when designing emails for Outlook 2007 / 2010: No support for background images (unless placed on the <body> tag) and no support for background images in nested tables The main update to Outlook 2007 / 2010 is its lack of support for background images within tables and nested tables. This does not mean you must strip out all background images as they will still be recognised by other email clients, instead we recommend that you compensate for users with 2007 by using additional background colours as a fallback. Background images can still be used on the <body> tag of the email. 26
No support for forms An alternative to using embedded forms is to offer the option for a link or graphical link to external web-based form or to speak to one of out Account Managers about incorporating a Data Capture Point please see DCP section of this document for more information. No support for Flash, or other plugins With flash only being supported by one of the more popular email clients (Mac Mail), we have recommended in the past that clients try and refrain where possible when it comes to Flash animation. No support for CSS floats No support for replacing bullets with images in unordered lists No support for CSS positioning No support for animated GIFs Gifs appear as a static image using the initial frame. We advise against use where possible as the ALT tag of the GIF will also not show leaving the user with a blank graphic in some cases. No support for JavaScript or rollover states Image and links will display the initial image of the rollover. No support for ALT tags Alt tag information does not display leaving clients who do not chose to download images automatically potentially with a blank email. A full list of Outlook 2007 / 2010's rendering capabilities is available at: http://msdn2.microsoft.com/en-us/library/aa338201.aspx#word2007mailhtmlandcss_full 27
MOBILE OPTIMISED / RESPONSIVE EMAILS Before getting started, this responsive design guide has been created as a starting point for our clients to optimise their emails for mobile devices while using the Communicator platform. As we're sure you are aware, mobile devices and their capabilities are forever changing and likewise so are the techniques used to make sure that emails render correctly on the range of available email clients. If you have any suggestions as to how we can improve this guide, or you notice any changes in functionality which requires the guide updating, please get in touch. It's said by 2014 mobile internet usage is likely to overtake desktop internet usage and even now it's believed that currently 1 in 5 emails are now being read on a mobile device. With this in mind, can we really ignore designing for mobile devices any longer? The answer is of course a resounding, no. For a while now web designers have dealt with designing for mobile by having effectively 2 different sites i.e. a maximum resolution one (www.communicatorcorp.com) and a minimum resolution one (mobile.communicatorcorp.com). Depending upon which device the site was viewed on, it would automatically chose which version of the site you ended up on. However, for Marketing departments this then becomes a logistical challenge; 2 different layouts, 2 different ways of working, and possibly even 2 different types of content i.e. one long, one short. Not only that but sharing content between devices proves difficult. For example, say a customer was viewing an interesting blog post on their mobile (or even vice-versa) and wanted to share it with the rest of their office - it's highly likely that the rest of their office would then be locked into viewing it on that context. A pretty poor user experience. Responsive Design is a current trend which aims to react to user s actions and detect the device which the site is currently being viewed on, in order to provide the best user experience possible in terms of navigability and readability. In short - depending on what type of device (and resolution) the user views the initial website on, means what type of experience they receive. Example below: 28
WHAT ABOUT EMAIL? With the variety of email clients on the market, support of various techniques is a challenge on mobile devices. This is something we stress to all who wish to adopt a responsive email design. iphone, ipad and Android devices all use the WebKit rendering engine therefore it comes as no surprise that the support for @media queries between the two on their in-built mail clients is pretty good. There are some anomalies between the two however; and one comes in the shape of Gmail's own app that you can download on both iphone and Android. Since the Gmail Web Client doesn't support embedded CSS (and @media queries is a variant of that), it's no surprise that media queries are not supported in any of the Gmail mobile apps either. Blackberry are slowly but surely moving towards using the WebKit rendering engine, but aren't quite there just yet, therefore support should improve as newer devices appear on the market. As it stands, only operating system 6 and greater have partial support for @media queries. Windows 7 handsets are different in the fact that the browser's base functionality is built upon a hybrid of Internet Explorer 6 & 7, which do not support @media queries at all. This means that users of Windows 7 handsets will have to cope with the basic email. A full list of @media query support is as follows: 29
@MEDIA QUERY SUPPORT Android 2.1 Eclair (Native Client) NO Windows Mobile 6.1 NO Android 2.2 Froyo (Native Client) YES Windows Phone 7 NO Android 2.3 Gingerbread (Native Client) YES Windows Phone 7.5 (Mango) YES Android 4.0 Ice Creme Sandwich (Native Client) YES Windows Phone 8 YES Android 4.1 Jelly Bean (Native Client) YES BlackBerry OS 5 NO Android Outlook Exchange (3rd Party App) NO BlackBerry OS 6 YES Gmail App (All Platforms) NO Palm Web OS 4.5 YES iphone YES Kindle Fire (Native Client) YES ipad YES Kindle Fire HD (Native Client) YES ipod Touch YES The other anomaly we ve found during testing is mixing the native Android email client, and email addresses which use a Microsoft Exchange Server to deliver those emails (usually Exchange 2010). For some unknown reason, the required code to enable a responsive design is stripped out by the server and users are faced with the standard email instead. 30
SO WHAT ARE THE PROS AND CONS? Firstly, the most important plus point is that responsive design provides a massively better user experience for the end user. Anything that's styled for the device its being read on is always likely to vastly improve the user experience and therefore hopefully improve sales, subscriptions etc. It also means there is no need for a 'separate' mobile email template. Having a separate' mobile email template is something we would always class as a poor man s' responsive design. By all means capture user preferences as to whether they want to receive emails on their mobile device, but sending a mobile only' email means that there is always going to be that one time when the user does end up viewing an email on their computer and although viewing a 300 pixel wide email on your computer isn't the end of the world, responsive email design would solve all of that. On the flip side, there needs to be an understanding that template/email layouts need to be much simpler. Single / two column layouts render best on mobile devices. They're easier to read, and if they do somehow not fully render as expected on the mobile devices which don t fully support various techniques, they degrade so much more gracefully. It should be understood that if there is the thought that current templates/emails can just be switched to be made 'mobile-friendly' then I'm afraid that this isn t the case. Responsive design means a change of approach; from design to dispatch. Finally, adding mobile-specific styles shouldn't be confused with providing a slimmer or fasterloading version of your content. Mobile-specific styles just make the content easier to read on the device. In effect, the user will still effectively be downloading all of the content. 31
HOW CAN I BUILD A RESPONSIVE TEMPLATE? It is important to re-iterate something before we begin. The techniques used and discussed within the following guide aren t universally supported by all mobile email clients. Not unlike web / desktop based email clients, there are no mobile email standards within the industry. Although we always try to ensure the advice we provide caters for the masses, there will unfortunately always be the odd occasion where the code will not render as expected. DESIGNING FOR MOBILE FIRST More often than not, the mobile experience for a website / application is often designed after the desktop version an afterthought if you will. To build a true responsive email it s imperative that this approach is reversed and the mobile version is designed first. Designing for the mobile environment comes with a natural set of constraints the most obvious one is screen space. Losing in the region of 80% of the screen space you are used to when designing for web / desktop email clients forces you to focus on making sure that what stays on the screen is the most important set of features/information for your customers and your business. Never has it been more important to understand the main goal of an email e.g. SquareSpace 32
Not only have SquareSpace utilised a single column approach which lends itself nicely to a responsive email, it has also forced them to think hard about what their main call to action is, which in this case is obviously trying to get customers to purchase a bespoke domain name. Research has shown that during a typical day: 84 per cent of people will use their smartphone at home, 80 per cent during miscellaneous times during the day, 74 per cent waiting in queues, and 64 per cent at work. This comes mostly in short bursts so not only will designing for mobile first mean a better user experience overall, but it will also give you the chance of slimming down the file size of your email enabling people to access and read your emails quickly on the go using a mobile connection e.g. 3G. A good example of using the mobile first mentality is below. The email on the left (90% images and even longer than the screenshot suggests) wouldn t work as a responsive email. Not only because of the slow loading nature of the large images when viewed on a mobile, but structure wise it isn t built using a single / two column layout. The layout on the right however has been generally built with mobile in mind. It uses a mixture of 1 and 2 column layouts, is short and punctual, has a nice blend of text and images and more importantly will load relatively quickly using a mobile connection. 33
CODING A MOBILE TEMPLATE In general a lot of the best practice guidelines we recommend in our regular template guidelines, run true when building a responsive template. For example, where possible we always recommend using Inline Style Sheets (ISS) over its External and Embedded CSS brothers and sisters. The reason for this is that most web-based email client s strip out any External and Embedded style sheets from the email header resulting in the final email being displayed incorrectly using the default browser fonts. ISS, however, performs much better. One key difference is that building a responsive template/email for mobile devices requires the use of CSS3 media queries (a variation of Embedded CSS which we normally recommend avoiding). For example: @media only screen and (max-device-width: 480px) { table[class="hide"] { display: none!important; } img[id="logo"] { width: 50px!important; height: 25px!important; } } 34
Breaking the above down, all the code is saying is that when a device with a maximum resolution of 480 pixels or below views this page (for example an iphone), then apply the following styles. This figure can of course be adapted depending on the device you re targeting, for example; 768px for ipad (Portrait and Landscape). However, given that we recommend 650 pixels as a maximum width for all emails, this may possibly be redundant. Then within the email itself all we have to do is reference the relevant style at the right time e.g. <img src="logo.jpg" width="100" height="50" id="logo" style="display: block;" /> When the email is viewed on a mobile device, the email (in this case the logo image (logo.jpg)) adapts based on these rules but it leaves any device using a bigger resolution e.g. PC s, untouched. Using the above as a guide, the media query can then be adapted based on a number of potential mobile resolutions should the need be there, but as a guide; 480px is a good enough starting point to cover most mobile devices. As well as the above, it s important to add in the following to the <head> of your templates: <meta name="viewport" content="width=device-width, initial-scale=1, maximumscale=1"> Adding this ensures a responsive experience from email, through to Web View. One thing you may have noticed which is different from your standard Embedded CSS, is the introduction of square brackets around class names. These are called Attribute Selectors and the main point of these are to fix a well-known problem in Yahoo! Mail. For some unknown reason, Yahoo! Mail gives precedence to the @media query, which means that even if you view the email on a PC, you will still be faced with the mobile optimised version of the email (Fig 1 below). Using the Attribute Selectors ensures the correct version is not only served up to Yahoo! Mail recipients but it leaves emails viewed in other email clients untouched. 35
(Fig 1) UPDATE 18 TH APRIL 2013: It appears as though Yahoo! Mail has now fixed the above issue in a recent release, so no longer are Attribute Selectors required however if you still choose to then please feel free. BUILDING A SINGLE COLUMN TEMPLATE Single column templates are by far the easier option when it comes to designing a responsive template i.e. they re easier to code, and if things don t render as you d expect, they degrade much more gracefully. Using the above media query as a guide we can do the following: @media only screen and (max-device-width: 480px) { table[class=table-shrink] { width: 325px!important; } } Then, similarly to the logo example detailed above, we can then reference that class on the relevant table: <table width="650" border="0" align="center" cellspacing="0" cellpadding="0" class="table-shrink"> 36
<tr> <td bgcolor="#ffffff" valign="top">{{mainbody_650_325}}</td> </tr> </table> When the email is viewed on a mobile device which matches the above requirements, the body of the email shrinks down to 325px wide. BUILDING A TWO COLUMN TEMPLATE Building a two column template, although slightly harder, can still be done without having to resort to adding too much code to the main @media query or the template itself. In theory, the idea is that the second column will wrap underneath the first column when viewed on a mobile device: To achieve the desired result when building a website, CSS properties such as float: left; would naturally be used but as we re building an email older HTML attributes such as align= left are an adequate replacement. In the following example we will take a 650 pixel wide table with one table cell, and inside that table cell we insert 2 nested tables; one with the width of 325 pixels which is aligned left, and another similar table which is also 325 pixels wide but this time with no align property. 37
The outcome when viewed on mobile will cause the table with no align property to wrap underneath its partner. The code to achieve this looks as follows; firstly the @media query: @media only screen and (max-device-width: 480px) { table[class=table-shrink] { width: 325px!important; } } Secondly, the HTML itself: <table width="650" border="0" cellpadding="0" cellspacing="0" align="center" class="table-shrink"> <tr> <td bgcolor="#ffffff"> <table width="325" border="0" cellspacing="0" cellpadding="0" align="left"> <tr> <td valign="top">{{column1_325}}</td> </tr> </table> <table width="325" border="0" cellspacing="0" cellpadding="0"> <tr> <td valign="top">{{column2_325}}</td> </tr> </table> </td> </tr> </table> 38
BUILDING A FLUID TEMPLATE Unlike the two examples above which are fixed at 325px wide, it is also possible to create a fluid template. The fluid template, which no matter what resolution device a user views the email on, shrinks and stretches accordingly. To do this, instead of using specified widths, we instead use percentages e.g. @media only screen and (max-device-width: 480px) { table[class=table-shrink] { width: 100%!important; } } This slightly amended @media query will mean that when a device with a maximum resolution of 480 pixels or below views this email, no matter what resolution the device has, the table will change to 100%. For single column templates this is a relatively small change; however for two columns it becomes slightly harder and requires some small amends to the template s HTML: <table width="650" border="0" cellpadding="0" cellspacing="0" align="center" class="table-shrink"> <tr> <td bgcolor="#ffffff"> <table width="50%" border="0" cellspacing="0" cellpadding="0" align="left"> <tr> <td valign="top">{{column1_325}}</td> </tr> </table> <table width="50%" border="0" cellspacing="0" cellpadding="0"> <tr> <td valign="top">{{column2_325}}</td> </tr> </table> </td> </tr> </table> As you can tell from the above HTML, we have amended the two side-by-side tables to percentages (50%) rather than fixed widths. Very little changes when viewed on either desktop or webmail client, but by changing it to a percentage means a fluid layout on mobile devices. 39
N.B. Because of the fluid nature of these templates the chances of something not rendering as expected is much greater, so please test thoroughly on multiple devices before dispatching. Our final bit of advice is that although fluid templates may seem the way forward, it s important that a wider view of your target audience is taken. For example, when using our upcoming improved Communicator reports, you may see as an example that 90% of your recipients view your emails on one type of mobile device e.g. Apple iphone. If so, it s probably not worth spending too much time in designing a fluid template for the other 10% of recipients who view their emails on an uncommon device. 40
HOW CAN I BUILD A RESPONSIVE EMAIL? From the above sections, you have seen how to design and build a responsive template. The following section shows how to build an email from that new responsive template within the Communicator platform. Importing your template into the platform is exactly the same as importing any other template. Simply store all of your template images in the same location as your HTML file (i.e. don t put the images into their own sub-folder), then create a ZIP file containing all of your images as well as your template HTML, then upload it into Communicator. N.B. Communicator is designed to be a feature rich email platform with no restrictions to our clients when it comes to building emails. Such features include intuitive WYSIWG email editor, data driven content, image map editor, advanced personalisation etc. However, when it comes to building a responsive email such features may or may not work as expected across wider mobile devices, so the key when building a responsive email is to keep it simple and test thoroughly. The simpler the template / email, the more chance there is of it rendering perfectly across desktop, web and mobile clients alike. CREATING FLUID IMAGES IN A RESPONSIVE EMAIL Mobile devices can come in all shapes and sizes so it s important that no matter what resolution mobile the user has, that images and text make use of the screen size as much as possible. One solution is to create fluid images; which similar to a fluid template, shrink and stretch depending on device. To do so, an added @media query can be used in the main template which then can be referenced when building the email. The added @media query looks like so: @media only screen and (max-device-width: 480px) { img[class=responsive-image] { width: 100%!important; max-width: 100%!important; height: auto!important; } } 41
To reference this class when building your email within Communicator, follow the steps below: 1. In the Template Manager, select your template; press the Actions button next to it, then press Create Email. 2. Select your required mailing list and give your email a name. 3. Double-Click on the required placeholder to enter the WYSIWG editor. 4. Insert an image via the Image Manager (Fig 2). 5. Swap to the HTML view using the button at the bottom of the editor and then include the class appropriately on the image e.g. <img class="responsive-image"> (Fig 2). (Fig 2) N.B. Because of the max-width: 100% property on the @media query, it s important that any image you insert into the relevant placeholder has been saved at the appropriate fixed dimensions. For example, if the width of the placeholder is 600 pixels when viewed on desktop and webmail clients, it s important that the image you use is saved out at exactly 600 pixels. Inserting an image which is too big for the placeholder to begin with and scaling it down using the platform rarely produces good results. HIDING / SHOWING CONTENT Although very much a contentious issue amongst Web / Email Designers, some may find it necessary to pick and choose which content to display to recipients when viewing the email 42
on mobile devices. The argument is that most mobile users do everything desktop users will do so all content should remain the same only presented in a usable way. This is very much a judgement call, however should you choose to remove certain content on mobile devices e.g. limiting the amount of stories; this is how you do it: @media only screen and (max-device-width: 480px) { td[class=table-cell-hide] { display: none!important; } } The above @media query is saying when a device with a maximum resolution of 480 pixels or below views this page, then set the content (in this case a table cell) not to display. To reference this class in the Communicator platform, we follow a similar process to that of when we want to insert a fluid image: 1. Presuming, you have already created an email from your responsive template, double-click on the required placeholder to enter the WYSIWG editor. 2. Insert a table via the Table Wizard (Fig 3). 3. Swap to the HTML view using the button at the bottom of the editor and then include the class appropriately on the table cell e.g. <td class="table-cell-hide"> (Fig 3). (Fig 3) The techniques used and discussed within this section are to be used as a starting point to your responsive email design adventures. By altering and enhancing the above code, as well as using the core functionality found within the Communicator platform, you can achieve your desired outcome on mobile devices with relatively little effort. 43
If you d like to know more about Responsive Email Design, or would like the Communicator Corp Design team to design and build a bespoke responsive template using the above best practice know-how and expertise, please contact your Account Manager for more information. 44
UK COMPANIES ACT 2007 LEGISLATION As from 1st January 2007 all emails and websites must supply the following information included in footers/about us company information pages to comply with the UK Companies Act law. Company name (including any sub divisional names) Registered company postal address (not a PO box address) Valid working email address (e.g. customer support) Company registration number and place of registration The following information must be included on your website: Trade associations i.e. for travel companies ATOL ABTA reg. numbers should be clearly displayed If VAT registered VAT reg. number should be displayed Clarity of any pricing information contained in an email or webpage, clear definition of Inc/Exl of VAT price, clear delivery options and costs For more information the full Companies Act 2006 is available at: http://www.opsi.gov.uk/acts/acts2006/ukpga_20060046_en.pdf 45