TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Erika Yanovich wonders: <<We are sending an HTML e-newsletter to our
customers which includes contents exclusively created for the
newsletter (cannot be found on our website as articles). However, the
entire newsletter archive can be found on the site.>>
I'm not sure I understand this: If the "entire" archive can be found
on the site, what's the point of creating content exclusively for the
newsletter -- if it's going to end up on the site anyway? Make your
life easier and produce the same content in both places.
<<Since the newsletter editor is on maternity leave, I'm getting help
from a graphic designer and according to her this is not the way a
newsletter should look like. She prefers a much shorter HTML, full of
links to articles that appear on the site and no actual contents.>>
As you'll undoubtedly discover from replies to your question, you'll
have a wide range of preferences to consider. Graphic artists in my
experience have a near-allergic aversion to reading*, so her attitude
isn't surprising. You won't get any single "this is the only good way
to do it" response that everyone accepts. In addition, note that a
goodly number of mail administrators block HTML messages because of
the fear of spoofing and phishing and boobytrapped GIFs, so you may
find that producing only HTML means many of your readers won't ever
have a chance to read the newsletter.
* Yes, I'm stereotyping. Sorry! That's been my experience in 20 years
in the biz.
All this being the case, the "ideal" solution is to provide both an
ASCII (plain text) and an HTML version of the newsletter, and let
subscribers choose which one they want to receive. Using automated
software such as the Mailman software used by techwr-l lets users
change their preferences on the fly, without your intervention, and
that can be a very useful thing given the burden that subscriber
management can become if you have to handle it all. It's fairly easy
to turn HTML into ASCII, so this isn't an onerous burden for the
publishing staff. Been there, done that.
In terms of content, the ideal solution would be to give readers the
option of "just the links" vs. "the full Monty", but then you've
created a difficult task for yourselves: you now have to create four
different versions of the newsletter (HTML and ASCII version of links-
only and full text). Not pleasant. The compromise solution that works
reasonably well for everyone, if not perfectly for anyone, is the
following: First, create an executive summary (100 to 200 words max,
and shorter is better*) of every article, and start the full text of
the article with that summary. Then post the full article only on the
Web site, and e-mail a collection of these summaries followed by
links to the full article. Those who just want the links only have to
read a small amount of text to see the links; those who might want
the full article get enough of a taste of its contents that they can
decide whether to follow the link.
* Try this challenge (it can be a fun party game if you're the kind
of word geek who enjoys Balderdash/Fictionary <g>): bet your audience
that you can describe any topic that you're familiar with in 50 words
or less. Surprisingly, you can. I once spent a profitable few hours
proving this to some workplace colleagues who didn't believe me and
who acquired a new appreciation for my ability to cut to the chase.
Yes, you sacrifice all the details, but if you're clever and
understand the topic well, you can do a surprisingly good job of
presenting the important bits... and in the context of Erika's
question, these are the bits that entice readers to read the article.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
