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.
Steve Hudson reports: <<To QA something, one needs the FINAL system. I mean,
to reducto ad absurdum (simplify stupidly) how could one test a help system
based on the func spec for such? Nope - you NEED the complete final product.
So, ship your "completed" project, with robohelp's DLL's etc, to the
testers.>>
Quality assurance (QA) of the type you're suggesting is another issue
entirely, though obviously a strongly relatedone. It's easy to test the
technical correctness and readability of text that will shortly become
online help without actually creating a compiled help file. But you still
have to do a second QA step on the help file itself. Although you could
theoretically do both at once, my experience (15+ years as an editor)
suggests that reviewers do a uniformly poor job when they try to concentrate
on more than one type of review simultaneously. Editors too, for that
matter; most of us do at least two passes through any document and look for
different things in each pass. The parallel with traditional print
publishing is pretty close: when you produce printed publications, you do a
technical check and and editorial check to finalize the material as much as
possible before you begin layout. Once you've got the layout in place, then
you proofread it to make sure nothing was lost in translation, plus to
handle all those niceties such as line breaks, widows and orphans, and so
on.
Interestingly, many writers now use templates in such a manner that they're
essentially doing the writing and layout simultaneously, since the template
applies "final" formatting on the fly. There's a lot to be said for this
approach in terms of efficiency, but in the end, it doesn't eliminate the
need for proofreading the final result. I've seen this problem arise in its
worst incarnation in a database publishing environment: I once owned a GM
car whose manual had clearly been published in this manner, and while most
of the manual was just fine, several important sections obviously related to
an entirely different line of cars. Nobody proofread the final document, so
many thousand vehicles ended up with an incorrect manual.
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"The most likely way for the world to be destroyed, most experts agree, is
by accident. That's where we come in; we're computer professionals. We cause
accidents."-- Nathaniel Borenstein
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
