Web Help based on user, is it possible?

[awargo]

My company would like to pick and choose what pages are displayed depending on the user that logs on to our online system. Is there a way to do that with Flare? So basically, whatever the login used is will determine what pages are shown. Thanks!

[RamonS]

Take a look at this thread...
http://forums.madcapsoftware.com/viewto ... =13&t=8338

[awargo]

So if I read it correctly, we would need to create a help file for each possible outcome? I am still confused at how we can have the correct combination of content come up based on the user's login. From what I got in speaking with the developer it may have something to do with the API.

[doc_guy]

Yeah. Essentially you have to create a separate help system depending on the user role. So you might have an admin help system, a developer help system, and an analyst help system.

Then when the user logs in, your developers would have to add some code to the help call (when the user clicks on the help button in the system) to check what the user's role is, and then point them to the help system that is targeted for their role.

There is no way for Flare to know what roles you have in your system, nor for Flare to know what pages to deploy depending on a user role. I don't know of any help authoring tool that can do that.

[awargo]

Thanks! I will let everyone here know that we can do it, just not the way we thought. I appreciate your help.

[doc_guy]

On your end, the single sourcing aspect is done with conditional tags at either the topic level (or even more granularly at the paragraph/sentence/character level; however, I suspect from your previous statements that this will be most useful to you at the topic level).

You will first create a condition tag set in the Project Organizer where you will add a condition for each different output you want to create. In the example I gave above, you'd create three conditions in the new condition tag set: admin, developer, and analyst. Save the condition tag set.

You will right-click on the topic in the content explorer, and go to Properties. There you will go to the Conditions tab, and you will click the include box or the exclude box, based on whether you want the topic included in a given output, or excluded from a given output.

Then you will create three targets. In each of the targets, you'll select a different condition to include, and exclude the others.

That will give you three help systems, one for each of the user types in your system.

That is a pretty high-level overview. Hope it helps. Let us know if you have any more questions, or if you run into a snag while doing it.

[RamonS]

I came across that issue some time ago and put in a feature request with MapCap. The way I think it could work is to create a help system that contains everything and a set of conditions that work like the conditional tags, but are applied at runtime, not during compile. One still has to define the conditions and tag the content accordingly, but it would result into one help system with e.g. 20 runtime conditions rather than 20 different targets, which likely contain a lot of the same stuff.
I think that would be a compromise as it limits the number of constellations possible and the compiler may do some of the work beforehand by cleverly chunking content (for example the parts that are included under every condition would be a chunk) and precompiling portions. The conditions will then be combined into condition sets having one or more conditions and an associated name so that for each help call an additional string is passed that specifies the condition set. That will only work with WebHelp running on a server or DotNetHelp with the viewer being the application doing the processing.
True dynamic help still needs to follow rules and compiling ToC, Index, Glossary, and Search at runtime and anew for each help call would require either insane amounts of processing capacity or insane amounts of time. So rather than having the flexibility of a grain mill, wheat and rye fields plus a veggie garden the more realistic approach is to go for frozen pizza. Still needs some preparations, but it is not done from scratch.

Damn, me and my analogies, now I'm hungry.

[doc_guy]

You lost me with that last bit.

I think that what you're describing would be a good fit in a WebHelp plus type target, which does require a server setup. Because what you are talking would require a bit of programmatic wizardry to get it to function. And unless you encrypt the files, you still have the problem that you're providing a bunch of content files that in some cases you might not want users to have access to (if they get a direct URL, for example). I dunno. You could work around it, but it seems like it would be cumbersome.

[RamonS]

Of course you need processing. My point is that if you give free reign and allow any combination at any time things such as ToC, Index, Glossary, and Search need to be compiled on the fly for each and every help call, which by the way would need to include quite some extreme definition to explicitly specify which content is to be included or not. That is not impossible, but it would take potentially minutes for a help call to receive the desired outcome. Preparing chunks of these things will drastically reduce the processing needed and limit it to puzzling the pieces together. But for that to work one has to define the pieces beforehand, which should not be an issue. I only once came across an application where the security was so detailed that it was possible to turn individual fields on or off for a user - and that pp had thousands of fields. It was insane.