This content has been marked as final. Show 2 replies
If you're contemplating a server-based help system I assume that the application it's documenting is also server-based. Therefore...why would end users not be connected to a server for viewing the help?
If needed, they (or their IT peeps) can copy the entire WebHelp help project onto their machines, but they'll have to deal with the storage and memory issues, as well as the security barriers that browsers might throw at them. Of course, that would also negate any context-sensitive links you might have provided in the app, wouldn't it?
Hi SSEL and welcome to our community (Waves at Leon too!)
For what it's worth, I once constructed such a beast. Please allow me to explain.
I was an intranet web developer. I managed sites for several departments within a company division. One of those sites was for a Field Services department. I had a WebHelp output called the "EQRM" used for their "Electronic Quick Reference Manual". This was their "bible" of sorts. As you might imagine, this worked fine as long as they were connected to the company intranet. But they made service calls. During these calls, they did not have access to the intranet, yet still needed access to the information. What to do?
I simply created a compiled .CHM version of the WebHelp system. Then made sure to create a page in the WebHelp system that allowed them to click a link and download the .CHM to their support laptops for "offline viewing".
While this worked dandy in my situation, the information wasn't used as a traditional help system. Instead, it was used as an application within its own right. So as Leon said, if you are linking this to an application, things might be dicey.