Where RoboHelp and RoboHelp Server users collide
As a user of RoboHelp Server in a team of five writers spread across three locations, we occasionally come across minor issues with its use. One of those is how we manage the publish process from our RoboHelp projects.
Viewing WebHelp Pro & FlashHelp Pro output in RoboHelp
One of the minor irritations of using WebHelp Pro or FlashHelp Pro outputs from a RoboHelp project used to be the workflow you had to run through to check the output as it appears on the server. Once you had published your output to the server, you had to open a browser and type in the URL of the Web Administrator. Only then could you logon and display the project.
All of this has changed with the arrival of RoboHelp 8. This version has a RoboHelp Server pod that can be displayed via the View > Pods menu item. When the pod is first displayed, a “Setup” button is displayed which when clicked allows you to enter the path and name of the RoboHelp Server. Once set, a “Connect Now” button allows you to view the project’s published output.
Tip:
It is a good idea to size the pod to a size that comfortably displays the Web Administrator dialog and save your environment via the File > Environment > Save Environment menu item. If you don’t do this, you’ll have to manually resize the pod each time it is opened.
Deleting Legacy WebHelp / WebHelp Pro Output Files
My wife and I have a running joke about how we organize things. I like order. It’s a man thing I guess. CDs are in racks sorted alphabetically by artist and books are sorted by genre and then size. It’s neat, tidy and easy to manage. Her method of organising is to have lots of piles of stuff littered everywhere. What is even worse is that she knows exactly in which pile that receipt for £2.49 for a cheap brooch bought nine months ago is! I digress!
When it comes to RoboHelp WebHelp and WebHelp Pro output files I am equally as anal. Things are a little easier of course as the files are very handily located in a folder all of their own and are generated / published to a location of your own choosing. But over time you can end up with lots of erroneous files. Take for example a project that is generated and published for the first time. Everything is brand spanking new and the output files are exactly what you require. Move on a few project versions and you may have renamed topic files, deleted baggage files, amalgamated map files, deleted index and/or TOC files. In fact just about any change to a project can result in a previously generated / published output file to be redundant. To make matters worse, because of the publishing workflow you have a duplicate of everything. Your generation directory has the output as it was created by your Single Source Layout. Your published location has a copy of it. So to delete files you have to go to both locations via Windows Explorer and manually delete them.
Of course if you are not bothered by redundant files it really doesn’t matter. They don’t do any harm apart from clogging up disk space, but me being me I like to keep things clean. The problem is, there is no way to clean up redundant files from within RoboHelp. This is a bit of an oversight in my opinion and some single source layout option to delete them would be useful. Maybe I’ll go and submit another feature request before filling a copy away in my Microsoft OneNote notebook; filed alphabetically of course 
Output files and so(u)rcery
The difference between a RoboHelp project’s source and output files can be an area of much confusion. This is especially true where users are more used to WinHelp, compiled HTML (CHM) or compressed JavaHelp output. With these output types you have one or two output files to worry about. Web based output however, has many more. Whilst it may seem unnecessary to understand the difference between the output and source files, it is essential in certain instances.
Take the scenario where you are faced with making changes to a legacy project that you have no knowledge of. You have the output but you don’t have the source. It is a common misconception that to recreate a project you just need to import the output files and, hey presto, off you go. Nothing could be further from the truth. In such instances it is always best to explore all avenues to find the source files. Or how about the scenario where you have a WebHelp project that is published to a test area, but which needs to be copied to a company intranet of SharePoint site once testing is complete. You could just republish to another location or manually copy the files, but which files should be copied?
Web based output types (WebHelp, WebHelp Pro, FlashHelp or FlashHelp Pro) output a series of files in a folder structure that largely mirrors the project’s folder structure. However there are some anomalies. For a start you may notice some additional folders. These contain versions of the output uses in different circumstances. The “whdata” folder contains DHTML files used by some older browsers. The “whxdata” folder contains output used in Java applet and DHTML versions on newer browsers. The “whgdata” folder contains pure HTML.
There are also other files likely to unfamiliar to those who haven’t seen them before. These include files related to context sensitive help, framesets, skins, style sheets and all manner of JavaScript files required by various elements of the help. These files are too numerous to list here but are well documented in the RoboHelp help file.
Users with access to web based output files often find there is no .XPJ file with which to open the project. This is a sign that you haven’t got the source. Some even try creating a new project and import the .HTM files they find in the output. If you do this, you are asking for trouble as the .HTM output produced by RoboHelp contains additional code which when imported back into a project causes it to complain loudly. Try creating a new project and importing a few WebHelp output files to see what I mean.
Compiled HTML output, as the description implies, compiles a set of HTML source files into a single deliverable file (.CHM). The file contains all that is required to display and use the file content and as such is, to this day, a natural choice for applications being installed locally on a client PC. Creating a new help file from a CHM however is relatively straightforward. RoboHelp has its own tool called HTML Help Studio that decompiles a CHM file into its constituent parts allowing you to create a new project from them. Just create a directory, select a CHM and point it at the directory and before you know it you have everything you need to proceed.
Before Compiled HTML output there was WinHelp. This uses Microsoft Word as the editor to produce a series of .RTF files from which a .HLP and a .CNT file are generated. The .HLP file is the package for the help and contains the tri-pane view and the topic area. The .CNT file contains the Table of Contents data and must be shipped with the .HLP file and installed in the same directory for the Table of Contents to be displayed. This output type is no longer widely used and cannot be used on Windows Vista or Windows Server 2008 PCs without downloading and installing the WinHlp32.exe, as it is not part of these Windows installs.
JavaHelp comes in two formats; uncompressed and compressed. Uncompressed JavaHelp produced a series of files in a folder structure in a similar fashion to WebHelp or FlashHelp output. Compressed JavaHelp outputs a single .JAR file. This is a bit like a compressed WinZip file and can be displayed in a JavaHelp viewer. As it is a single file, it is the favored method of delivery.
