Inspiring

Question

Best/Easiest Practice for Distribution of Webhelp files for Fat(ish) Client Application

Forum|Forum|11 years ago
October 28, 2014
3 replies
1223 views

So another in my long line of questions in trying to change the implementation of the help systems at my new employer.

So, the pressure is to convince the existing guard to toss out the old method and go with a new method... One of the issues has come up for CSH Webhelp (via RH10)...

Apparently, in the old method (where every help topic was it's own CHM - no, I'm not kidding). They kept it that way so that any time a help file was updated, they could just send out that one chm to update that one topic.

Now they are worried that if we switch to webhelp using topics in one single big project that we can't just send out a single updated file any more...

So I'm trying to get ammunition as to how updates to the help can be distributed without it being a big hassle...

We do have small updates that go out about every week, and they are afraid that going to the webhelp (1 project with lots of topics) method will require more time and effort for the techs because they will have to complete the update of a huge help system every time.

One solution we have suggested is that we only update help files on major releases and add any changes to help procedures in the Release Notes or in a separate PDF and also include a note that the help files "will be updated to reflect this change in the XX/2015 XYZ Release).

Does ANYONE have any other ideas of how distribution could be done efficiently so that we don't have to continue this "project per topic" fiasco?

HELP!!! PLEASE!!!!

WebHelp

This topic has been closed for replies.

K

ktbFLAuthor

Inspiring

Thanks Peter, so far we think we have a plan for the issues about which we were concerned. Thanks for your input!

Peter Grainge

Community Expert

Can you not host the help on your own web servers so that there is no download? Obviously users have to have web access.

You could supplement that with something local that the system switches to when there is no connection. That would not have to be so up to date as long as users are made aware of that.

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.

RoboColum_n_

Legend

We do something similar to what Peter suggests. It may not be practical for you though. Our applications are server based and installed on the client's own server. We host online help on our own server, so as Peter suggests users need internet access. A small number of users do not, so we install an offline version of the help files on their application server. The help file call automatically routes to the online help on our server, but if that times out for whatever reason the offline help on the client's application server is called. This works with CSH calls also.

The only issue is that we decided not to update the offline help on the client's application server between releases. It was too much hassle for the client and us. With the online help hosted on our server we (the Technical Writers) can update it at anytime with no involvement from anyone else. It is only if the path changes (e.g. a new product release) that the developers need to do anything.

K

ktbFLAuthor

Inspiring

Thanks so much for the additional info about your process, RoboColum(n) - I

am adding that to my responses for my boss and I to use during our meeting

on this today!

On Wed, Oct 29, 2014 at 4:31 AM, RoboColum(n) <forums_noreply@adobe.com>

Jeff_Coatsworth

Community Expert

We package our WebHelp files in two different ways here at my company – they both involve the installation tool we use to create self-extracting executables (this one happens to come from Wise Installation Systems, but there are lots of other tools out there). One division doesn’t trust it’s users to update their help, so they include all the WebHelp files and folders in with the programs when they compile and produce the installer. This method ends up bloating the installer file to over 1GB. In my division we decided to avoid bloating our installers by spinning the WebHelp off into its own installer. They both work fine at wiping the client’s existing WebHelp and reinstalling all the files in their respective folders. It ends up being about 500 MB in size.

K

ktbFLAuthor

Inspiring

Hi Jeff,

Thanks for the quick response... Your second option sounds most like what

we would consider...

How do I ask developers for that, how does it work...? Basically I need

details too pass on and I am not savvy enough to know what this means for

any of us as far as responsibility delegation.

Sorry...

Jeff_Coatsworth

Community Expert

In our case I generate the help, then blow away a folder on our LAN server and place it up there. The installer program has a script that basically sucks up all the contents of the folder off the server and compresses it and creates a .exe – that .exe is basically like a zip file (only smarter) that gets either burned on DVDs or put on our website for clients to download and run.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded