The world wide web and in particular the World Wide Web Consortium (W3C) have done a pretty good job in developing standards by which the developers of browsers such as Microsoft’s Internet Explorer and Mozilla’s Firefox are gradually dragging themselves towards compliance. The benefit to website developers is enormous and we have all but said goodbye to the days of having to build different versions of a website so it will appear the way we want in the different browsers. Surprisingly, whilst Microsoft have a reputation for doing things their own way, they were not the worst culprits in the early days: designers who remember version 4.07 of the Netscape browser will know what I mean.

Let’s just take a step back for a moment and have a look at why standards are important. It is clear that computers are used by people with specific and wide-ranging needs. Take for instance someone with a visual impairment who needs to use a computer. It may be that a monitor is not a feasible device for displaying the content and text reading software may be the preferred option. On the other hand, perhaps a monitor is acceptable but the user needs to be able to alter the colour scheme, font and type size so it is legible to them. I started out in this business before the web was invented: when the designer controlled the layout down to the finest detail which, once printed, couldn’t be changed without an expensive reprint.

With the advent of the web, designers took a while to get used to the idea that the recipients of their beautifully crafted designs would have the audacity to change them to suit their own needs, even to the extent of turning off the pictures and choosing to download only the text! However, with the introduction of cascading style sheets, and the (almost) universal adoption of these standards, it is now possible to create visually rich websites that behave the way they were conceived and are available in some form or other to anybody who can get online. That’s what standards provide: a framework around which we can work, knowing that our output will be used in many different ways. Whilst we think we can craft our web pages beautifully, I know the audience might think otherwise, and I respect that.

Unfortunately, this framework does not extend to email. Consider the plethora of ways email can be sent and read: dedicated clients such as Outlook Express (or the other version of Outlook that ships with Microsoft Office), Eudora, Mozilla Thunderbird and Lotus Notes; or the webmail systems provided by the likes of Yahoo! or Googlemail. AOL is different again. The point is that they all differ and, most importantly, they don’t comply to the same standards, and they may or may not comply with accessibility issues. Now this is a recipe for chaos.

Those in the know will be aware that there are two basic versions of email: text only and html. The first is just as it says: text only, no pictures and no formatting, whereas html turns emails into something that can look not dissimilar to a web page. This is unsurprising considering html is what makes web pages work. However, many so-called purists hold the view that html email should be banned and there are valid reasons why that should be so which I will come on to. But html email isn’t going away, and this creates problems for anybody who wants to communicate with their customers on a regular basis by an email newsletter but doesn’t want to present their information in the Courier typeface and with no formatting.

Is there a perfect solution? Not surprisingly, the answer is ‘no’, especially if you are looking to send out a complete - and perhaps lengthy - newsletter by email. Some of the pitfalls which can be encountered and cause problems with varying email clients are: broken links within a page, elements being repositioned, style information being rewritten and so on. Put simply, you lose control and in an uncontrollable way.

So what is the best approach? Well, given all of the above, here are some of the key issues to consider:
Some recipients will either choose to receive their email in plain text or be unable to receive it any other way, so your beautiful newsletter will have no pictures and some links might not work.
It is possible to send out one email with both html and plain text versions included. However, this will nearly double the size of the email and all your readers will have to download both versions, one of which will be redundant.
Accessibility issues will not be addressed in the way they can be on a web page.
Emails don’t get indexed by search engines, so your valuable articles won’t be searchable unless you duplicate the newsletter onto your website.

From this it might be getting clearer as to where I am heading. The answer in my mind is to combine the immediacy and directness of an email to alert your readers of a new newsletter, but redirect them via a link to your website straight to your newsletter page where you can present them with the information in a format which provides the greatest flexibility in terms of accessibility and design. That way each medium is being used in the way it was intended.

There have been some useful articles written on this subject. The best I have seen, by Tim Slavin, gives some excellent advice on how to produce an html email. However, even this points out that not all the pitfalls can be avoided. Ultimately, any solution involves an element of compromise.