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: Re: FrameMaker Required From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Sun, 17 Mar 1996 17:50:00 EST
At 03:16 PM 3/17/96 EST, you wrote:
>On 3-14-96 Robert Plamondon wrote:
>>> My experience is that few people read manuals until
>>> they are completely stuck. If they can muddle along,
>>> they are content. Thus, one can become an instant
>>> expert by plowing through the manual set.
>For the record, I have never *plowed through* a manual or manual set
>in my life. I'm a voracious reader, but I read books that describe
>processes conceptually. I know what tasks an application pkg should
>perform. If the how-to is not obvious from the interface, then I go
>to the book. This approach works for me. Furthermore and as a
>result of this approach, I consider myself an expert on a handful
>of tools. I do not muddle along, unless I am using a tool so
>infrequently that learning it is just not worth the bother (for
>example, some Norton utilities).
Me too, Joyce. I have to confess that I almost always dive into a package,
then use the manual when I can't intuit my way out of a box. I know most of
my users work that way, too, unless they're having formal training. I like
working with live files to get my bearings. I work through the live ones,
learning how the original creator did things. It's inefficient as hell, but
I can't bring myself to sit and march through a manual.