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.
Re: Documenting the way software actually works WAS: Try selling the sizzle of what you do.
Subject:Re: Documenting the way software actually works WAS: Try selling the sizzle of what you do. From:jenny_berger -at- fairfieldresidential -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 17 Feb 2003 08:44:53 -0600
Way TOO simple an answer for me.
The answer to this question here is: Well, is it in the bug tracking
system? Will it be fixed before the release? If it isn't fixed, have we
put it in the Known issues section of the Release Notes?
If these are true, then document it the way it's supposed to work.
At many smaller companies, the documentation is also the functional
specification.
=======================================================
I have trouble accepting this mainly because users, from my experience,
don't really care how something is "supposed" to work. If they're reading
the doc at all, they want to know how the software *actually* works so
they can *actually* do what they need to do with it. To follow this line
of thinking, I could say in the docs that the product can make julienned
carrots and cut through metal like so much butter, even though it doesn't
*actually* do that. Rude surprise to the user if he tries to make the
product do what I claim it's supposed to do, doncha think? My question
would be, do we really want to risk ill will by telling users one thing
when the truth is something, oftentimes, completely different?
As for the release notes, I've yet to meet an end-user who wasn't a
developer or manager who read them for supplementary information. I'm not
saying release notes are unnecessary, but if the end-user isn't reading
the manual (or even only scans it in an emergency) you can bet they're
not reading the release notes.
As for functional specs doubling as end-user docs (I'm presuming), I've
found these actually create more questions than they answer for end-users.
Granted, it can be more efficient to repurpose content, but in this case I
don't believe it's effective.
Jenny Berger
Technical Writer
Information Systems
Fairfield Residential
Buy or upgrade to RoboHelp X3 today and receive the WebHelp
Merge Module for FREE ($299 value). RoboHelp X3's all-new
features include conditional text, completely re-engineered
printed documentation output, Context-sensitive Help Toolkit,
single-source layouts, and more!
Order online today at http://www.ehelp.com/techwr-l
---
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.
