Re: Planning modular help for software packages

Subject: Re: Planning modular help for software packages
From: "Katie Kearns" <katie -dot- kearns -at- gmail -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Mon, 27 Feb 2006 17:39:10 -0800

On 2/27/06, Tony Markos <ajmarkos -at- yahoo -dot- com> wrote:
>
> Planning for modular help systems is the same as
> planning for modular anything: It is all about
> selecting an analysis technique that results in the
> partitioning of a system into logical and natural
> modules. Discussion of such technique is taboo on this
> listserv.


Er, I think there's more to it than that. There will still be some sort of
interaction between the modules (otherwise they'd just be different
applications, not modules) and dealing with trying to refer to modules that
may (or may not) be there is very challenging.

When I worked on a modular OLH system years ago, we only had links to
modules that we knew would be there -- for example, there was one module
which all the others plugged into, so you knew you had to be able to link to
it, it had to be there. Otherwise you need to program in a lot of
conditional links, and I don't know of any commercial OLH system that has
that functionality built in.

I've done a home-grown help system based on XML that had conditional links
built in, and it was really nice, but a lot of that functionality was made
possible just based on the way the entire product was designed. It was
designed specifically to handle drop-in features, and was client-server
based, so every call to the help system (client accessed the server) could
access the server product's database to see which features the product had
installed/enabled to determine if it should show a link or not. Still, it
was quite a bit of work to mark up all the links and topics to make sure the
right things turned up at the right time (and then test it all!). If I had
it to do again, I would have influenced the engineer to use a different
method for marking everthing up, and counted more on things like
autogenerated related topics links based on metadata, instead of hard-coding
just about everything.

-Katie
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.componentone.com/TECHWRL/DocToHelp2005

---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.


References:
Re: Planning modular help for software packages: From: Suzette Leeming
Re: Planning modular help for software packages: From: Tony Markos

Previous by Author: Re: ABREVE documentation methodologies
Next by Author: Re: Warnings at front of document
Previous by Thread: Re: Planning modular help for software packages
Next by Thread: Re: Planning modular help for software packages


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


Sponsored Ads