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.
*This message was transferred with a trial version of CommuniGate(r) Pro*
Hi Kevin,
I would keep the two version running for no longer than 3 months.
Kevin, you're about right on time to start making this decision, IMHO.
If you do need longer, I think its possible the team might be dragging their
feet. Set a cutoff date and follow through with it. It sounds harsh but
it'll keep your team moving forward quickly. Good for morale too.
This may also be of interest for tech writers migrating from any authoring
tool or may have to write advisory procedures for software/data migration
projects.
Am on Flare 4.2 which I upgraded from Flare 3.1.
Standardize. If I had Flare v5, and if I was working on a corporate writing
team within my influence, i'd do my level best to standardize the company on
the same tool and on the same new version as soon as possible. This depends
on your own context, type of organization (contracts-based or
products/solutions driven) and number of projects you undertake.
Risk management. To do some risk management, I'd do a short project
migration test of a cross-section sample of older projects (something not
tooo old) and then do a build and project check. I do this so I can document
a short checklist of things I need to fix/do to older projects. Check for
possible compatibility workflow issues with other product versions you have
access to in the Mad suite , say Flare 5 and Capture 4/MadCap Lingo 2 for
example. It doesn't have to take very long. Publish the list to your public
work server.
List and scope projects. Then, I'd plan in a few weeks and list out projects
needing migration. Set a cutoff date. Follow through.
Train. Do a inhouse conversion training session with the team. In training,
use the checklist publicly to guide training so you can detect any errors
with the checklist. Assign 1 team member responsible or yourself to run the
checklist for all identified projects. If I have project owners, I could use
them instead. Update the checklist as necessary, then freeze it.
Finishing up. After the migration project is done, make sure new projects
have the opportunity to take advantage of the new Flare 5 features, as
business needs change.
Gradually, update your in-house project doc guidelines to take advantage of
the new Flare 5 features- rel tables, etc.
Hope this helps.
Daniel
-----Original Message-----
From: McLauchlan, Kevin [mailto:Kevin -dot- McLauchlan -at- safenet-inc -dot- com]
Sent: Friday, July 03, 2009 10:25 PM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Flare 5 users are happy?
I've had Flare 5 installed (and lightly used) for a couple of weeks.
I've still got Flare 4.2 taking up space.
Has anybody encountered any good reasons to want to keep 4.2 around any
longer? A quick look at the Flare forums didn't reveal anything that
particularly scared me.
As a general rule with your tools, if the tool allows two installed versions
of itself to live on your system, how long do you keep a previous version
actively available on your computer, before deciding to trust the current
version and retire the previous?
- Kevin
The information contained in this electronic mail transmission may be
privileged and confidential, and therefore, protected from disclosure. If
you have received this communication in error, please notify us immediately
by replying to this message and deleting it from your computer without
copying or disclosing it.
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
