Skip to main content
A
Anonymous
April 1, 2014
Question

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

  • April 1, 2014
  • 2 replies
  • 1370 views

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.

This topic has been closed for replies.

2 replies

A
Anonymous
April 2, 2014

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

A
Anonymous
April 3, 2014

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.

Jeff_Coatsworth
Community Expert
Jeff_CoatsworthCommunity Expert
Community Expert
April 1, 2014

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
Captiv8r
Legend
April 1, 2014

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

A
Anonymous
April 1, 2014

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

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices