re: Thinking patterns (sequential vs. other instructions)?

["Christensen, Kent" <lkchris -at- sandia -dot- gov>]

Monday, Geoff Hart provided a nice response on this topic and some useful
new direction for the thread, and I'll add some thoughts inspired by that.

First of all Geoff, seemingly really diplomatically, notes ...

"Most of what techwhirlers document is sequential because many of the tasks
our audience perform are sequential at their bottom level, and it's natural
for us to be most skillful at doing something you do frequently."

Well, I'd be less diplomatic and counter the observation of tech writers
with the observation that that observation is much like observing that
"Tiger Woods, as an individual, is really good at golf."  That is, I'd
respond to John's project supervisor, "what's your point?"

Geoff then goes on to relate ...

"... many tasks are not purely sequential; there are branches, decision
points, alternative ways to accomplish something, options within any given
approach, and so on.  Since we do this less often, we're less good at doing
it. Moreover, this borders on instructional design, which is another area of
expertise that many of us never study."

... to which I'd comment that, indeed successful or at least senior level
technical writing is certainly a form of instruction, and knowledge of
instructional design seems inherent.  Also possible here is just good
indexing that helps the user successfully jump around the manual and find
the subplots that he or she wants next in the user's own chosen order.

Geoff writes of "failure to provide the higher-level information that helps
readers
understand the various procedures that make up a task," and I'd offer that
is surely the point and probably the basis of the original observation.
This is where it gets difficult, however, since, as I noted here recently,
the world is full of prerequisites and the question is how many do you teach
(or even just list) in the manual at hand?

There is undoubtedly desire for immediate gratification, and many of our
readers want mainly to know how and not why.  And, we can certainly simplify
our background setting or our tutorials by presenting them as lists of
frequently asked questions, but some could see that as "dumbing down" or,
yes, "sequential," but most times I'd reject that view.

As a writer, I'm certainly more comfortable knowing as much as I can about
the product I'm documenting, but I really can't then just simply assume all
my readers need to know (or want to know) all I know to successfully operate
or use the product.  Engineers or programmers could be even worse about
this.  All this, however, seems pretty near the spot where the writer
succeeds or fails, and maybe those writers who have the advantage of knowing
specifically who their customers are and those writers who have customers
somehow required to have the prerequisites have it easiest, but none of it
is easy and that's why we (should) make the big bucks.  And lots of times we
have to know when (better yet, why) to present just some of it and not all
of it ... but somewhere some steps for sure.



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** 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

Sponsored by Cub Lea, specialist in low-cost outsourced development
and documentation. Overload and time-sensitive jobs at exceptional
rates. Unique free gifts for all visitors to http://www.cublea.com

---
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.