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