Retrieve multiple context-sensitive topics from responsive HTML

[Faeneth]

Hello,

I'm a first time poster and am currently evaluating RoboHelp 2017 for my company. I am completely new to context-sensitive help and this is my first experience with it, but as the only Technical Writer in our company, I am responsible for creating a concept and choosing the right tool for our needs.

We are planning on implementing a context-sensitive help for our newest web application, which should suggest multiple helpful topics to the user of our web application directly within our UI (with links to the fully responsive HTML5 output "Help Center" from RoboHelp).

It would be similar to what Facebook is doing with their context-sensitive help (where, depending on where on Facebook you are, you get different suggested topics directly in the Facebook UI).

Could this somehow be accomplished with the RoboHelp API? Or is it really only possible to call one specific help topic for each context? This would be a huge programming overhead and not really an option for us.

What additional development effort would be needed to build on top of the RoboHelp API to retrieve multiple topics for each context? (e.g. to display the topic titles + links to the respective topic in the Help output)?

Suggestions are highly appreciated.

[Jeff_Coatsworth]

Yes, it's entirely possible - search for "context sensitive help" (CSH) - see Willam's topics on the subject - https://www.wvanweelden.eu/article-category/context-sensitivity 

[Faeneth]

Hello Jeff,

thanks for the answer. Could you be a bit more specific as to where I can find the relevant information for our use case?

I already knew about William van Weelden's excellent article, but I don't get the impression that he covers the issue of retrieving multiple topics for one context.

Thanks

[Jeff_Coatsworth]

Sorry, re-reading your OP reveals that I glommed on to the CSH part too quickly - no, you can't get that effect from RH. What you can do is link specific spots or pages in your application to specific topics in the help (that's the CSH part) when someone presses F1 or clicks on an icon or text link. You can build "See Also:" type mini-TOCs inside the help, but they won't be part of your application.

[Faeneth]

That's unfortunate .

Since it's not really doable for us to change the application code and redeploy our application whenever we add or remove a context-sensitive help topic, I guess RoboHelp is not really an option for us out of the box.

However, maybe our programmers can somehow expand/build upon the RoboHelp API to somehow retrieve multiple final help topics for one context in a convenient way. I'm not giving up hope yet.

If you have any additional input or advice for that, I'd appreciate it.

[Jeff_Coatsworth]

The CSH API only figures out how to grab the specific topic you tell it to find - it doesn't come back with multiple ones. Since it's a web application, wouldn't you already know the specific URL for the topics you would want to offer up on each page? Maybe you can implement your own "home-rolled" CMS system for serving up topics.

[Captiv8r]

From what I've seen of this thread it seems that what you are wanting can easily be accomplished using basic RoboHelp functionality.

One could create topics for "concepts" that are linked to from an application. And within those topics there could be some verbiage explaining why they are there or how they got there and there could be links to suggested topics that are related.

These pages could offer simple links that the RoboHelp author maintains by opening and editing the topic to add or remove any new links. Or, you could employ different tools that are available within RoboHelp. There are things such as RelatedTopics controls, See Also Keywords and Controls. Etc.

It really all depends on the effect you are wanting to achieve.

Cheers... Rick

[Peter Grainge]

I'm not understanding why your app can't call a specific topic. If the user is in a specific screen, then surely there would be a single most relevant help topic as a start point. If the user is not looking for help on the screen they are in, then the combination of the table of contents, the index and search should enable them to find the answer they want.

Instead of the standard search, you could use Zoomsearch with RoboHelp and that could offer titled searches that are limited to specific topics. How is described on my site.

Alternatively, within HTML5 outputs, there is Dynamic Content Filtering that limits the TOC, Index and Search to specific topics. These could be linked to topics relevant to what you describe as contexts.

At the moment I am reading that your user could be in the web app and call the help and you want it to open with various suggested topics. How is the system supposed to know why they have accessed the help?

---

See www.grainge.org for RoboHelp and Authoring information

@petergrainge

[prhmusic2]

Faneneth,

You wrote:

|

Since it's not really doable for us to change the application code and redeploy our application whenever we add or remove a context-sensitive help topic, I guess RoboHelp is not really an option for us out of the box.

|

I would define a context-sensitive help topic as being directly related to something in the UI that the user interacts with.

In my head, the only reason a context-sensitive help topic would be removed is if the UI that the user interacts with has been removed. Like if you had "Apples Maintenance" - that calls a "Apples Maintenance" help topic when you click Help / press F1 - and then had that screen removed from the application. Then I would remove the "Apples Maintenance" help topic.

By extension, removing the functionality would require redeploying the application - to remove that screen - and when the application is redeployed, I would get into the loop of releasing an updated help system - that no longer has any reference to "Apples Maintenance" - at the same time. In that way, you are piggybacking on the application deployment and ensuring the help system matches the system it documents.

That's why I circle back to Peter's point:
"If the user is in a specific screen, then surely there would be a single most relevant help topic as a start point. If the user is not looking for help on the screen they are in, then the combination of the table of contents, the index and search should enable them to find the answer they want."

Rick's suggestion is also a good one. I have gone that route in the past. Under specific circumstances, it can work really well. The lesson I have learned is to keep the focus narrow if you are going to list associated topics in a list you are going to manually maintain. Do not allow that list of topics to grow into a list that mimics the TOC pane, which is hopefully auto-created by dragging folders from the Project Manager to the TOC pane.

Paul