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.
TECHWR-L Digest - 16 Oct 1996 to 17... 10/28/96
Thanks for the QuickMail. I'm away from the office until October 28 and will
respond then. If you need the HWM technical editor before then, contact Pat
Boyd or Mike Genin.
Date: 10/17/96 10:03 PM
To: Karen Lew
From: Technical Writers List; for al
!!! Original message was too large.
!!! It is contained in the enclosure whose name
!!! is the same as the subject of this message.
!!! A preview of the message follows:
There are 42 messages totalling 2249 lines in this issue.
Topics of the day:
1. Personal Quality Standards (3)
2. Online Documentation. New! Improved! (12)
3. Documentation Plan
4. Windows help tools (3)
5. online documentation
6. entry-level positions (2)
7. Personal standards
8. Re: Translation into Arabic
9. c/c++ and Java tech writers needed in Silicon Valley
10. Writing for translation -- Oops!
11. Online Documentation. New! Improved
12. Engineer Humor (2)
13. Writing for Translation -- Oops
14. mailing list
15. still no joy on illegal filename
16. Intranets - Don't go there? (2)
17. Footers & Revision #'s (2)
18. Thanks! RE: Documentation Plan
19. Tools for creating online manuals
20. THANKS: Re: HELP!!! Initialism advise needed pronto!
21. PDF vs. HTML
22. Contract writing position available in Waltham, MA
23. Milwaukee firm looking for tech writers
Date: Wed, 16 Oct 1996 23:44:10 -0700
From: Janet Valade <jvalade -at- IX -dot- NETCOM -dot- COM>
Subject: Re: Personal Quality Standards
I can't find the original post in this thread, so I'm not sure I'm
remembering right. But it seems to me that the person who posted the
question was originally asked to give an estimate for updating a
manual. It sounds to me like she did that. And she still believes she
can update the manual for the price quoted.
Then, when she read the manual, she thought she could improve its
quality with additional work. However, this was not part of the
original bid because it was not originally requested by the client. I
see no reason for her to throw this work in for free. It was not
requested and was not in the bid. If she wants to make a separate bid
for this "other" job, it is a totally different question.
Also, it is entirely possible, if you have not discussed the manual
quality with the client, that the client has exactly the manual he
wants. He may have reasons, whether you agree with them or not, for
every element of the style, contents, etc. of the manual. He may be
outraged if you change any of it. You may then have to spend more time
putting it back the way it was. I certainly wouldn't rewrite the
manual without discussing the changes with the client.
jvalade -at- ix -dot- netcom -dot- com
Date: Wed, 16 Oct 1996 23:36:23 PDT
From: Robert Plamondon <robert -at- PLAMONDON -dot- COM>
Subject: Online Documentation. New! Improved!
I'm perplexed. People keep telling me how on-line documentation needs
to be different from other documentation, and yet all the best on-line
documentation I've used is exactly the same as its printed counterpart.
Take QuickBooks, for example. Its on-line documentation stinks.
It has about three levels of on-line help: pop-ups that obscure your
work and tell you nothing, on-line help that tells you that you enter
names in the NAME field, and on-line manuals that tell you that you
enter names in the NAME field. Duh!
(Whoops! I almost forgot the duh-level audio help for people
who can't read.)
This is not only duh-level documentation, but it's simultaneously
fragmentary and redundant.
I've been saddled with many applications whose documentation consists
of mazes of twisty passages, all different. No structure, spotty
coverage, lots of duh-level stuff repeated seventeen times. It's
In a book, you can flip through the pages, look at the table of contents,
or look in the index. Much of the on-line documentation I've been using
has NONE of these features. A top-l