Skip to main content
shootathought
shootathought
Inspiring
November 6, 2007
Question

Help for User Permission Level Context Sensitive Help

  • November 6, 2007
  • 2 replies
  • 928 views
Hi, all!

I'm charged with changing the way that we use RoboHelp and call to the help files from our web-based application, and am having a difficult time trying to find any information on how to do this (I have very little coding background!). I'm hoping someone here will know how to help me!

The UI designers want help for a new system to appear differently based on the way the user is logged in: Internal User, Administrator (Client), User (Client). They also want help to open in a pop-up window using AJAX or javascript to call the help file, identify the user-level, and retrieve the appropriate text. The closest thing I've found researching this involves a database ( http://www.codeproject.com/winhelp/RoboHelp_X5_Web_CHM.asp).

My thoughts say there needs to be some sort of code in the html of the topic to identify different users for different text, kind of like this:

<Internal_User>
<Admin_User>
<User>
text
text
</User>
text
text
</Admin_User>
more text
</Internal_User>

So, my first question is: Is this possible at all? If so, how would the developers call, do I need to use mapIDs? How can I make the TOC change based on the user log in credentials?

The other things that worry me are: What if I need a particular user to be able to see help in several areas of one topic? Can I force an application to look through the entire topic for each tag before generating the help? Do I need to use a database?

Well, you get the point. There are a ton of questions that I can build on, but I'll wait for the "Can I do this?" answer and add more later! :)

Thanks in advance for any responses!
    This topic has been closed for replies.

    2 replies

    A
    Anonymous
    November 7, 2007
    Which of Leon's two possibilities you go for would probably depend on whether you want one user type to be able to see the help for other user types. The first (merged project) would make all content available to all users. The second would provide help content appropriate only for the user type the developers specify, which is the better option if you have sensitive or restricted information in some help topics that not everyone should see.

    In case it helps, I can describe how we have implemented help for multiple logins in a few projects. I use conditional build tags to specify what goes in each version of the help system depending on the user type that is supposed to see that version. I run the output to parallel directories. The developers coded the Java to display the help that corresponds to the user's role. When a user click the Help link, the Java looks at the role (and in a couple of projects, the users's selected display language) and goes to the appropriate directory to open the help. Personally, I use map IDs because the developers simply put the same JavaScript strings in every page and then change just the ID so the correct topic is called. It works smoothly for us.

    --Ben
    L
    littlestarkeeper
    Participant
    June 24, 2011

    OK, I need to do the exact same thing as the original requester--create context-sensitive help for users who log in as different role types--i.e., reader, contributor, editor, administrator, etc. The difference is that we are using HTMLHelp rather than WebHelp. In our current system (in which all user types see all context-sensitive help for all of the user types), IDs are mapped to bookmarked sections within topics rather than to entire topics. What is the simplest way for the next iteration of our product to change the help system so that users only see the context-sensitive help for their own user type? Right now, for example, for a "submitting a report" screen, we have context sensitive help on the data fields on that screen and for each field, the code calls the map ID to jump to the field- specific info for that field. However, the user can scroll through the whole help topic (since the script is mapped to sections of a particular large topic with multiple bookmarked entries, each with a separate map ID) and view the info for data fields that other user types only see in their view of the application.

    For the next iteration of our product, what do I need to do to write the help files and how do I need to coordinate with the programmers who are creating the map files to restrict views of context-sensitive help to only the help for data fields and other functionality available to users of a particular user type?

    Peter Grainge
    Community Expert
    Peter GraingeCommunity Expert
    Community Expert
    June 28, 2011

    I think you will need to generate different CHMs for different users and leave the developers to call the required file.

    AIR help would enable you to have a dropdown with each user type and the user could then pick their section. Not quite what you want but an option. There is information about AIR help on my site. The dropdown for the user types is what is known as DUCC, dynamic user-centric help.

    That is a RoboHelp 9 feature described in the RoboHelp Tour on my site. You haven't said what version you are using.

    See www.grainge.org for RoboHelp and Authoring tips

    @petergrainge

    Use the menu (bottom right) to mark the Best Answer or Highlight particularly useful replies. Found the answer elsewhere? Share it here.
    MergeThis
    MergeThis
    Inspiring
    November 7, 2007
    1. There's very little you should be doing here, as the help author, beyond delivering the help output. It's up to the developers to configure user privileges, open help in specific formats, etc.

    2. Forms (and their controls) in a web application only need to call the topic/bookmark URL; no map ids are needed. That is, AcctMainFrm would call the AcctMainFrm.htm topic. However, if you wanted to name the topics differently, such as accounts_main_window.htm, then you'd need some form of alias file.

    3. Don't let the example you've found cloud your judgment on making decisions for your environment, As I see it, their mission statement is really not similar to yours: they wanted dynamically-driven WebHelp AND HtmlHelp; you seem to want WebHelp only, but accessible by login privileges.

    Your involvement will probably be either of these:

    * Create a merged WebHelp project with the child projects containing user-specific information.
    * Create multiple WebHelp layouts (merged or not), which would each be placed within specific directories and restricted by logins.

    As to the help "...open[ing] in a pop-up window using AJAX or javascript to call the help file, identify[ing] the user-level, and retriev[ing] the appropriate text," that's on the developers, not you.


    Good luck,
    Leon
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices