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: Business issues, documentation and editors From:Jim Shaeffer <jims -at- spsi -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 10 Jan 2002 16:48:35 -0500
I had been thinking about similar points raised in other
posts.
I used to tell some of my computer classes that I was just
doing toolbox training. I had time to train them on the tools
found in the word processor or spreadsheet but not to address
how to structure a complex document.
If I document how to use each of the tools in a carpenter's
toolbox, I have _not_ documented how to build a house. But, in
the case of a generalized tool (like a word processor), I cannot
predict whether the user is building a house, a cabinet or a
pedestal for a statue.
In the case of the users of the software I document, many business
processes that would provide context are considered proprietary
information. Such business process differences are used by our
customers to differentiate themselves (our customers compete with
one another). (Sometimes makes for interesting User Conferences.)
I struggle to work around the apparent dilemmas.
Also, thanks to Steven Brown for asking some good questions.
His post arrived as I was finishing this one.
Jim Shaeffer (jims -at- spsi -dot- com)
> -----Original Message-----
> From: Jean Weber [mailto:jean -at- wrevenge -dot- com -dot- au]
> One of my biggest complaints about a lot of software
> documentation is that it tells me *how* to do something
> but doesn't give me a clue *why* I might want to, or what
> it's for. The assumption seems to be that the reader wants
> to do X but doesn't know how. I think that's often an
> incorrect assumption; sometimes it never occurs to me that
> X was a possibility -- I didn't know enough to even ask the
> question.
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of
your book. What are you waiting for? http://www.iuniverse.com/media/techwr
---
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.