Creating one help system for user groups with different access ri ghts?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Rasil Ahuja wonders: <<I am creating help using RoboHelp for a web
application that, based on your login, displays different menu options. For
example, Company A bought our product with X features. Company B, on the
other hand, bought the
product with Features X and Y. I would prefer to not create a generic help
system that covers ALL features because it might be confusing to those users
who will not have access to nor see those features.>>

If your help is context-sensitive (and it should be), workers for a company
who didn't buy feature X will never ever see the help for feature X. Don't
forget, they only consult the help when they experience a problem (e.g.,
want to learn how to do something), and if they're not using a feature,
they'll never look for help on that feature. The only risk is that if they
cruise the index because they're bored and can't find what they're looking
for, they may encounter the index keywords for feature X. If they do, they
may see the help for that feature and discover they can't use it.

That's one bonus to including all topics. Let's say (hypothetically) they do
spot feature X and discover it's not installed. They can then serve as
advocates for _your_ company by persuading their employer to purchase
feature X. All you need to do is include a note at the top of the help
topics for any optional feature (those outside the core set that everyone
must buy) saying something like: "If you don't see this on the menu, it's
because your company didn't buy it. If you want to accomplish this task
using the features you did buy, see the help topics on..." The second
sentence cross-references to informatoin on other ways to accomplish a
task--assuming that it can be accomplished at all; if not, delete it.

<<But outside of creating separate help systems for each type of login
group, I don't see how I can address this issue.>>

One way is to create a single master help document in Word, and a separate
normal Word document that contains the complete list of features plus which
help topics go with each feature. When someone orders a specific set of
features, you manually step through the master help file and delete any
irrelevant topics, then save the file under a new name (e.g., Features
ABC.doc). Compile that and away you go. Clumsy and perhaps inefficient, but
it works just fine. Of course, you'll have to design cross-references
carefully so that they don't go to dead ends, but you should be testing all
links anyway before you ship a help file.

<<Creating multiple help projects for each login group will create a huge
update issue as the number of clients increase because most of the help
pages will still apply to all users.>>

Another good reason to stick with my first suggestion. But presumably there
are conditional compilation techniques you can use in RoboHelp that let you
spec individual topics to include when you compile. I believe you can do
this through the section of the project file that tells the compiler which
topics to include when it generates a help file. I'll leave it to the real
RoboExperts to tell you how to do that.

--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada 

"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."--Bjarne Stronstrup (originator of C++ programming language)


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Help Authoring Seminar 2003, coming soon to a city near you! Attend this
educational and affordable one-day seminar covering existing and emerging
trends in Help authoring technology. See http://www.ehelp.com/techwr-l2.

A new book on Single Sourcing has been released by William Andrew
Publishing: _Single Sourcing: Building Modular Documentation_
is now available at: http://www.williamandrew.com/titles/1491.html.

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.