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.
> She suggests the following:
>
> 1. "Create the new Adobe structure and layout of the admin
> 2. "As we work on CRs that have impact to the admin manual, you can
> include hours to update the manual when you are working on the CR. The
> This is all well and good, but what I created doesn't match the old
> manual.
So make your stuff match the old manual. If the choice is A. use your style
on the updates and then try to update the rest of the old manual to relect
your style, or B. use the existing style on the updates and leave the rest
of it alone, and you've been told to work on priorities, then probably
option B is the right choice. Create a solution (even if it's somewhat
flawed.) This is better than creating a problem and NO solution.
> The change manager doesn't understand that new
> information added to just a small part of the old manual will just be
that: an
> old manual that no one will use, since most of the info is not true
anymore.
Suggestion: confine your updates to an appendix which can easily be
separated from the portion of the manual that is old. Thus it's easy to
pull this piece out and your updates aren't lost among a lot of outdated
material. If you're granted the time and resources, later on incorporate
the updates from the appendix into the document body.
> My style of writing manuals, is to talk with all relevant
> people (admin manager, admin themselves, SME's) and to come up with a
> coherent, working document.
Different problems call for different styles. If I can quote Sun Tzu, "Do
not repeat the tactics which have gained you one victory, but let your
methods be regulated by the infinite variety of circumstances." You may
need to work differently this time.
> I am always told to "add this to the manual," but
> where? how? There is no place at the moment.
It may be different in your workplace, but this is exactly the type of
challenge my company pays me to figure out. I think answering this question
is mostly the responsibility of the technical writer.
> She's also having a requirements person write requirements
> for an addition to the "manual!" Isn't requirements usually written for
> software, or do people write formal requirements for info added to a
manual?
You may be in a situation where what you percieve to be "end user
documentation" is really something else. Figure out if this is the case.
Be pro-active. Just because someone tells you what they want you to write
is "documentation," it doesn't necessarily mean this is actually true. You
may be being asked to actually write a process document or a design spec.
Chris Grant
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Acrobat & FrameMaker Seminars: PDF Best Practices, FrameMaker-to-Acrobat
Advanced Techniques, FM Template Design, Single Sourcing with FrameMaker
in Brussels (Oct), and in Montreal & Dallas (Dec): http://www.microtype.com/1
Experience RoboHelp X3! This new RoboHelp release combines single sourcing,
print-quality documentation, conditional text and much more, into the most
monumental release of RoboHelp ever! 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.
