RE: Framemaker, Word and Robohelp

Subject: RE: Framemaker, Word and Robohelp
From: "Blaine, Karen L." <karen -dot- blaine -at- unisys -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 17 Jan 2001 12:15:20 -0500

Chuck Martin wrote:
|It distresses me to see, time and time again, that "taking a course" is
seen as a solution to |learning about a software package.

Among the positive aspects of taking "taking a course" is that for a new
product, I can get up to speed a lot faster than I could if I'm exploring on
my own.

One of the most valuable things I get out of a course is the interaction
with other people, who often will be using a product very differently than I
expect to use it. This gives me ideas about how I can use it more
efficiently. From the UI and the documentation, I may understand how to do
something, but a course gives me ideas about how to apply the tool to the
best advantage, how to make it work for me.

|While in some cases it may be needed, training more often is about
explaining how to use what
|should have been obvious, if the software had been designed with its users
in mind.

I find that sometimes the practical use of an option isn't clear because the
option was designed for use in a specific industry, and uses terminology not
commonly used in my industry. Without someone (an instructor) to help me
"make the connection", using these options doesn't make sense, therefore I
avoid them even though they have the potential to make my job easier.

|Using FrameMaker as an example, it is essentially one of many word
processors. Many of the |tasks that users would want to do in FrameMaker,
many of the goals that users would want to |reach, are no different than the
ones that would be there if they were using a different package. |And if
users are reasonably familiar with other packages (as I would hope technical
writers with |any amount of experience would be), then the product design
should be such that it lends itself to |communicating its important and
useful functionality. In addition, the documentation, both the
|online Help and the printed materials, should be easily accessible and
should have clear |information bout how users can reach their goals when
they run into difficulty.
Having made the transition between products a number of times, part of the
transition required is one of accepting the philosophy of the assumptions
made at product design. Often the product was targeted at a particular
industry, then expanded for general use. Understanding product philosophy
often clarifies all kinds of options, methods, and procedures that otherwise
leave you thinking "What a stupid way to do that!" or "Why ever would I WANT
to do that?"

Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17) or 800-646-9989.

Sponsored by DigiPub Solutions Corp, producers of PDF 2001
Conference East, June 4-5, Baltimore/Washington D.C. area. or toll-free 877/278-2131.

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 for more resources and info.

Previous by Author: Re: Learning FrameMaker
Next by Author: Is my RoboHelp Classic Project getting too big?
Previous by Thread: RE: Framemaker, Word and Robohelp
Next by Thread: Re: Framemaker, Word and Robohelp

What this post helpful? Share it with friends and colleagues:

Sponsored Ads