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: Enterprise software - reorganizing the help From:"Patrick and Jenny" <pat_jen -at- hotmail -dot- com> To:"Richard Lewis" <tech44writer -at- yahoo -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Mon, 15 Oct 2007 09:57:59 -0700
Hi Richard
Good point. We do use flow charts to document business procedures, and find that keeping them to a single 8.5 x 11 inch size is best. These are most helpful for training new users.
How do you deliver your data flow diagrams - pdf, some sort of online help, printed documents?
Jenny.
----- Original Message -----
From: Richard Lewis
To: Patrick and Jenny ; techwr-l -at- lists -dot- techwr-l -dot- com
Sent: Monday, October 15, 2007 9:06 AM
Subject: Re: Enterprise software - reorganizing the help
Hi:
I lead larger-scale enterprise integration efforts at a large company by documenting As-Is (and some To-Be) situations. Ninty-eight percent (98%) of what I do is come up with a comprehensive, integrated understanding of essential functionality and, especially, a understanding of the interrelationships between these functions.
I use data flow diagrams because:
* Only DFD's focus on the interrelationships between functions.
* Only with DFD's can one document a whole bunch of software in parent-child relationship diagrams of about 8 1/2 by 11 in size. This is key to maintainability. If you have larger diagrams, trying to update them in rapidly changing environments becomes too hard.
Patrick and Jenny <pat_jen -at- hotmail -dot- com> wrote:
Hi
I'm interested in talking with people who document large enterprise software
systems.
We want to reorganize our help system so that it is easier to find info and
simpler to update. Currently we have three types of documentation: End-user
procedures (available from the Help menu in the app), Setup Guide (a
standalone chm), and Release Notes (a standalone chm). We also have printed
reference guides with technical information on advanced procedures and
setup, and details of all the screens including background calculations.
We have three different audiences - end-users, their support staff, and our
own high-level support group.
So, I'm wondering where to go from here. There are frequent updates to the
software (every 2 or 3 weeks), so whatever we decide to do, needs to be easy
to update.
Any suggestions? Anyone in a similar situation? How should we organize all
this information?
Thanks, Jenny.
------------------------------------------------------------------------------
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-