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.
Poorni Aravindan Kumar reports: <<We are releasing two products. Product A
is the main product and Product B is bundled with the Product A. Product A
will have two patch releases, but Product B will just be the same. Both
Product A and B have separate Release Notes. The product dependencies and
support are different for each of Product A patches. In the Product B's
Release Notes, I've a note quoting: "Product B's software and product
dependencies are specific to the Product A patch it supports (is bundled
with). Its hardware, software, and product requirements are dependent on the
Product A requirements. For information on Product A's hardware and software
requirements, see Product A's Release Notes." Does the above note convey
the required information?>>
It seems to me that a better solution would be to produce a single set of
release notes that includes all the possibilities you listed; that way,
readers don't have to go searching for Product A's notes. Moreover, this
would let you produce optimal documentation because you'd be presenting all
the necessary information in one place, well integrated, rather than forcing
readers to compile information from two separate sources. This might look
like the following:
Product A (general)
Patch 1 for Product A
- details
- implications for Product B
Patch 2 for Product A
- details
- implications for Product B
Product B (general)
Alternatively, you could move the implications for product B under Product
B, producing the following structure:
Product B
- generalities
- implications of Patch 1 for product A
- implications of Patch 2 for product A
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Save $600: Create great-looking Help files and software demos with
RoboHelp Deluxe. Get RoboHelp and RoboDemo - our new demo software - for one
low price. OR Save $100 on RoboHelp Office in June with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
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.
