Posts Tagged ‘html email code’

5 reasons Email design is different to Print DM design

Thursday, April 8th, 2010

aka How to provide perfect design PSDs to an HTML email developer.

What do you think about this article? please add your comments below!

An all image email renders badly when images are disabled

More brands than ever are transforming their traditionally printed direct mail activity into email marketing campaigns, and as a result direct marketers and their designers are having to learn new skills designing for email. One of the most common ways that email campaigns lose their effectiveness is when they’re not designed for the channel, and they’re simply a DM campaign that’s been dropped into HTML, so here’s our tips for making kick-arse email direct mail campaigns.

Put down Illustrator

Whilst you may use Illustrator to create initial assets, particularly on cross channel campaigns, final email creative should be artworked in Photoshop (Or a equivalent bitmap based program) at 72dpi in RGB colour. When it comes to building the design into HTML, the HTML developer will require access to different layers, so ensure they’re not flattened. As a rule of thumb, emails should be maximum 600px wide. And don’t do everything in Illustrator and save it out as a psd, we’ll know!

Email rendering isn’t precise

Barring gremlins at the print house, when producing print assets we can almost guarantee how the resulting artwork will be displayed, right down to the smell of the stock. Unfortunately when designing emails we don’t have this luxury (although scratch & sniff is but a USB dongle away). Email code renders differently on different operating systems, different devices and in different email clients – Consequently the fold will move around for different recipients (it’s typically 400-700px), and the real estate that a paragraph of body copy takes up will vary due to differences in line height and font size rendering.

But, Email rendering is precise

Having said that, things like text and images are held within flexible tables, as opposed to more rigid text boxes and bounding boxes. So when changing copy and images for use in an HTML structure that’s already built, remember that any extra copy or larger images will stretch out and “break” the design. It’s worth setting precise image dimensions and copy limits, but also consider designing around this; common issues include two columns – one text and one image, when extra text is added there may be extra space created underneath the image to compensate. As a rule of thumb it’s easier to guarantee horizontal alignment and accept that vertically things may shift slightly.

Postman Pat goes postal

Whilst the Royal Mail and/or a postman chasing dog may sometimes get between us and the recipient, they don’t usually open each mailing, read it and either mark it as junk or just throw it out. Unfortunately email is different, and the chances are you’ll have to jump through some deliverability hoops in order to get to the inbox. Spam filters don’t look too kindly on all image emails, for example, so it’s worth getting some web text in your design somewhere (that’s standard web fonts like Arial or Verdana). Likewise some email clients will disable images by default, so think about how the message will look without images turned on – we can use alt-text to replicate in-image copy, but it’s not ideal – again, consider using web text and using things like the Johnson Box.

And Finally, Less Is More

I think this is the same in print and really it’s borne out of the client wanting to pass on too much information – but thanks to screen’s lower resolution and the recipient’s tendency to skim read or even skip large paragraphs, we have even less room for large chunks of copy than in print. We do, however, have only a simple click between us and the web, so it’s worth thinking about using the email as a teaser and putting your main/large content on a landing page. A good text size for body copy, by the way, is about 11 or 12pt, 10pt is ok for terms and conditions but don’t go any lower (also ensure point sizes are whole numbers, it breaks the internet if they’re not).

Follow @iamelliot and bookmark http://www.emaildesignreview.com/ for more hints and tips designing for email.

Email Design For The iPad: A Preview

Wednesday, April 7th, 2010

The hot topic at the moment is how the newly released iPad impacts design practices and the user experience for email.

Gmail’s blog has details of the iPad Gmail interface here, and thenextweb promptly explains how you can access the interface from a laptop here. iPad will come with Wifi and 3G options, find out about iPad 3G plans here.

Style Campaign and Campaign Monitor have been jointly testing rendering in the iPad’s mail client, and will release a report in the next few days – an early twitpic can be found here.

We’re itching to get hold of one, and we’ll be posting our thoughts on it as we do. Until then here’s a quick video showing that the overall iPad interface is so intuitive literally a toddler can use it..

Best Practices for Coding HTML Emails, part 1

Thursday, December 10th, 2009

HTML code for email newsletters is a deceptively complex art, and ensuring your beautiful concept looks as intended in the plethora of different email clients and platforms can cause real headaches. In this series we’ll take a look at some html email coding best practices, to find out what can really help to make your mailing render properly without it taking an age to code.

Get dirty in the code

You have to hand code emails – coding using WISYWIG will add a ton of erroneous code that’ll lead to frustration trying to get your build to render correctly. Dreamweaver can be a good tool but make sure you still code things yourself. Don’t ever use word. Ever.

Tonight we’re gonna code HTML like it’s 1999

In web coding there’s been a revolution in recent years – CSS and XHTML allows you to split content from layout and formatting, which makes coding a lot more versatile, lighter weight and easy to work with. Unfortunately, coding standards for email are still a long way behind this, for various reasons, and essentially the best way to ensure your design renders properly across most email clients is to code “old school” html, using tables to create the layout.

Look out for more HTML Email code best practice in forthcoming weeks!