Modular or not modular?

Subject: Modular or not modular?
From: Rantamäki Annu <annu -dot- rantamaki -at- dosetek -dot- varian -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 26 Sep 2002 16:34:38 +0300


Hi all,

We have two competing views about how to develop our help system, and as I'm a beginner in the realm of online help systems, I would like to hear your expert opinions and would be grateful for any advice.

Our environment:
Our product is a Windows software suite consisting of a range of applications developed at two locations in two countries. One installation of the software may contain all or some of the applications, and one of the applications is always part of the installation. In addition, a basic set of functionalities are shared by all applications. We have writers working on the same HTML help project, also at two locations in two different countries. I work alone at my location, and the other location has outsourced to work to a company with 2-5 people working on our project. The contractors have planned the entire help project. I'm an employee of the customer, however, cannot make decisions (nor easily influence others) about the entire help project.

To put it short, View 1 is to build a modular system consisting of one master .chm and about 6 sub-chms, View 2 is to build one big .chm with everything in it. We use FrameMaker 6 and Robohelp HTML 2002.

View 1:
Create several smaller RH projects and compile several .chms which will be linked to a master .chm. Smaller RH projects are quicker to compile, and updates do not require compiling the entire project. This is good in new releases where part of the applications in the suite are upgraded, and the rest stay as they are. Small updated .chms can be easily sent to our customers. Writers at both locations can be working on their own .chm without the need of using the same shared HTML source.

View 2:
The modularity of the system lies in the information in the RH project being grouped and tagged according to the applications. The modules are represented by the HTML files in folders which are all included in the same RH project. Because the linking between the modules is complex in some cases, the modules are be kept in one RH project. Subsets of information from the project can be compiled with build expressions. HTML files are easy to update. After updates, a new build is made of the entire system, and the customer can be provided with updated information by having them copy the updated help file into the appropriate directory.

The question is, what are the pros and cons of these two ways to approach this issue? Is there anything that could be said to be a major advantage/disadvantage? The help system will be localized into a few languages - do you see any problems looming in this regard?

I hope I have explained the situation understandably and provided sufficient information for you. Thanks for any comments.

Annu


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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

Enhance, optimize and automate your FrameMaker-to-PDF workflow with TimeSavers:
Define all PDF features in your source FrameMaker files ONCE, distill MANY.
Bookmark Controller, Link Controller, UnBloat & more : http://www.microtype.com

---
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.



Next by Author: RE: what's the world coming to
Previous by Thread: RE: FW: Tables "tied" to section breaks - FIXED!!
Next by Thread: how to shrink multi-page xl spreadsheet


What this post helpful? Share it with friends and colleagues:


Sponsored Ads