HTML Newsletters

Because consistency isn't what the client pays for...
Skipping round your sarcasm for a moment :p : that is exactly right. The client is, in almost all cases, paying to make an indirect profit. That's what clients want: a successful email campaign that achieves the results that they were hoping for.

Visual consistency doesn't come into it.

In fact, the two are mutually exclusive for all but the plainest of creatives.

The problem lies with the client's initial expectations which, as you imply, are "this must look identical in all email clients".

The solution lies in informing the clients that the only way to do this is to send their email as one big image. Further, inform them that as a consequence of near-universal image-blocking/substitution their recipients will be presented with an ostensibly blank email.

"That's if it gets past an ESP's spam filters for image/text ratio imbalance in the first place", you add, finally.

I've had clients who've accepted this, and clients who haven't. Of those who haven't, I can recall a number of occasions where these clients have taken their business away in a huff only to come back sheepishly at a later date when their campaigns haven't seen the success they were expecting because another designer kowtowed to the client's naive expectations.


That's as silly as saying don't bother making a website look the same in IE6 [...]
I would counter that it's more silly to salary a developer a goodly sum to produce absolute pixel-perfect cross-browser consistency. Especially when some of these browsers are seeing an irreversible decline in use.

And it's not just me who thinks it's more silly to strive for pixel perfection:

http://boagworld.com/design/letgo/
http://forabeautifulweb.com/blog/about/five_css_design_browser_differences_i_can_live_with/


you just have to as a lot of people will be using Outlook 2007. It does cause problems but you can't just ignore it and its not impossible to get it looking the same in the majority of the most used mail clients.
Do you actually know how many people are using Outlook 2007? 50%? 30%? 15%, perhaps? No, it can't be as low as that, otherwise email designers and developers wouldn't be so up in arms and changing their working practices to accommodate it.

6.1%.

Now of course there are caveats to their findings, but it's still the most comprehensive study you'll likely encounter to date.

And yes, 2007 use is certain to increase as time rolls on. But I don't think it'll ever be the dominant email client, and certainly not something to design for at the detriment of others.


The only difference I've come across when coding for Outlook 2007 when compared to other mail clients is that you can't use CSS.
Yes you can. It ignores some declarations, and misinterprets others, but as long as you design with sensitivity to 2007's idiosyncrasies, you can come up with creatives that look good in 2007 and better in more style-tolerant email clients.

As with all things internet-design-related, the golden phrase is: graceful degradation.

Make everything using raw tables, using nested tables, v-align, td's, tr's, font size. Its quite possible to get it looking very near identical to the design this way, unless you're designer has made something ridiculous!
In order to provide the recipient with something visually interesting, or to stay within a brand's guidelines and visual 'voice', designers are frequently made to come up with something ridiculous :D

You're right about using most of the HTML elements you mention, though, yes. Font "SIZE", for instance, should be employed, but only as a fallback for those email clients that can't interpret inline CSS font-size declarations.

But you have much less control over typography with HTML element parameters alone than when employing CSS. What about letter spacing? Line height? Small caps?

To get it looking the same you need to make compromises, you can't use background images, so use a solid colour. You cant use padding and margins, so use empty td's with set widths/height for spacing.
Ooh, I wouldn't rely on empty TDs, especially when it comes to height declarations! Some email clients collapse them no matter what.

If you do have to design your emails this way - or if you're just an unfortunate coder who's been handed an approved design - then the only way to guarantee proportions is to use the dreaded spacer gifs.

Also, you can use background images, but (a) make damn sure there's nothing important and exclusive within the image, and (b) use an appropriate solid colour for the background in case it's not displayed [not just 2007, but also Hotmail, annoyingly].

Why visually cripple an email for everyone to pander to a minority? As I pointed out earlier [much earlier!], designing for consistency for the lowest common denominator only results in everyone getting exceedingly unengaging emails.

It isn't that hard if the client is paying then try and do it properly!
I do do it properly. I've been doing it - and by it, I mean designing and coding HTML emails while advising clients on how to achieve more successful email campaigns - properly day in, day out for six years ;)

Anyway, suarve... I'm sure that helps :D
 
Oh, and fishfishfish's advice is spot on, too. Speaking of this: which broadcaster do you use, fff?

At the moment we use IonMX (Bluestreak), which works well but is getting rather dated. We're about to switch to Silverpop, which is much more powerful. We'll be able to provide individually personalised emails each with its own content tailored to the preferences of specific users, which should help push up open rates and click throughs to our sites. We can then also put in tailored ads, too. (I know people hate them, but they do pay the bills and most websites wouldn't exist without 'em).
 
Just out of interest, and because sites of this sort seem to like to hide prices without contacting them directly, how much roughly do IonMX and Silverpop (and any other services people here use) charge.

I currently 'run' the newsletter for our company and I'd like to see what else is out there (mainly because I'm aware that ISPs/recipients may have the host blacklisted), but cost is a determining factor. We send it out to about 9,000 people probably two or three times a month if that helps.
 
At the moment we use IonMX (Bluestreak), which works well but is getting rather dated. We're about to switch to Silverpop, which is much more powerful. We'll be able to provide individually personalised emails each with its own content tailored to the preferences of specific users, which should help push up open rates and click throughs to our sites. We can then also put in tailored ads, too. (I know people hate them, but they do pay the bills and most websites wouldn't exist without 'em).
Silverpop does indeed look rather interesting; the landing page/microsite attention in particular, speaking as both a designer with a creative hat, and someone who can see the obvious benefits that they can deliver over 'linking to a home page and hoping for the best'.

Thanks for replying :)
 
Just out of interest, and because sites of this sort seem to like to hide prices without contacting them directly, how much roughly do IonMX and Silverpop (and any other services people here use) charge.

Sorry, haven't a clue about that I'm afraid. We just get access to it via a company-wide contract for newsletter campaigns across all of our magazines.
 
Email rendering of HTML is infamously poo. Really, it's so utterly foul. Blame MS and Outlook/Word for that.

So yeah, just pummel the page through FrontPage. Text rich is always good. No point sending a newsletter if there is nothing to read.
No, don't. Outlook renders HTML mail just fine - it is services like gmail which over-ride CSS properties which are the problem.
 
No, don't. Outlook renders HTML mail just fine - it is services like gmail which over-ride CSS properties which are the problem.
Nay, Nay and, erm, thrice nay! :p

EDIT: To be fair, there's an element of truth in what you say, but it's not just Gmail overriding selected CSS properties, it's all email clients with one exception: Thunderbird.

*hugs Thunderbird*

Of course, the delicious irony is that those with Thunderbird are least likely to want HTML emails :D
 
Last edited:

I really would reply to most of it but that post is hugeeeee :p

I'm not having a go directly at you saying "do it properly if the client is paying", just in general.

I've only had to use spacer gif's once and have used empty <td>'s on various occasions testing through litmus without any problems appearing. Maybe something that will appear in the future for me!

Just because a handful of websites are against IE6, you still can't deny its approx 17% current usage. Thats an average of ignoring 1 in 5 of your viewers, especially when you are making sites that will be viewed/tested in offices around the world which for ridiculous reasons still haven't upgraded!

When I said a lot of people use Outlook 2007 that was a mistake. I meant to say that a high % of people will be viewing the email in clients that don't handle CSS properly/fully so you need to make sure tables/html is used as much as possible without CSS.

Using the stats you provided from campaignmonitor, around 27% of users can't see background images. Ensuring you have an alternative solid background color is ofcourse something that must be done. But where possible I try to make sure the design doesn't heavily rely on background images but is altered, in a non-degrading way.

Whoops written more than I was meant to :D
 
I really would reply to most of it but that post is hugeeeee :p

I'm not having a go directly at you saying "do it properly if the client is paying", just in general. [...]
Yeah, sorry: I got a bit carried away. And on a day off work, too :D

I can't remember offhand which clients collapse empty TDs, I'm afraid; I can only recall that it happened to me often enough in the past to resort back to spacer gifs, despite the drawbacks they bring [increased spam/junk risk, increased page weight, possibility of ugly replacement images in some clients].

Best to avoid spacer gifs when designing emails, if you can. Padding - and to a lesser extent, Margin - can be very useful here, actually. The key is knowing which elements to use them on; padding a P is flaky, while padding it's containing TD is more consistently rendered, for instance.

The IE6 thing - I inferred from your post that you meant visually identical cross-browser consistency. The point I was trying to make is that as long as the site functions identically for poor ol' IE6ers, and doesn't look aesthetically offputting, it doesn't matter. Lose the odd background image here, don't have rounded corners there... that sort of thing. Acceptance of this means that, in turn, expensive and talented developers could be more efficiently employed on more important tasks. That's all :)

Yeah, when I finally found out that Outlook 2007's user base could be as low as that, I was astonished. The entire HTML email design community, myself included, got into a right royal flap over very little. That's the downside to reading all them there design blogs :D

Aaaanyway. How's the e-[newsletter/flyer/shot] going, Mr Suarve?
 
Yeah, sorry: I got a bit carried away. And on a day off work, too :D

I can't remember offhand which clients collapse empty TDs, I'm afraid; I can only recall that it happened to me often enough in the past to resort back to spacer gifs, despite the drawbacks they bring [increased spam/junk risk, increased page weight, possibility of ugly replacement images in some clients].

Best to avoid spacer gifs when designing emails, if you can. Padding - and to a lesser extent, Margin - can be very useful here, actually. The key is knowing which elements to use them on; padding a P is flaky, while padding it's containing TD is more consistently rendered, for instance.

The IE6 thing - I inferred from your post that you meant visually identical cross-browser consistency. The point I was trying to make is that as long as the site functions identically for poor ol' IE6ers, and doesn't look aesthetically offputting, it doesn't matter. Lose the odd background image here, don't have rounded corners there... that sort of thing. Acceptance of this means that, in turn, expensive and talented developers could be more efficiently employed on more important tasks. That's all :)

Yeah, when I finally found out that Outlook 2007's user base could be as low as that, I was astonished. The entire HTML email design community, myself included, got into a right royal flap over very little. That's the downside to reading all them there design blogs :D

Aaaanyway. How's the e-[newsletter/flyer/shot] going, Mr Suarve?

All going good thx :)

Was given another 500 emails to add to the ever growing list, so am checking to make sure everything is good.

Was having a look at the OCuK newsletter than was sent today - how do you rate how that one is made up - code/html wise?
 
All going good thx :)

Was given another 500 emails to add to the ever growing list, so am checking to make sure everything is good.

Was having a look at the OCuK newsletter than was sent today - how do you rate how that one is made up - code/html wise?
Pleased to hear it :)

I've not seen the OcUK HTML version, and it's late but I'll see if I can track one down in the morning.

I have a strong recollection that their plain-text version of their newsletters from years ago used to consist solely of "This newsletter is only available in HTML format" or something.

Thanks for giving me the choice, OcUK :p

So an immediate lesson there is: always do a full, proper, informative plain-text version of your HTML emails for the people that choose that delivery method.

EDIT: Ah, there it is: http://www.overclockers.co.uk/newsletter.php :D I'll give it a look-see later on.
 
Last edited:
Was having a look at the OCuK newsletter than was sent today - how do you rate how that one is made up - code/html wise?
Right. Strictly looking at the coding of the newsletter and leaving aside the other aspects, it's clear that they've got at least one thing right: the HTML is old skool, yo.

The good:
  • TABLEs for layout
    As mentioned before, these are much more reliable for defining areas than DIVs or other more semantically correct methods in emails.
  • No DOCTYPE
    This is actually a good thing for HTML emails. A web page can only have one Doctype declaration, and if you're viewing it in a webmail client, there's already one specified. So if you declare one at the top of your email code, it's going to get stripped out or ignored. Of course, browsers react differently depending upon the Doctype, therefore if you've coded and tested your email with an XHTML Doctype and your webmail client renders it using a HTML 4.01 Doctype, you can get some head-scratchingly different results. Font size declarations not being interpreted properly, for instance.
  • All images have WIDTH and HEIGHT specified
    In some clients - Outlook being the one that springs to mind - when images without specified dimensions are blocked/substituted, they get stretched to accommodate the "This image has been blocked..." pseudo-ALT tag. Thus a 5px-high ruler image, for example, without dimensions suddenly becomes 100px high, or even more. This can have a knock-on effect to all following layout, and your key message text can be shoved out of view. So always specify WIDTH and HEIGHT on your images to prevent this and maintain layout integrity.

The bad:
  • My god, it's full of images
    As is typical with emails that have been based on print ads [or designed by someone with more experience in print], the entire email is composed of a grid of images created in Photoshop and then sliced in ImageReady. Guess what happens with email clients that block images by default [i.e. nearly all of them]? Yup, the recipient is presented with a blank email. While far from ideal, this sort of all-image email wouldn't be quite so bad if it weren't for...
  • Blank ALT tags
    Got Firefox? Got the Web Developer extension? View the newsletter using this link. Now with the Web Developer extension, replace images with their ALT attributes, as an email client would. What do you see? :D The lesson here is: if you must do an all-image email [and there are many reasons why you shouldn't], then at least give each image a descriptive ALT so that recipients have got something to go on, rather than NOTHING AT ALL.

There are more issues with the 'newsletter' than just these coding ones - it's too wide for some people's preview panes, there are arguably too many items all battling for a recipient's attention [why 'hope with a shotgun' when you can 'make certain with a sniper rifle'?], there's no clear 'unsubscribe' link at the top of the email, which can lead to erroneous spam abuse reports and deliverability issues as you become blacklisted by ESPs - but those are the main issues from a code standpoint.

Hope that helps, suarve [and Spie :D] :)
 
Last edited:

Well that's the kinda way I was trying to do it, using loads of tables. Too ages too, as I'm used to using divs :)

One question.

The newsletters is in fact from someone who deals with print and has a load of white text, that looks good when backed by an image, but invisible when the images haven't downloaded :(

Is it acceptable to use the bgcolor tag for the body (setting it to grey) so the text still shows when the images haven't yet been downloaded - as without this, it makes the email look blank :)


Also (and this is a longshot), has anyone ever used email mareting director? You can insert unsubscribe links into your email. Clicking on this link takes you to a third party service called Zeop (iirc), When you next sent a campaign, you connect to thise rvice to update the links. Is there any way to make the unscubscribe go directly to our site, instead of the Zeop thing?
 
[...]The newsletters is in fact from someone who deals with print and has a load of white text, that looks good when backed by an image, but invisible when the images haven't downloaded :(

Is it acceptable to use the bgcolor tag for the body (setting it to grey) so the text still shows when the images haven't yet been downloaded - as without this, it makes the email look blank [...]
Not only is it acceptable, I'd encourage it - and possibly reinforce it with an inline style [though I don't recall many email clients ignoring background-color declarations].

The only thing to watch out for with this is that the TD doesn't extend beyond the dimensions of the background image [assuming the image isn't repeated, and doesn't fade into the TD bgcolor]. You don't want any horiz/vertical slivers of bgcolor popping into view, so you'll also need to check that the layout doesn't flex with inc/decreased font size, for example.

No idea of your longshot, though, sorry.
 
Back
Top Bottom