RE: Planning modular help for software packages

Subject: RE: Planning modular help for software packages
From: mlist -at- safenet-inc -dot- com
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Mon, 27 Feb 2006 17:03:17 -0500

Suzette Leeming [mailto:suzette -dot- leeming -at- gmail -dot- com]
> In our Accounting module, we used a bit of code to tell the
> system to check
> the system parameters to see if General Ledger is authorized
> (which would
> mean they purchased the Accounting module). If not, then help
> opens the help
> for the Accounting Interface.
> Desktop Tools is not really a module, but affects all parts
> of our system,
> therefore I included that help in each of the other modules.
> I'm using Help
> and Manual and it allows me to include other help files. When
> compiled, they
> present as one help file.

Our Help is not compiled (we provide WebHelp) and is standalone.
As well, we use RoboHelp, in which it's rather fiddly to get
sub-projects to come together and produce a "global" ToC.

So far, it's simpler to just give the customers everything in
the Help and tell 'em that if they haven't got a certain
function, then either it's not switched on, or it wasn't

Also, the functions that can be bought separately are not
well-delineated chunks that would all come under their
own headings. Instead, several of them are enhanced aspects
of functions that everybody gets. A more, um, dispersed form
of modular than the other posters are talking about.

As an example of functionality that the user can switch
on or off, our hardware supports a long list of cryptographic
algorithms. Those algorithms are used all over the place in
our interface and in customers' integrated use of our product.
Now, the FIPS 140-2 standard was specified around a certain
core of algorithms... they had to draw the line somewhere,
and some algorithms were limited-use or specialty items, while
others were the product of "dang furriners" and so were
legitimately left out. Many big corporations
and institutions need to operate under that standard. For them,
we allow the switching off of all of our algorithms that the
FIPS people didn't test. Other customers need those other
non-FIPS-approved algorithms, and don't really need to run
a FIPS-compliant shop. For them, we allow to switch on all of
the non-FIPS algorithms.

As an example of a functionality that the user cannot
switch on or off - they have to buy our product configured
one way or the other - we have the option to authenticate
to the product via a typed password, or via a much more
stringent physical-token-and-trusted-path two-factor method.
But you pick one or the other when you buy, and you can't
go back... at least not with all your data intact.
The basics of how that works can be talked about in a
fairly self-contained few pages, but the use of it -- the
special effect on this or that operation -- gets mentioned
all over the place, specific to each operation.

For either of those example situations (there are more)
it is possible to just have generic explanations of many
operations, with simple links out to separate pages,
depending on which config/setting you have on your system.
But it doesn't work everywhere, and it gets too cumbersome
to be doing "if/then" and either/or by means of drop-down text
or expanding text... and what about those poor few with the
browser options switched off, who must view all the
drop-down/expanding text always expanded?

There's modularity and there's modularity.
Perhaps what we call installable modules are more
accurately installable overlays. Hmm. Not even.


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.

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

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at

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

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 for more resources and info.

Previous by Author: RE: Planning modular help for software packages
Next by Author: RE: Planning modular help for software packages
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