Skip to main content
Inspiring
October 28, 2014
Question

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

  • 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!!!!

This topic has been closed for replies.

3 replies

ktbFLAuthor
Inspiring
November 18, 2014

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
Community Expert
October 29, 2014

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.
ktbFLAuthor
Inspiring
October 29, 2014

Hi Peter,

Well... that would be ideal, but i think the shear number of users that

would have to be made aware might be daunting for these folks...

Also, how would it work for downloading... would the users have to do it

themselves or what?

Thanks... kb

On Wed, Oct 29, 2014 at 4:06 AM, Peter Grainge <forums_noreply@adobe.com>

ktbFLAuthor
Inspiring
October 31, 2014

It sounds like internet/network access might be extremely limited (patient sites)? Possibly also bandwidth might be an issue?

(If neither of those are an issue, and all software is installed as part of a corporate-style common desktop environment, then I wouldn't have thought deploying the full help each time would be a problem.)

Or possibly the help includes procedures or information that may change without the application itself changing?

Perhaps using a comparison tool like Beyond Compare could work to let your devs build a package of just the changed files (it compares the content of the files, not just timestamps). You would have to keep a full copy of last version output, to run the comparison on, obviously. That *should* pick up changes to toc, search, index files, as well as topics, so t    hat search etc all work correctly while reducing the size of the package that needs to be distributed.

Then build these into a self-extracting zip file as described above.

You would need to test, though, to make sure there aren't any unintended consequences.


Amebr - you hit the nail on the head... i want to apologize to everyone for all this mass hysteria...but this has been a freaking rollercoaster... one day they are happy with the plan, the next day they decided they want to complicate it more... So now my job is to find out how viable and how tricky and perhaps how dangerous it will be to send out JUST the files that have been changed.  Especially for CSH! 


Anyone have any experience with this or have any advice?  Peter?  I suspect you might know how this might work... are they any pitfalls to watch out for.. I just have this fear of sending out a few files from an entire project... Altho, it appears when I publish, ONLY the files that have been edited in some way show a new date.. that includes non-topic files - so i'm assuming sending all those will keep the TOC, Index, and Search features working properly... as well as incoming and outgoing links from an edited topic?


Another question would be how to handle new images in a project... as the image folder tends to be the largest, i don't want to have to send the entire image folder... Thoughts...????  Advice?  Jeff? Peter? Amebr? Bueller?  Bueller?  Bueller....?


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


OH... and Jeff... my apologies for the misnomer of using the term "Fat-ish" client in reference to this... I totally misspoke and should have said Mobile App... but in my mind, any time you have to download something to use it, it's a fat client... sorry!  :-/

Jeff_Coatsworth
Community Expert
Community Expert
October 28, 2014

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.

ktbFLAuthor
Inspiring
October 28, 2014

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
Community Expert
October 28, 2014

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.