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.
Subject:Re: Learning time billable? From:Peter Collins <peter -dot- collins -at- BIGFOOT -dot- COM> Date:Sun, 14 Feb 1999 15:42:41 +1100
"However since I don't have much experience in the type of technology that
his company is related to, I have to research and learn about it. We agreed
on an hourly rate before I started and my question is:
Is the time that I spend learning billable?"
Actually, you should NOT research and learn about it. This view is well
presented in earlier emails to this forum, which you may find in the
Once you have learnt, you are not a beginner and are less likely to
document the things that a newby needs to know.
Best is to start writing the procedure section while you are completely
ignorant of the system. Don't even get a quick demo of it. Get ready to
write. Take notes of everything you do, including how you get in and out of
Start by loading the software yourself (if that is what users will have
to do) merely by clicking on SETUP.EXE (or whatever) without reading
anything - just as most of us naughty people do already. Move on to doing
the basic things that a newby ought do. Note every false start and
'gotcher' that you experience so you get them all noted as essential
guidelines for your newby readers. As you become more experienced, move on
to the more complex features, assuming, as you write, that your readers
have by now got the same level of experience. When you find yourself having
to go back to your notes or otherwise refresh your memory about some
earlier procedure, ther please put in a hyperlink or page-ref bacdk to that
earlier material, for your readers will have the same problem you just did.
When you have worked through every alternative to every option on every
dialogue and menu, all the procedure stuff is done. Then you can write the
supporting material. That may mean, at the very least, going back and
putting meaningful examples into your instruction stream, and writing
'purpose' sections for each task or feature, so readers will know what they
can use those product elements for, in their own environments.
Of course, at any point where you have to ask your friend for help with
the product, at that point you may need to write his explanation into a
principles or reference section, with a link or ref to it from the point
where you stumbled while you were working through and documenting the
I believe you will produce more beginner-friendly texts with this
approach. Be warned that you will also find a number of features that do
not seem to work as you expect. You will, by the time you have finished,
have systematically used, in all its glory, every feature and option in the
system and you may well be the only one who has. No, it's not your job to
be a product tester, but get used to it - this is the real world!
Please let me know, eventually, what you decided on, and how it went
Peter Collins, VIVID Management Pty Ltd,
26 Bradleys Head Road, MOSMAN NSW 2088, Australia
+61 2 9968 3308, fax +61 2 9968 3026, mobile +61 (0)18 419 571
Management Consultants and Technical Writers
email: peter -dot- collins -at- bigfoot -dot- com ICQ#: 10981283
Short stories and CV: http://www.angelfire.com/pe/pcollins/