This content has been marked as final. Show 15 replies
Trying to pick a help system for someone else is a brave act! To answer your question about the terms you have used.
RoboHelp HTML and RoboHelp for Word are two applications that you use to create outputs.
The outputs can be:
- WinHelp (RoboHelp for Word only)
- HTML Help otherwise referred to as compiled HTML help and contained in a single file intended to be run locally
- WebHelp which is uncompiled HTML files and is run from a server
- FlashHelp which is much the same as webhelp but can run across many platforms.
Whether or not you need Office Pro depends on whether the help is being run as a service. If it is not, then webhelp will work just fine. If it is, then I believe you need Office Pro.
Perhaps with that knowledge and some Googling, you can get a clearer picture.
Essentially RoboHelp exists as three different products.
* RoboHelp HTML
* RoboHelp for Word
* RoboHelp Server
From the authoring side, you are only interested in choosing between RoboHelp HTML and RoboHelp for Word. Both of these products produce different output types.
* WebHelp Pro
* FlashHelp Pro
All these output types are HTML based. The two "Pro" output types are what would require the RoboHelp Server package. But keep in mind that you do not need RoboHelp Server in order to place WebHelp or FlashHelp on a server. You just end up with additional capabilities by using RoboHelp Server. Some believe that no ability exists for server deployment without having RoboHelp Server, but that's a misunderstanding.
Personally, my own viewpoint is that if you are creating anything HTML based, do not use RoboHelp for Word. Use RoboHelp HTML, as it was designed from the ground up to create and manage HTML. With anything Word based, HTML is an afterthought.
Oh, one other thing. Using RoboHelp for Word, you use Microsoft Word as your editor. With RoboHelp HTML, you have the ability to use either the built in HTML editor or any other HTML editor you prefer.
Hopefully this helps a smidge... Rick
Thanks for the info.
I'm guessing that they will not want help to run locally so HTML Help is out. Ironic that this .NET project will not be able to use MS's product for it's help.
You raise an interesting question about whether or not the help will be run as a service. I don't know what that means.
But won't Office Pro make the WebHelp output?
When RH7 is released in Nov - will all these different products be bundled and all the outputs available from the one app?
I appreciate your input.
Rick - Thanks.
I'm sure my customer wants HTML because he emphasized 508 compliant and CSS. So the authors would have to either learn DW or use the built in HTML editor.
I was also asked for quick deployment from a "CM repository" and assumed that that would require the Server add on. Is that accurate assumption?
I hope you guys (Peter and Rick) aren't thinking I've just been waiting for you to answer my questions. I'm Googling all over the place trying to compare apples to oranges. I found a great HAT comparison tool but it's fraught with terms I don't understand and missing terms/features I'm looking for. HAT comparison tool I don't have the time to learn everything these products do so that I can "score" them and "contrast" each detail. So its so refreshing, and extremely helpful when I can get the info I need and cut thru the jargon.
The way I understand it, you need RH Server only if you're publishing your help system directly to the server from which your users will be accessing it. If your application dev team is using a repository from which builds and deployments are generated (I'm not sure what the CM is in "CM repository"), I would think you can commit files into that repository and not have to touch the server yourself.
This is the way a couple of my projects work--I have a copy of the files in the repository on my hard drive. I make changes on my hard drive, then commit my help output files into the repository within the directory where the application code pages are. The help files are included in dev and test builds and when the application goes to the production server. We use Subversion for this version control process.
Basically, I simply check in my file changes, and when a build or deployment occurs, my files go right along. Hope this helps,
"Running the help as a service." It is meaningless to me too but it is what determines whether or not you need the .NET version which is what I think it was called. Doesn't seem to be mentioned for RH7 so not sure. I will make some enquiries.
Point is unless the developers say it is going to run as a service, forget this variant of the product.
Just to add to Ben's post, RoboHelp Server is only needed if the output is WebHelp Pro or FlashHelp Pro, rather than WebHelp or FlashHelp. The Pro versions give additional features but most people use ordinary WebHelp and FlashHelp. You don't need RoboHelp Server for them.
It has nothing to do with the version control. That is handled by RoboSource Control. Let's not go there right now!
For what it's worth, I was new to all of this just a few short months ago. From what you describe, your customer's situation is similar to mine, and I suspect that RH6 or 7 will work just fine.
My company also creates a .NET application. I use RH6 for HTML and use their built-in HTML editor. So far I haven't felt the need to learn or use DreamWeaver, although I sometimes need to monkey with the HTML by hand to fix numbered lists. The RH editor is somewhat similar to MS Word, so the learning curve isn't too bad.
Our customers install the help files on their local computers when they install or upgrade the software, but we decided to go with Webhelp instead of HTML Help because we liked the output better.
My process is that I create the Help files locally on my hard drive. When I finish with a revision, I "Generate Primary Layout (Webhelp)", review that everything is good to go, and check the Source help files into the appropriate repository within our source control management (SCM) software. We use Surround SCM. The developers set up our s/w build process to look at the help repository. If the files are checked in, the build process automatically launches the RH batch generation process and rebuilds the help. It then directs the help output files (there are 100s of em) to the correct build directory so they can be deployed with the software.
Gotta say, that I was skeptical at first, but it works pretty seamlessly. I check in the changed Help files at night, the software test build runs at midnight, and my Help changes are live when the software installed on my computer performs its autoupdate in the morning.
That makes perfect sense! That's how I would do it too but when the project manager said it, I guess it sounded like it should be more complicated. CM = Content Management.
So RH doesn't have a CM repository but the dev team building the overall application had BETTER..and the help files just go in there. That's clear.
Kathy - Whew! That does sound daunting. It's very helpful to learn about your process.
I never mentioned that my project is web based. It's like an online "tax return meets mortgage application" type form. It won't be installing anything when it runs so I guess HTML help is out.
So far I'm thinking about RoboHelp HTML with WebHelp output...and I'm hoping that RH7 clears all this up by coming out with one tool does all.
Peter - that clears up alot.
And thank you for not going THERE just yet.
PS - I've been bouncing around WikiPedia and it describes RoboHelp as "A specialized tool for creating online help. Very overpriced." How does everyone feel about that?? Wiki sez...
.NET was the version that produced help that would run on that platform. In RH7 that will be incorporated into the the core product.
I really enjoyed reading about Kathy's setup. Never ceases to amaze me how RoboHelp is used in workflows I've never dreamed of
Just to add to what Peter and Rick have mentioned. There remains a lot of confusion about the old product names. Fortunately, one of the first things Adobe did was to consolidate a lot of "RoboInfo this" and "RoboHelp for .Net that" confusion. Now you are only dealing with RoboHelp the authoring client and the RoboHelp Server (which is optional).
There are others but the two main reasons for using RoboHelp Server 6 (or the new 7) are:
1. Ability to search the text of PDF and MS Office (Word, Excel, etc.) files natively rather than convert them to HTML topics.
2. Generate User Feedback reports in order to update future topic content based on that feedback.
As for .NET, the good news is that you no longer have to buy anything extra to use the .NET API (pre-cooked code that developers can use to link topics to Web Applications for context sensitive help, etc.) This is optional. Some developers use it, some "roll their own." But it's there for free beginning with RoboHelp 6 you'll find it on your hard drive here:
C:\Program Files\Adobe\RoboHelp 6.0\CSH API\RoboHelp.NET
Another nice thing Adobe did was eliminate the need for purchasing extra licenses for additional domains on the RoboHelp Server. This helps authoring teams create reports from different sub sets of end users. In the old days you had to purchase a license for each new domain, but no more.
You can read a bit more about this subject in this Developer Network article
Now that I've read this whole thread, I'd like to append to the posts from Peter Grainge and Captiv8r on 10/12/2007. I've been using RoboHelp for Word for almost 10 years, and I've tested RoboHelp HTML version X5, version 6, and now I've begun testing version 7, so I'm pretty familiar with the topic we're discussing. I have no background with RoboHelp Server, so I will omit this product from my post. If I explain something incorrectly, surely someone else can correct me.
The biggest confusion is over the use of the phrases "HTML" and "HTML Help," with respect to discussions about authoring environments and output types. The terminology is a bit repetitive, but the meaning is different when you focus the discussion on either authoring environments or output types. Allow me to explain...
There are two main poins to keep in mind:
1. Where you will do your work (AKA, your 'authoring environment,' which is where you will create, edit, and maintain your source material)
2. What you will produce and hand to your customer (AKA, your 'output types' or 'generated output')
Regarding #1. (Where you will work):
Peter said "RoboHelp HTML and RoboHelp for Word are two applications that you use to create outputs."
I like to think of these two as being the two options for your authoring environment.
If you use 'RoboHelp HTML,' you will author your source material (your Help file content) using either the built-in HTML editor found in RoboHelp, or using any other HTML editor that you prefer.
If you use 'RoboHelp for Word,' you will author your source material (your Help file content) using Microsoft Word.
Regarding #2. (What you will produce):
Captiv8r talked about the different outputs that RoboHelp can produce. He listed some, but not all, of the available output types.
The RoboHelp HTML product can produce all of the following output types:
Microsoft HTML Help
The RoboHelp for Word product can produce all of the following output types:
Microsoft HTML Help
**RoboHelp for Word is the only RoboHelp that can produce the output called 'WinHelp.' However, the RoboHelp functionality here is limited, and nifty things like conditional build tags (as they are applied to Index Keywords and Table of Contents entries), variables (new functionality in RH7 HTML), and snippets (also new functionality in RH7 HTML) do not appear to be available yet for the Word authoring environment in RH7. Therefore, I'm currently focusing my testing of RH7 on the HTML authoring environment, not the Word authoring environment.
JL, you said that your customer "wants HTML because he emphasized 508 compliant and CSS."
Section 508-compliant Output is something that only the WebHelp output can do. I do not see this option listed for the WebHelp Pro ouput type, or for any other output type besides WebHelp.
Cascading Style Sheets (CSS) are not used in the RoboHelp for Word authoring environment. Instead, you use Word Styles here. Cascading Style Sheets are used in the RoboHelp HTML authoring environment, regardless of which output type you choose to produce. The output types do not mention Cascading Style Sheets in the Properties of their configuration dialogs (AKA, Single Source Layout Options).
In summary, you first need to choose an authoring environment, and in doing so, be aware of which one can produce the output(s) you desire.
I hope this helps to clarify a new and confusing topic for you.