Email Design Best Practices
Use single column design
A single-column design is ideal for most emails—except for product-focused or newsletter formats—as it simplifies the layout for mobile devices. This streamlined approach allows readers to scan content more easily without the distraction of jumping between multiple columns.
The width of the email
A 600px width design is often recommended as a standard for emails. This width ensures that your content scales well on mobile devices without sacrificing image and text clarity. It provides ample space to accommodate your content effectively on both desktop and mobile screens.
Think mobile first
This approach has become increasingly common as mobile usage has surged in recent years. It prioritizes designing emails for optimal display on mobile devices while ensuring they also render beautifully on desktops. This method is especially effective for simple emails that convey direct and clear messages or information to your audience.
Steer clear of using emails that are entirely image-based.
If image blocking is enabled, your entire message could be lost. If you must include text within an image, be sure to use styled alt text to convey your message effectively. Additionally, image-based emails can be taxing on your recipients' data plans and pose challenges for visually impaired users. Whenever possible, opt for HTML text instead.
Email Development
Keep the following in mind when creating emails that use Liveclicker elements:
Use tables in your HTML.
Tables are by far the most reliable way to achieve a consistent layout.
Nested tables are totally safe, so feel free to nest away. You can also use colspan and rowspan, as long as you count your columns/rows carefully. Watch out for empty TDs, as some email clients don't handle these as you'd expect. Usually this issue can be fixed by adding an " " or non-breaking space character. You can control the size of this character using CSS so that it doesn't mess with your layout.
Know your design pattern
There are two popular approaches to coding an email layout.
The most popular approach is called responsive design. The basis of this technique is to start with a 100% width table (to which you can apply styles that will affect the whole email) and then floating (using align=”center”) a fixed-width table in the center of this wrapper. Using media queries, the width of this fixed-width can be adapted to various screen sizes.
The other popular approach is called hybrid fluid or “spongy” design. This technique uses container tables that are set to width=”100%” and constrained by a max-width style. On screens wider than the max-width, the table will reach its max and become no wider. On smaller screen, like tablets and phones, the table will naturally fill the available space. The “hybrid” part of this technique is that each table must be surrounded by a conditional table visible only to Outlook. The hybrid table has a fixed width, which solves the main problem with fluid design: Outlook ignores max-width statements. The main advantage of this technique is that it works pretty much everywhere, regardless of support for embedded styles or media queries.
A popular email templating framework that we recommend, if you're looking for a place to start, is 'Foundation' for email by Zurb: https://get.foundation/emails.html
Ensure code is well commented
Keeping code well commented will allow for ease of editing templates. This is true of any kind of coding, really, but shouldn’t be neglected for email. Because email development is full of hacks and fixes for client quirks, it can be invaluable to note why a particular style or element was added.
Encode special characters
If your email service provider (ESP) uses a different encoding method than the one you've selected for your email, special characters (such as ©) may appear incorrectly, often showing up as black squares or diamonds. This issue can also affect quotation marks and apostrophes. To prevent these problems, it's advisable to use a character encoder.
Keep email file size under 100Kb
There are several compelling reasons to keep your email size below this limit. First, a lighter email is more likely to pass through spam filters. Additionally, keeping your email under 100KB will prevent Gmail from “clipping” it.
To achieve this, consider eliminating redundant or unused styles, moving some content to a landing page, or minifying your code before sending. Be sure to test any changes thoroughly before the final send!
Avoid Javascript, Flash, forms and other complex CSS/HTML
Javascript and Flash are unsupported in email clients, so don't use them at all. Newer code, such as HTML5 and CSS3 have limited support, but are sometimes possible (and fun!) to use. These enhancements should be used with caution. As always, test thoroughly when using any advanced code!
Use cellpadding for spacing
Cellpadding provides reliable spacing across all email clients. If you need spacing only on one side of an image or container, you may want to use another spacing technique.
CSS
Use inline styles. Some Gmail clients, like Gmail Android App for Non-Gmail Accounts (GANGA), don’t support embedded styles. In addition to this, there are quite a few smaller email clients like Yandex and Telstra that still require inline styles.
To achieve this, you can code using classes and IDs and then make use of a CSS inliner. Email on Acid offers an inliner that you can use from any email test.
Avoid shorthand CSS when possible. If you see problems with a client interpreting your CSS, check to make sure you're not using a shorthand declaration. For example, "margin-top: 5px" may work where "margin: 5px 0 0 0;" does not. Especially avoid three-digit hex codes. Some clients don't react well to these, so you'll want to make sure you always use the full six-digit code.
Get used to !important
If you are a web developer, you may have been trained to avoid !important at all costs. When coding email, though, you'll find this declaration can be invaluable. You can use it to override styles added or modified by the email client (especially web clients). You'll also get a lot of use out of !important when writing media queries, where this declaration will let you override a default style with a mobile-specific one.
Get comfortable with media queries
Media queries are commonly used to create custom styles for different clients or screen sizes. The basic format of a media query for email is:
@media only screen and (max-device-width: 640px){ styles here }
This will cause the styles contained in the query to trigger only on screens of 640px or smaller. "Min-device-width" would do the opposite, triggering on screens of 640px or larger.
The most common uses of this technique are to control font sizes, image sizes, and to make some tables become 100% width so that they will fill a mobile screen. You can also use media queries to hide content that isn't necessary for mobile users. Just make sure that you use !important on styles within the media query, so that they will overwrite existing styles.
LiveForecast, LiveFeeds, LiveSlides, Live Images, LiveTimer, LiveCoupon & Webscrapes
These elements appear as images in the email, making them easy to adapt from desktop to mobile. Typically, we can set the image width to 100%. However, instead of editing the embed code directly, we assign a class that targets the image within its parent element.
If you have a LiveForecast for example, you should place it inside an element such a TD.
Then you can create a class named .rte_element and applied that class to the TD that contains the element.
In that class you set this properties: .rte_element{ width: 100% !important; height: auto !important; }
LiveVideo
This element is a little bit more complex, mainly with responsive design .
If you have a LiveVideo for example, and is width is set to 600px, you have to make it responsive to adjust the element in mobile environments.
Here’s the best example to demonstrate the use of mediaqueries with an Liveclicker Element:
If you see the embed code for a LiveVideo you’ll see that is contained within a div with the class name .dimensions_xxxxxx, where xxxxxx is an id for the element.
Then you could target that DIV with media queries, for each device you create a breakpoint in which you define the dimension of the element, here’s an example of a commonly used media queries for this:
/*Responsive styles for video*/
/*Android devices*/
@media only screen and (max-width: 480px){
.dimensions_01010101{
width: 272px !important;
height: 153px !important;
max-height: 153px !important;
}
}
/*iPhone 5 (320)*/
@media only screen and (min-width: 320px) and (max-width: 568px) and (-webkit-min-device-pixel-ratio: 2) {
.dimensions_01010101{
width: 272px !important;
height: 153px !important;
max-height: 153px !important;
}
}
/*iPhone 6 (375)*/
@media only screen and (min-width: 375px) and (max-width: 667px) and (-webkit-min-device-pixel-ratio: 2) {
.dimensions_01010101{
width: 322px !important;
height: 181px !important;
max-height: 181px !important;
}
}
/*iPhone 6+ (414)*/
@media only screen and (min-width: 414px) and (max-width: 736px) and (-webkit-min-device-pixel-ratio: 3) {
.dimensions_01010101{
width: 356px !important;
height: 200px !important;
max-height: 200px !important;
}
}
/////////////////////////////////////////////
LiveReveal & LivePoll
These two elements demand greater attention during the creation process due to their highly customizable designs. However, they require a more advanced understanding of CSS. The LiveclickerProfessional Services team is available to assist with coding these elements into your template. Please reach out to your Account Manager for further details.
Containers
The new embed codes improve the Liveclicker elements on mobile environments. Whatever the approach you'll use in your email design: Fluid, Responsive or Hybrid Email Design, our element automatically adjust its size by the percentage width of its parent container.
