When it comes to email design and coding – especially when coming from the website realm, it seems relatively simple. If one knows their way around coding websites, then they’re automatically good to for email right? Not necessarily. While email design has gained popularity (there’s blogs, conferences and online communities dedicated to the craft now!), there are still quite a few misconceptions about email design.
We work with a lot of in-house and contracted graphic designers from our ever (and fast) growing list of clients and we tend to hear the same type of comments, questions and concerns.
Let’s dig into the 10 common misconceptions, get some insight and learn some workarounds!
- “I built our website so I can take a go at our email template.”
That’s great! I’m personally always one for getting down and dirty in the code, but be aware that what you did for your website won’t just neatly transfer over to the email. Emails are table based and if you learned HTML by making websites within the last 10 years or so, you more than likely use <div> tags and CSS to manipulate the positioning of those divs – we see this technique quite a bit during initial code evaluations. Email does not play well with <div> tags and CSS positioning like absolute, fixed, margin, top, bottom, z-index. Say hello to our little friend <table> and his buddies <tr> and <td>! Need some tips and tricks for working with tables? - “When I slice my image in Photoshop, it provides table based HTML; I’ll just use that.”
I know, I know – we just said email uses table based code, so why not use the table based code that Photoshop provides? Because Photoshop doesn’t care about email best practices – the code that is created is based on how you slice and its concern is to make sure the code reflects the exact way things were sliced. This means that if you don’t slice your images evenly, based on a grid and with consideration of text and how email clients can behave, you’ll have code that looks good in browsers but will be broken in your inbox – if it even gets there! Also, Photoshop adds a few things to its code that just isn’t best practice for email.
Tip for slicing: Slice horizontally, not vertically! - “I’ll just send this whole image as the email.”
What’s worse than messy code based on sloppy image slicing? Just plopping the whole image in an email and sending it off as a campaign. Email takes into consideration what’s called text to image ratio and it should be balanced 1:1. What that means is if you have a large promo image, make sure to have a paragraph or so of text to prevent the email from being treated as image heavy. - “GIFs are cool! Let’s include one of our TV commercial in our next email.”
GIFs are definitely the way to go in email, with 1 out of 2 marketers using them in their email campaigns – but there are some guidelines and limits. GIFs should grab attention and complement the email’s content, but not act like a replacement for video in email. Also, file size is a big factor when it comes to how much animation should happen, the longer and more detailed the animation, the bigger the size – and you’ll risk looking quality of the image as you try to optimize and compress the image. A best practice would be to keep the animation to just one area or object in the image and make the animation itself the GIF while the images around it are static .jpgs (all properly sliced and placed in a table, of course!). Keep in mind that Outlook doesn’t support GIFs and will only show the first frame of your image. These guys were really creative with their use of GIFs in an email campaign. - “Let’s add our website survey form to the email.”
You’d think that since form tags are basic HTML, they should work just fine in email right? Yes and no – some email clients will remove the form fields completely, while some will display them but you won’t be able to type in them while some even let you click the submit button, but nothing happens or actually submits! While it would be cool to just include the form and collect info directly from subscribers, the best method is still to link to a landing page with your survey – at least this way you’ll get some click through data! - “Our website font is SoAndSo*, available from Google fonts. Please use that font for our headings in our email template.”
I really wish this were a reality – the ability to use Google fonts inside our email templates and campaigns. This would eliminate hoping that a subscriber has a particular font installed (while using a font stack for backup fonts) or just using the handful of web-safe fonts available. So far, the only email client that supports this is the native Mail program that comes with Mac products. So we’re still crossing our fingers when we add non web-safe fonts into a stack – but it’s a total safe method and workaround. If the subscriber doesn’t have the font we hope they do, there’s a web-safe font ready to take its place!
*SoAndSo is a font name we totally made up! - “I added some interactivity in my email that I use in my website but it’s not working”
This is probably my most hated thing about email coding – not being able to use jQuery, JavaScript or any programming language for fun sliders, hover effects or animations. Imagine browsing an image gallery using AJAX right inside your inbox, how cool would that be? We’ve sometimes come across scripts when evaluating code and the client has expressed that they know Javascript doesn’t work well but to leave it in anyway for email clients that it will work in. Unfortunately, these langauges won’t work in any email client and leaving the code in will often result in your email being rejected for security protection. Get rid of any Javascript or jQuery in your code before you deploy! - “I added the responsive CSS from another template into ours but it’s not working on a mobile device when I test.”
Responsive email started becoming all the rage around 2011 and the buzz is still just as strong a few years later and it’s completely understandable. Over half of email opens happen on the go now so clients want to take advantage of the awesome technique so their subscribers can open emails faster. The biggest mistake we see with this is, because of a lack of knowledge about responsive coding, is taking the responsive CSS from another email and placing it into their own code expecting the responsive behavior to “kick in”. There are classes that will need to be connected and those classes might not be setup for your layout – some classes will be for particular elements or you find that you might need your own while there’s a ton clogging up your header that you don’t need. Responsive can be a bit of a beast, especially if you’re just starting out with email design and coding so take the time to learn about the different methods and see which one might be right for you! - “My YouTube video isn’t working when I send myself a test.”
This misconception is kind of two-fold. While it’s true that you can add video to email, some email clients will show the video, most won’t, while others won’t display controls so the subscriber may not be able to start or stop the video. Also, video that’s used in email is self-hosted and directly linked to the .mp4 file – video from YouTube is either embedded, which doesn’t work in email, or displayed through an iframe, which also doesn’t play nice with email (and could get your email in the Junk box). The quickest workaround is to use a screenshot of the first frame and link directly to the page online for the video to be viewed in a browser. - “Get everything above the fold – that’s the rule!”
Not really a misconception, because it’s very true that the most important part of your message should be above the fold before subscribers scroll, but rather it gets overused and when we receive past email examples from clients, we sometimes see this. Social media icons, share buttons, the logo, the phone number, the free shipping banner, 4 latest products and a guest blog post all crammed above the fold. People are okay with scrolling now! In fact, we come to expect it. Treat above the fold like the marquee of a broadway show – it’s big, it’s flashy, it entices you to go inside, buy a ticket and enjoy the show.
There are rules for below the fold too!
We totally get it! If designing and coding for email isn’t as complex as building websites, why is it so darn confusing and just not straightforward? While there are a lot of things I wish we could do in email (especially <div> positioning), there have been improvements over that past few years – we can add CSS3 for pretty styling with safe degradation for email clients that won’t support it, animated GIFs are a pretty good workaround for grabbing attention and some folks are finding ways to break the rules, like using an auto play video in the background.
Perhaps one day, we’ll be able to transfer the exact same code and techniques from the website to the email client, especially now that email design as a profession is on the rise. There’s a rapidly growing community that aims to influence the future programs and features that will become available but it will be a slow change. Use this list as a quick reference guide on how we get around some of these misconceptions while you’re designing and building your next campaigns – hopefully it will make things a little less complicated!
Until next time – happy designing!