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

[ktbFL]

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

[Jeff_Coatsworth]

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.

[ktbFL]

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]

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.

[ktbFL]

Great info.. and sounds easy... where do i find info on the installer

program scrip.. oh.. and is your stuff CSH?

On Tue, Oct 28, 2014 at 3:22 PM, Jeff_Coatsworth <forums_noreply@adobe.com>

[Jeff_Coatsworth]

Try here - http://en.wikipedia.org/wiki/List_of_installation_software on the various flavours of programs. I’d talk to your developers to see what they’re already using for software distribution first.

Yes, it does CSH too – because of the ancient language that we write our programs in, I had to develop a “handmade” solution that invokes the RH CSH API to launch the correct map id.

[Peter Grainge]

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

[RoboColum_n_]

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.

[ktbFL]

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>

[ktbFL]

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>

[Peter Grainge]

The developers set things up to look for a connection. If it exists, they take the user to your server. If it does not, they take the user to the local version. A dialog could tell users that because there is no connection, they will be shown the local version - optional.

Users would not download anything. Local copy would be set up at installation. Updating between versions is optional as long as users are made aware your web server version is more up to date.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[ktbFL]

So after the comments from Jeff and Peter being forwarded to the sw

architects, here is the response:

What we need to determine is if there is any way to manage the help where

change sets can be sent out rather than entire help file. I’m not sure how

this might work with robohelp. Our stumbling block is not us deploying to

the customer but once the customer gets it they need to deploy to all the

laptops their staffs take to patient sites. Them having to download to all

those laptops every SP is the issue. Check with your contacts and see if

they have any recommendations. We’ll talk in more detail next week.

DID I MENTION... HELP ME PLEASE!!! If there is no way to figure this out,

we will be stuck with the current situation - 1 set of functionality = 1

chm = 1 loooong scrolling page... so our total help is over a GB... and

it's UGLY, UGLY, UGLY from every perspective!!!

HELP ME!!!!!

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

[Jeff_Coatsworth]

So how are they installing the software already to all the laptops right now? BTW when you said this was a fat client application, that infers that there’s a server involved in this with clients attached to it – what you’re describing is just a straight install on to each machine as if I had bought Word or Excel and installed it on my machines at home.

Doing a differential build of only the topics that change would be tougher, since regenerating wipes the \!SSL!\WebHelp\ folder each time & I think dates all the files the same date/time. You might have some luck with the publishing part of the SSL – there’s something in there about only updating the changed files, but I’ve never used it. You’d have to copy the output into some location, update only the changed files, determine which ones they were and then compile an updater to package & deliver them to the right spot on the laptop.

Did they tell you what tool they use for installing the software?

[Peter Grainge]

So do what we do in many cases, install the webhelp on the client's webserver. App links to that for help.

Easy.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Amebr]

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.

[ktbFL]

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]

Same principle would apply – only compile & distribute the changed files in the output. These self-extracting installer programs are quite smart in figuring out where to place the contents of their packages.

[ktbFL]

Just to confirm... RH doesn't provide such an installer at any point...

Correct?

[Jeff_Coatsworth]

Correct – this is all “after-generating” stuff; RH doesn’t really to any distribution stuff except “Publish”

[ktbFL]

Thanks, Jeff... Wanted to make sure I was understanding... THANKS!

[Peter Grainge]

Sorry for slow reply, family bereavement.

When you generate you do so locally and the target folder is emptied first. When you publish Rh will only upload changed files unless you have Republish All ticked. It will not delete files that are no longer required. Thus YOU could get Rh to just upload the changed files if you had access to the customer's servers, which I doubt you have.

Similarly your developers could use software to do the same but I suspect what they want is to send a package containing only the changed files and where the customer installs them. That would require knowing in advance what is on the customer servers and I don't think there is a practical way of doing that.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[ktbFL]

Hi Peter,

So, so sorry for your loss... I appreciate you contacting me despite it.

I think the devs are going to write a script to push only the updated

files...

Now I have bookmark issues as posted in the forum...

Thanks... hope the days get easier for you.

kb

On Sun, Nov 9, 2014 at 7:04 AM, Peter Grainge <forums_noreply@adobe.com>

[Peter Grainge]

As long as all customers have the same version of the help and they include ALL updated files, not just the topics, that could work. If there is a potential for one customer to get an update that others don't have, put on your tin hat.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[ktbFL]

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