Good HTML Email Newsletter Design

- Page 2 -

Use links extensively

Links are great: provide short summaries of articles, and link to longer and more complete versions. Provide the links in context, and use them as they would be used in a typical web page, rather than in a big bunch at the beginning or end of the newsletter.

Use short human-generated summaries and tables of contents

The first thing in an HTML newsletter should be a descriptive title, followed by an easy to use, hopefully hyperlinked table of contents. Make sure that the links are either clearly external (will launch a browser), or that they lead to anchors in the newsletter. Use the former if the newsletter doesn't actually contain the articles, and the latter if the newsletter does contain articles.

Make sure that if the newsletter contains a bunch of abstracts of longer articles found elsewhere that the summaries are written by humans rather than generated by a computer (à la search engine summary report) or just appropriated from the first paragraph or sentence of the article. The summary should be as meaningful as possible.

Use bulleted lists

Lists, instead of paragraphs of text, make the newsletter scannable. Explain main points following a short (one or two sentence) summary by using a short bulleted list. The table of contents could also be a bulleted list.

Use hierarchical elements

HTML offers H, or heading, tags, which let the newsletter author specify a document hierarchy. For both accessibility and visual reasons, use the hierarchy. H1 tags should be for the newsletter title, and higher number H tags for subitems of all kinds. Take advantage of what HTML offers in terms of document hierarchy. For example, this page has a hierarchy specified with H tags that makes it easier to scan and more accessible.

Bad things in plain text newsletters

Plain text newsletters are quite different beasts than HTML newsletters. They don't have as many useful intrinsic properties; authors must be very craty in order to make them scannable and useful. A lot of plain text newsletters, including one I get from my hosting provider, are way too long and complicated to be of any practical use.

Avoid the following pitfalls in plain text newsletters:

• long articles
• forcing users to go to another medium
• prose
• Long articles

Again, long articles are a no-no in newsletters, particularly in plain text newsletters. There is usually no easy way to tell when one article ends and another begins, and plain text newsletters are often viewed at very small font sizes, making them hard to read anyway. The shorter, the better.

Forcing users to go to another medium

There must be a reason to choose plain text newsletters over HTML newsletters; don't send a plain text newsletter that has no content other than a bunch of URLs, phone numbers, or mailing addresses. Send a newsletter with content, and don't force users to skip to another medium to get the real content. Plain text might not be perfect, but since you've got the user's attention, take advantage of it. Making the user copy and paste a URL just breaks his flow.

Prose

For the same reasons that articles in plain text newsletters should be short, the articles should also be written in point form and be cleverly structured: conclusion, main points, important notices or background info, and for more info click... (URL). Using drawn out language will make the newsletter harder to scan and understand.

Good things in plain text newsletters

Plain text newsletters can be positively accented with by following a few guidelines:

• use spacing, capitalization, and symbols to emphasize document hierarchy
• tell users what's in the newsletter straight away
• include only two or three subjects per newsletter
• Use spacing, capitalization, and symbols to emphasize document hierarchy

Plain text newsletters don't have the style and structure facilities afforded by HTML, so the author is restricted to spacing, capitalization, and symbols for emphasis. Headers might be all caps, preceded by a > symbol, and so on. Stars or dashes can be used as separators. Try not to run text together as if it each article and the table of contents were combined into one long document.

Tell users what's in the newsletter straight away

Because it's harder to scan plain text newsletters (due to the lack of variation in font size, layout, etc.), the user must be explicitly told what's in the newsletter right away. If the newsletter is being emailed, use a good subject line. In other words, use the subject line to describe what's in the email, not just to say that it's issue XXX of the SuchAndSuch newsletter. Additionally, use a dashed/bulleted list at the very top of the newsletter to emphasize what follows in the document.

Include only two or three subjects per newsletter

Again, because plain text newsletters are harder to scan and navigate, they should be simpler on the whole than HTML newsletters. Only include two or three items, subjects, or articles in a plain text newsletter. If there is more to say, break it up into additional newsletters. It's better to send two issues than a double issue, because the double issue will be harder to deal with in many ways.

Conclusions

None of the above guidelines are necessarily going to be always useful, especially as different newsletter media are developed. In the future, newsletters may be a Flash movie that can accomplish everything in one place and with relatively little bandwidth usage. For instance, it's not practical to include five full length articles in a newsletter now, but it may be in future interactive versions of the same newsletter.

More important than guidelines about how to format newsletters is what should be in the newsletters. Newsletter authors must be able to justify the newsletter according to user goals. Don't send a newsletter if the user is going to go out and get the information anyway; send the newsletter if the information is critical and unlikely to be self-discovered by the user. Talk to users, model their use of the information in the newsletter, and an appropriate format will become more evident.
 

Read more theory columns at http://www.merges.net/theory/ written by Adam baker who is a highly talented graphic designer, please check out his work here http://www.merges.net/