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.
At 08:31 AM 1/28/99 -0700, Eric asked:
>How do you learn new tools (in the narrow sense),
>technologies, or products?
In general, I learn by *gasp* reading the documentation. I realized, after
rereading your post, that for me this question actually has two different
answers: I learn new software tools that will help me accomplish my job in
one way, and new software tools that *I* will be documenting in an entirely
different way.
To learn a new tool of my trade, such as RoboHTML, PaintShop Pro, or
Macromedia Director, I start with the vendor's tutorial, if there is one.
If not, I take the User's Guide (again, if there is one...) and start with
page 1, and read it through from start to finish, opening the software as I
read, following any steps I encounter in each chapter, and exploring the
software in a fairly controlled fashion. It feels important to me to
understand the designer's paradigm, and to start out using the software in
the way the originator intended for it to be used. Once I have a good
grasp of this, then I can make informed choices about how *I* want to use
it. If there is no User's Guide or tutorial, I will probably buy a
third-party book and go through it sequentially to learn the software.
On the other hand, to learn a new piece of software that I will be
documenting, I use a somewhat different approach. I start by working
through any existing tutorial material, and then by asking the developer
assigned to work with me to give me a demo of the software and to walk me
through a tour of the major features or subsystems. For really complex
software, such as the software development tools I document at my current
job, I try to take the company's training class as early as possible, to
get a feeling for what the software does, what the component parts are, and
how they fit together.
Once I have this overview sense, I can delve into my part of the product
and explore it enough to understand what it's about and write about it.
And when I have that level of understanding of the technology, I feel
pretty comfortable exploring new pieces added to the software, up to and
including reading the code to find out how this or that design object works
so I can write about how to use it and create credible examples.
I guess what learning both kinds of software has in common for me is that I
do ask a lot of questions, and, at least initially, I rely on documentation
and SMEs to get an overview of what's there and how it's intended to be
used. I especially don't want to find out I've documented something one
way, when that's the opposite of how it should actually be used, even if my
approach seems logical to me.
martha
--
Martha Jane {Kolman | Davidson} mailto:editrix -at- slip -dot- net
"If I am not for myself, who will be for me?
If I am only for myself, what am I?
If not now, when?"
--Hillel, "Mishna, Sayings of the Fathers 1:13"
