Work From Home VPN end users report RoboHelp is too slow.

[MH_Angell]

My company is adding more work from home (WFH) options.  I was unaware that online help published as WebHelp accessed through VPN was so slow as to make it a chore instead of a help.  I go in through my remote desktop, so did not see any difference when I tested output.  WFH users do not have a remote desktop to access. 

I began experimenting by  publishing as .chm to gain some speed for them.  I instructed some users on how to download the HTML chm help to their desktops, but they reported that it takes from 30 minutes to 2 hours for the download.  In addition, it would be up to the end user to download it daily to stay current.  That may not be workable, either.  Once downloaded, however, it is acceptably fast.

I have been asked by another department to assist them in setting up RoboHelp for their area if they decide to purchase.  I would train the Instructional Designer on how to use RoboHelp from  and author/publisher standpoint.  I am not a IT person.  I have been using RoboHelp since about 2000 and am proficient in the front end stuff, but not back end.  Ours is a VERY secure environment with firewalls galore. 

If the decision is made to go with RoboHelp instead of straight Sharepoint for their help files, they will be purchasing Version 11.  Many of their employees are WFH.  I hesitate to advise them to make the financial commitment until I've figured out a solution for end user speed over VPN (if one exists).  I have read all that I can find about the problem (Access database, etc) and am now posting here for assistance.  I need a solution for my area, also.  I use RoboHelp version 8.  We just recently moved to Windows 7.

Thank you,

Holly A.

PS -  I apologize if this is the wrong forum.  Nothing seemed to fit my question perfectly.

[Jeff_Coatsworth]

I think you’re getting the creation of help tool (RH) mixed up with the help output itself (webhelp) – the two don’t really have a lot to do with each other when it comes to accessing them via VPN.

Trying to run RH to create content for help systems with a VPN is probably a losing proposition unless you either RDP into a workstation within the network where RH is installed locally (BTW - that’s how I’m working right now), or employ some sort of source control system that will allow you to check out the RH project files to your local (home) workstation that has RH loaded on it.

In either case, those remote workers who are accessing the webhelp content you generate don’t (or at least shouldn’t) have any issues than they normally would face accessing any other website. If they are, then there’s something in the way your remote workers are accessing the web pages you’ve created that’s not set up correctly or your content has an extreme amount of processor-intensive graphical content that’s causing a slow-down.

[Captiv8r]

Hi there

I read that differently than Jeff did. You do say end users. However, I think you may be a bit confused with the mention of the Access database. That part would only come into play during the editing process. No database is involved for end users. It's all a bunch of HTML, Javascript and Image files.

Does your company have an intranet? If so, do the WFH users also see the extremely slow behavior for that? If that's the case, you can't expect WebHelp to outperform that as you have an underlying problem somewhere else to resolve.

Cheers... Rick

[MH_Angell]

I was trying to not be confusing, but it seems I have been anyway.  Normally, I generate help using Webhelp Single Source Layout that results in a bunch of loose files.  It is published to a server and accessed by a link on our Intranet.  There is no speed of access issue for our end users who access the intranet from the office location or from their computers when logging in to a remote desktop at work.

I've researched the problem extensively and what I have read is that RoboHelp is built on an Access database and that VPN is slow because of the way packets are sent over the network. VPN users can access the Intranet and all other applications without any issue with lag time.  The only one they have trouble with is RoboHelp.  If my end users can't use what I publish, then management will start looking for another option.  I want to fix this before it gets out of my hands.

When I publish using HTML Help single source layout (with the .chm extension), the speed issue is solved because the files are saved in a "bundle" or smaller package.  The problem still exists that downloading the file to the remote users' computers is very slow.  Accessing the topics in the compiled version once they have been saved to the end users' desktop is fast.

I want to know if there is a way to publish my help projects that will allow those who access the published output by VPN to see their help topics as fast as it is when they are in the office and access it from the Intranet locally.  They still use the intranet, but from a remote location.  They do not have desktops at work to log into. 

Cloud storage is not a possibility.  Is there an SSL that I am missing and have not tried that might solve the problem?  If we published to Sharepoint, would that help, althoug I can't imagine how.

I can't believe that I'm the only one experiencing this problem.  i want everyone who uses it to be as satisfied as those who use it locally.

Thanks,

Holly

[Jeff_Coatsworth]

No, you’ve misunderstood – the RH project (the source files YOU use) are based on an Access db – the help you produce – WHATEVER flavour you create - doesn’t use Access at all.

The posts you saw were users trying to run their RH projects remotely via a VPN in a manner that violated the RH license (you’re not allowed to install it on a server where multiple sessions of it can be run).

I’m still unclear as to what you mean when you say “i want everyone who uses it to be as satisfied as those who use it locally” – what’s “it” in this sentence?

Are you trying to let remote workers access your RH project topic files or the generated help output topics?

[MH_Angell]

Forget I mentioned an Access database and let's cut to the chase.  The output that has to travel over the VPN when I publish using the SSL Webhelp cannot be accessed in a timely manner.  Even output published as HTML help takes up to an hour to download onto a remote computer.

It is the RoboHelp output that I want them to be satisfied with...their help files.  i want them to be able to click on the link and their Table of Contents, Search, Index and Glossary options will all pop up just like when they click on the link to their help files when they are in the office.  When they click on a topic, I want the topic appear on their screens without the users having to count to twenty five. 

Is there a single source layout that will be faster? 

Thanks,

Holly

[Captiv8r]

Holly, I'm not sure I saw an answer to a question I asked earlier.

When folks are working via VPN, do they see the same speed issue with opening other sites? If so, there likely isn't much you can do to improve things and I'd be skeptical that any other authoring tool's output would be any better.

The thing is, at the end of the day WebHelp output is just a bunch of HTML, JavaScript and Image files. It should behave just as snappy as any other site does. If it's not behaving that way, I'd be investigating where it's being accessed from because something sure sounds amiss.

Cheers... Rick

[MH_Angell]

They do not see the same speed issue when opening any of the applications that they use when accessing by the VPN.  The other applications open without a speed issue.  It is only RoboHelp that runs slowly.  I've asked for VPN access so that I can test it myself.  I log in to my desktop at work when I work from home.  It's a different connection than the type used by VPN.  VPN uses encrypted files. Everything the end users access to use at work is located on company servers.  That includes their help files.

I'll continue to work on this.

Thanks,

Holly

[Captiv8r]

Holly, not trying to be overly nitpicky here, but it might be helpful to those of us trying to help if you could stop referring to RoboHelp (The editing application) and WebHelp (product created by RoboHelp) as being one and the same. It muddies the waters.

When you say "RoboHelp runs slowly" our minds leap to you using RoboHelp and making edits and wondering why it's slow. But if you say "WebHelp runs slowly", there is no question in anyone's mind that you are referring to the WebHelp output as generated by RoboHelp.

I'm admittely a bit surprised that you don't have the same access an end user would have. That would seem to be a rather crucial piece of the puzzle.

Hopefully your IT can maybe shed some light for you as to why simple HTML pages are so slow to load in the VPN. If you do get it sorted, we would appreciate your posting back here to let us know what it was that resolved the issue. It's certainly not a common one or we would have had you up and running smoothly by now.

Cheers... Rick

[Jeff_Coatsworth]

@Rick - +1 for clarity ;>)

[Jeff_Coatsworth]

As Rick says – if viewing the output is slow via VPN then you’ve got some structural issues with how they’re accessing the server’s HTML pages. There’s nothing really special about WebHelp created by RH vs. HTML pages created from any other HAT. Sounds like your IT dept. needs to have a look-see into what’s happening. I know at my company our VPN servers are constantly getting tweaked to improve speed.

[IsaT-h7xvUK]

Holly,

Not a solution, but a confirmation: I'm working from home right now, so I just connected to my company VPN and tried to open a WebHelp project that is on one of our file servers (not a Web site) to see how it goes (I never do that, because that's not how our help systems are used).

The results:

• With the latest version of Chrome: Opening and browsing the WebHelp output (clicking links, TOC and index entries, etc.) works just fine.
• With the latest version of Firefox: Takes a lot longer, and makes navigating the help project rather painful.
• With IE10 (I don't have IE11 on the computer I'm working on at the moment): Just opening the WebHelp output takes ages, forget about browsing.

So, with the exact same computer, VPN connection, bandwidth, etc., the "user experience" varies A LOT just depending on the Web browser being used.

Just for the record: The WebHelp output I tested was generated with RH10 and all the latest updates from P. Grainge to make it display properly with the major browsers. Also, re the Web browsers: I never tweak them, I always use their default settings (whatever they are); no add-ins.

Hope you find a solution for your users. Keep us posted.

Isabelle

[MH_Angell]

Thank you, Isabelle.  Your research will likely prove very helpful in my search for answers and a solution.  It gives me another thread to follow.