Developing WebHelp for Different App. Scenarios

Question

We are developing WebHelp projects for several of our
Web-based applications. One of our applications has a unique set
up, and I am not certain how to approach creating the Help system.
The application, "Simple", has a menu that allows users to
access another application "Simon", if they have opted for such a
configuration. Basically, the user would have to purchase both
Simple and Simon. In this scenario, the Simple WebHelp would only
contain a subset of topics from the Simon WebHelp. There are cases,
however, where customers would only be using Simon, and would not
have access to Simple, unless they upgrade.
For the Simon application, users need to have access to that
Help, exclusively.
One option is to develop separate WebHelp: A complete system
for Simple and a complete system for Simon. For the Simple/Simon
application combination, maybe we could use conditional build tags
for the relevant, imported Simon topics. But then, we would have
duplicate data. How do we account for the Simple/Simon scenario?
For a software upgrade from Simple to include access to Simon, how
to we create the Help so that both Help contents are addressed (so
that there is some "trigger" that knows an upgrade has happened and
the correct Help displays). Can we have one merged Help system that
can have conditional tags for: Simple Help only, Simon Help only,
and Simple with a subset of Simon topics only, and that this one
Help file can be attached to the application, and when there is an
upgrade, the appropriate Help will display? If so, what is the
recommended approach for this? THANK YOU FOR YOUR HELP!

Answer 1

Just FYI: I work with a project very similar to the scenario
you describe. All of our subscribers use our software to collect
and store data. All of them also have access to a subscriber-only
website. Some of the subscribers use desktop-based software and a
SQL database to store data; others use Internet-based software and
our servers to store data. The Internet-based software is housed
within the subscriber-only website. So all users can access the
website, but the Internet-based users have access to a wider range
of options.
Accordingly, the Help project for the subscriber-only website
has four conditional build tags:
1. Internet-only
2. Desktop-only
3. Print
4. Online
The Desktop-only and Print tags are used at the content level
(i.e., to mark text within a topic); the Internet-only and Online
tags are used at both the content and topic levels. This allows me
to produce four seamless outputs:
1. Printed documentation for desktop users (excludes
Internet-only and Online)
2. Printed documentation for Internet users (excludes
Desktop-only and Online)
3. WebPro output for desktop users (excludes Internet-only
and Print)
4. WebPro output for Internet users (excludes Desktop-only
and Print)
The WebPro outputs are published to an instance of
RoboEngine; each contains a link to the appropriate printed
document. The subscriber-only website picks up on the user's
software type at login, and the link to the Help system changes
appropriately. (Note that I didn't have anything to do with that; I
simply explained the situation to our Web developer, and he made
the necessary coding changes.)
The bulk of the work involves setting up the build tags and
outputs and thinking about how you need to approach your content.
Ultimately, however, the tags provide a lot of flexibility without
the need for duplication.