Note: My Web pages are best viewed with style sheets enabled.

Internet Newsletters: Should You Publish Them As Web Pages or As E-Mail Messages?

Copyright © 2010, 2011, 2013, 2018 by David E. Ross

Definitions

KB: kilobytes, 1,000 bytes, 8,000 bits
MB: megabytes, 1,000 KB, 1,000,000 bytes, 8,000,000 bits
GB: gigabytes, 1,000 MB, 1,000,000 KB, 1,000,000,000 bytes, 8,000,000,000 bits

Recently, I received an E-mail message that was over 1 MB. It contained a newsletter from the recreation and park agency of a nearby city. The newsletter was only three pages long, in an 800 KB PDF file, which contained colored graphics. (Without the PDF file, the message was only 8 KB. I don't know what happened to the other 200 KB needed to make the full size reported by my mail server.)

I receive other newsletters via E-mail, many of them HTML-formatted with many graphics. One such weekly newsletter is always more than 100 KB; a recent issue of this newsletter was 151 KB. This newsletter usually begins with a link to a Web version. Since I block E-mail messages that exceed 100 KB — only downloading the first 100 KB — I use the link to view the complete newsletter in my Web browser. However, I recently downloaded the entire E-mail version and noticed holes where graphics appear in the Web version; those graphics totaled 460 KB. The E-mail version of this newsletter issue had 784 HTML errors.

What is the point of this? There are several problems with distributing newsletters via E-mail.

Many individuals setup their E-mail clients to save attachments without opening them. This is a safety precaution to avoid computer viruses, which often spread through E-mail attachments. Thus, newsletters distributed as attachments to E-mail messages generally require extra action by the recipients to open and view them, at least as much effort as clicking on a link in an E-mail message to a Web newsletter. Often, the attachments are merely images that are supposed to be embedded in an HTML-formatted newsletter. Even images, however, can contain malware.
Generally, an aesthetic presentation requires HTML formatting. However, few E-mail clients produce valid HTML. Different E-mail clients might have trouble displaying the newsletter as intended; this is especially true for audio clients used by persons who are visually handicapped.
Sending a 1 MB newsletter to 1,000 recipients becomes a distribution of 1 GB across the Internet. Even with broadband, this can create network congestion. If several recipients all use the same ISP, other customers of that ISP might experience delays in receiving E-mail. If enough recipients are all at one ISP, the ISP might even block delivery of the newsletter.
Each recipient who downloads the newsletter in an E-mail message must then allocate disc space for it. A 150 KB newsletter does not take up much of the space on a 100 GB hard drive and even less of the space on a 900 GB hard drive (the sizes my two physical drives). However, in a business environment where many employees all receive the same newsletter and where lawyers have advised the business to retain and archive all incoming and outgoing E-mail, additional disc capacity might have to be purchased. Even some non-business newsletters have lasting value; rather than save lengthy files, it might be better to save short E-mail messages that contain links to those newsletters on the Web.
If Web-based newsletters remain available, then a new issue can contain links to items in prior issues, avoiding the need to repeat information. There is no dependence on recipients saving old issues.
When creating newsletters for viewing on a computer, whether in an E-mail message or on the Web, the use of PDF is generally inappropriate. In many cases, browsers are setup not to display a Web-based PDF file in the browser itself. Instead, they launch Adobe Reader or another PDF viewer. A PDF newsletter distributed via E-mail is just another attachment to a message with the same issue as described earlier for other attachments.
Jacob Nielsen, an expert on Web design and usability, says:
Users hate coming across a PDF file while browsing, because it breaks their flow. Even simple things like printing or saving documents are difficult because standard browser commands don't work. Layouts are often optimized for a sheet of paper, which rarely matches the size of the user's browser window. Bye-bye smooth scrolling. Hello tiny fonts.
Worst of all, PDF is an undifferentiated blob of content that's hard to navigate.
PDF is great for printing and for distributing manuals and other big documents that need to be printed. Reserve it for this purpose and convert any information that needs to be browsed or read on the screen into real web pages.

Every January, my wife and I send a newsletter to our family and friends. Some copies are sent as hard-copy via postal mail. For recipients whose E-mail addresses we have, I setup a Web page with the newsletter. Then I send those recipients a brief E-mail message with a link to the Web page. The Web version of our latest annual newsletter included a Web page depicting the envelope used for the hard-copy version with graphics (including the image of a postage stamp); a page with the letter itself with our letterhead and signatures as graphics; and a page with photos of our three grandchildren. When printed, the letter itself was three pages long; printed, the page with the photos was two pages long. The six Web pages for our 2009 letter (done in January 2010) were 80.2 KB, including the photos and other graphics. The E-mail message announcing the Web version of the newsletter was 1.2 KB.

Obviously, I think any newsletter distributed through the Internet should be created as a Web page; then, a brief, non-HTML E-mail message containing a link to the Web page can be distributed. This is the most efficient use of the Internet, and it creates the least amount of annoyance for recipients.

Not only should the E-mail message be brief, however, so should the Web link (URI) to the newsletter. The same organization that sends me weekly newsletters also sends me a larger monthly newsletter. The URI to the Web version contains 194 characters! None of the URI is meaningful. While the URI to the page you are currently reading contains "newsletters.html", the URI to the latest version of that monthly newsletter contains:

render?llr=k7pdgucab&v=001UGlpv9WiH3Vuugn-hXwsn7BI-m-9F_yB4MzXNBdso_zVbhEGudnvHJXZ8nlSlsORSi9Y5q-4n6sx8na4JSHYc2nZmCsPjzSgjvxikFK1aQCi13QeuJiCbqa0iwOley7B

a result of using an outside service to create and distribute the newsletter, which is afflicted with 227 HTML errors. There is no excuse for either the length of the URI or the errors. There are several Web-based services that will shrink a long URI to about 20 characters or less, and there is an excellent Web-based tool that will check Web pages for errors.

The city mentioned earlier (Agoura Hills, CA) sent out an urgent public-service E-mail notice supporting a fund-raising activity by the Las Virgenes Unified School District. The fund-raising activity is intended to offset part of the cuts in education funding in the California state budget.

As received at my E-mail client, the message appeared as follows (after removing many, many blank lines):

From: Agoura Hills Rec <agourahillsrec@ci.agoura-hills.ca.us>
To: Agoura Hills Rec <agourahillsrec@ci.agoura-hills.ca.us>
Subject: =?Windows-1252?Q?City_of_Agoura_Hills:_Public_Service_Notice_=96_LVUSD_?= =?Windows-1252?Q?=93Save_Our_Schools=94?=
Thread-Topic: =?Windows-1252?Q?City_of_Agoura_Hills:_Public_Service_Notice_=96_LVUSD_?= =?Windows-1252?Q?=93Save_Our_Schools=94?=
Thread-Index: Acv57Zwt98vtX0n/TVqM6erJXrnm5w==
Date: Wed, 13 Apr 2011 15:15:24 +0000
Accept-Language: en-US

20110412162330464 (2).jpg

City of Agoura Hills - Department of Community Services
30610 Thousand Oaks Blvd.,
Agoura Hills, CA 91301
(818) 597-7361

TEST LOGO 2.jpg

agourahillsrec@ci.agoura-hills.ca.us

Facebook ButtonCLICK HERE TO FIND US ON FACEBOOK

Attachment Converted: "D:\downloads\Eudora attachments\image005.png"
Attachment Converted: "D:\downloads\Eudora attachments\image006.jpg"
Attachment Converted: "D:\downloads\Eudora attachments\image0071.jpg"

Viewed in my Web browser, this HTML-formatted message did not look much better. Several things were wrong.

The Subject header-line was garbled, containing both a real subject — poorly formatted — mixed with pseudo-HTML markup. The subject appears to be City_of_Agoura_Hills:_Public_Service_Notice, but the underlines between the words should have been omitted.
There was no real content. The content was relegated to a JPEG file that presented a letter from the city. Thus, the content could not be reformatted with a different font for someone who might be dyslexic or processed through an audio browser for someone who is blind. This might be a violation of the Americans with Disabilities Act. Even if the announcement were published as a Web page, the use of a JPEG file to present the text content was very wrong.
While embedded JPEG files might appear inline when a message is composed with HTML formatting and again inline when such messages are viewed by the recipient, the files actually traverse the Internet as attachments to the message. Thus, those of us who set our E-mail clients to prevent opening attachments — to reduce the risk of computer viruses — did not see the letter from the city without making a special effort to find the JPEG file and open it in an appropriate viewer.
The message was indeed HTML-formatted. Some people simply reject such messages unread.
Two spurious image files were sent with the message. One was a copy of the city's logo, which already appeared at the top of the JPEG file for the letter. The other was a Facebook icon; not everyone has a Facebook account or wants to bother with any social networking site.
The message was composed and formatted as HTML using Micro$oft's Word 12. All versions of Word are notorious for creating seriously erroneous HTML. In this case, there were 26 HTML errors (about 4 errors per killobyte of message).

24 January 2010
Updated 6 January 2018