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: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
purchased.
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.
Kevin
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!. http://www.webworks.com/techwr-l
