RESPONSE SUMMARY-L-O-N-G RoboHelp-the adventure begins

["Julie A. E. Tholen" <tholeja -at- ANUBIS -dot- NETWORK -dot- COM>]

Greetings fellow techtrons!

Well as with everything in the computer industry, reality has reinvented itself once again. My little project has gotten pushed out sooo far that now I may need to locate a RoboGun out on the East coast to do the
first pass at this project. Let me know if you know of anyone who is quick, good and likes pressure.

Here is my original post and responses.  Thanks to all who responded; your help, advice, and words of
wisdom were terrific!


Thanks a bunch.
Jules    "Life is short. Eat dessert first"
(J.A.E. Tholen)
612.391.1354
tholeja -at- anubis -dot- network -dot- com


*********************************original post*****************************************
I've just been green-lighted to develop on-line help for a new tool with RoboHelp (as opposed to the programmers doing it in C++).  I've never worked with this
tool before, but several of my colleagues have. But we have a question regarding
the inital setup of the tool. How much and what kind of programmer involvment is
required? We will be having training on the tool, but I need this information
for my deliverable plan.

If those of you who have worked with RoboHelp fresh out of the box on a project
could supply me with time/work estimates/definitions and general words of
wisdom, I would be very grateful. Of course I'll post to the list a summary of
responses.

************************************RESPONSES***********************************************

From: Sue Heim <sue -at- ris -dot- risinc -dot- com>
> When they have all (or most of) the dialog boxes, etc., defined in
> their .rc (resource) file, they'll need to run makehelp. This will
> produce a .hm file with all the dialog box help IDs defined. (the
> IDs should mostly be obvious from their names, but you may need some
> guidance on which ID goes to which dialog box). You take the .hm
> file and attach it to robo. Then, when you create a context-
> sensitive help topic, you use the help ID string from the .hm file
> as the context string for the topic (select it from the list in the
> topic definition dialog). When you put the help file and the program
> in the same directory, the links are automagic.

One thing to add... if you've purchased the WinHelp Office suite,
there's a nifty util included called WinHelp BugHunter. This
handy-dandy little item allows you to figure out what the heck the
context IDs are (if your programmers are as vague as mine!). You just
launch BugHunter (which stays on top of all apps), then click Help or
press [F1] in the app for which you are trying to link context help. The
ID appears (in decimal) in the BugHunter window. Then you just need
to convert that number to Hex and match it to the number in the .HM.
Simple (and this way I don't have to depend on the programmer's to
remember to give me the IDs! <grin>)!

...sue
-------------------------
Sue Heim
Research Information Systems
Carlsbad, California USA
Email: Sue -at- ris -dot- risinc -dot- com

From: "Susan W. Gallagher" <sgallagher -at- expersoft -dot- com>
Your programmer involvement will be minimal, Julie. Mostly, it
depends on the language they use, but you mentioned C++ so I'll
assume...

When they have all (or most of) the dialog boxes, etc., defined in
their .rc (resource) file, they'll need to run makehelp. This
will produce a .hm file with all the dialog box help IDs defined.
(the IDs should mostly be obvious from their names, but you may
need some guidance on which ID goes to which dialog box). You take
the .hm file and attach it to robo. Then, when you create a context-
sensitive help topic, you use the help ID string from the .hm file
as the context string for the topic (select it from the list in the
topic definition dialog). When you put the help file and
the program in the same directory, the links are automagic.

If you're doing "What's this?" help, the programmers have the additional
chore of adding an array of widget IDs to the dialog box definition.

If the programmers are in the habit of reusing dialog boxes (common in
MFC-based applications [Microsoft Foundation Classes]), they need to
supply different help IDs to each different instance of the dialog box.

Sue Gallagher
sgallagher -at- expersoft -dot- com
     -- The _Guide_ is definitive.
        Reality is frequently inaccurate.


From: Miki Magyar <MDM0857 -at- mcdata -dot- com>
Bon voyage - robohelp is a good tool. However, there is one 'feature'
you should be aware of. When you've edited your .rtf file and are ready
to compile it into a help file, you're asked if you want to save it. You must
say YES, or all your work goes down the drain and is lost forever. I got
in the habit of putting the original .rtf file in a 'rawrtf' subdirectory and
copying it to the directory I was using to build the help project.

Aside from that, I like it better than ForeHelp, which I'm using now. I
prefer the ability to edit the .rtf file directly, instead of having to deal with
the one level higher GUI. Personal preference.

Their online help is good, the documentation adequate, and I had no
trouble getting up and running with it very quickly.

From: Chuck <chuckm -at- fwb -dot- com>
Your interaction will depend on whether you will be developing
context-sensitive Help. If so, you will work with your software
engineers to make sure your topic IDs match up with all the interface
elements.

If not, then your interaction will be basically the same as written
docuemtnation: review to make sure the information is correct. The
eexception is that you will have to make sure the Help file istelf is
called correctly from the Help menu.

--
"You don't look American"
"Everyone looks American, because Americans are from everywhere."
                                           - Doonesbury
O-
Chuck Martin
Sr. Technical Writer, FWB Software    | Personal
chuckm -at- fwb -dot- com                        | writer -at- creative -dot- net
http://www.fwb.com                    | http://www.creative.net/~writer

I have used RoboHelp extensively. I did use a tool before using
RoboHelp, so I a had an idea of how to use online help authoring before
it. However, it does come with a great tutorial. You can start creating
within a couple of hours of getting it out of the box. If you understand
software applications fairly well, you shouldn't have a problem using
the product.

Hope this helps,
Stacie L. Steinberg
Technical Education Specialist
LanVision, Inc.
ssteinberg -at- lanvision -dot- com

 I started using RoboHELP with no programming background, virtually no
     training or programmer support... It is very intuitive and easy to
     learn.  With a technical writing background, you will master RoboHELP
     very quickly, especially if you have RoboHELP 4.  This tool uses MS
     Word as its base and adds very useful tools.

     Bill Warner, Ph.D.
     Senior Technical Writer
     ReliaStar Financial
     Minneapolis, Minnesota
     bwarner -at- reliastar -dot- com

From: "Phil Hellerman" <Phil -dot- Hellerman -at- mci -dot- com>
RoboHelps takes no programming involvment to set up. However, you do =
need some coordination if you will be using W95 style help. Also, the =
development environment your programmers are using matter to RoboHelp =
but is defined when you create the intial project. Other than these =
items, no programmer hand holding is required.

If you are comfortable with tutorials, you should be able to become =
proficient with RoboHelp after their tutorial. It takes 2-5 hours based =
upon your proficiency.

I have used RoboHelp for several years and find tool to be great and =
support excellent.

From: Elna Tymes <etymes -at- lts -dot- com>
Programmer time is required only to establish the links within the
program itself.  There's a separate compile file that needs program
links in order to pop up when you press the Help key (usually F1).  How
much programmer time depends on the number and types of links.  Usually
no more than 4-8 hours is required, and that includes design time.

> If those of you who have worked with RoboHelp fresh out of the box on a project
> could supply me with time/work estimates/definitions and general words of
> wisdom, I would be very grateful.

Depends on what you consider "fresh out of the box."  As a new user,
you're going to make mistakes and have to redo things as you get used to
thinking in non-linear fashion, and as you get comfortable with the
program.  Once you become familiar with the program, your
design/implementation time will decrease.
The most efficient implementation of an online help program use approved
text as its material. This means that, if you're doing a parallel
ink-on-paper doc set, you need to get the hardcopy material past the
first review at the very least, so that you won't be changing two sets
of text.  In our shop, we vastly prefer that online help not start much
more than a basic outline until the text has been approved.  Conversion
of the material is then more like an editing process, where you lift
applicable material and rewrite/tag it for use in online form.

How much time the design process takes depends on how extensive you want
your help to be.  If you want to use the kinds of Quick Start
question/answer presentation that Microsoft uses, you'll need more time
to think through what kinds of questions your users will have.  If you
intend to use the outline of the manual as the outline of the help
system, you'll have corresponding less work in that phase.

We can generally do a simple lift/format/tag conversion at the rate of
about ten (manual) pages an hour, but then this is one of our core
proficiencies.

Elna Tymes
Los Trancos Systems

If you want the help to be context-sensitive, you will need to
coordinate a list of context strings with the programmers.  Where I
work, the programmers supply the strings, and I sometimes find it
necessary to pester them a little.  Especially if you are in a
version of the original software with new screens or features being
added, you have to be sure you have the latest.  You may also come up
with questions of "what does this context string refer to?"  I suppose
it would be possible for the tech writer to write the strings and give
them to the programmers, but I don't know how practical that might be.

When you open a new RoboHelp file, the template asks you to identify
the environment (C, C++, etc.) in which the help will be used.  I
have never quite understand this.  The help seems to work ok whether
I go to the programmers and find out, or if I just enter the
Standalone option.

You would also have involvement with the programmers if you planned
to use screen captures.  I would advise against using screen
captures.

Bill Sullivan
bsullivan -at- deltecpower -dot- com
San Diego, California

The programmer involvement is usually limited to supplying the context IDs if it's a context-sensitive system.

If you use RoboHELP 95 or 4, learning and using the tools is pretty easy. I went to Solutions training for RoboHELP and advanced RoboHELP, which was useful, but anyone familiar with software programs and has the ability to look up things in the documentation, shouldn't have too many problems with it. Blue Sky does support the product, but I found e-mail worked better than phone as a means of getting responses.

Good luck,

Joel
joel -dot- cambron -at- chirondiag -dot- com

From: "Phil Hellerman" <Phil -dot- Hellerman -at- mci -dot- com>

W95/WNT is not a problem since RH has a version specifically supporting =
W95. (Comes with W3.1 so you need only select evironment.)

Not so sure about HP OpenView however. I develop context sensitive help =
that uses the capabilities of the program developed map files. (I've use =
PowerBuilder in the past and presently using Micorsoft Developer Visual =
C++.) You might want to ask RoboHelp themselves via email to =
robohelp -dot- support -at- blue-sky -dot- com -dot- 

HP OpenView may have some common architecture with others listed by RH; =
Boland C++, Visual Basic, Paradoc, Access, WinMaker Pro, PowerBuilder, =
Excel, Borland Pascal, Tubo Pascal, Symantec C++ Borland C++, Microsoft =
C/C++ Generic C, and Generic C++.

Let me know if I can help further. (Above type quickly so excuse grammar =
and spelling.

From: jarnopol -at- pop-blue -dot- interaccess -dot- com
Boy can I attest to problems using RH95 for a C++ program.  The first thing
to do is to figure out where you want context sensitive help and let the
coders know about it.  The problem with C++ is that RH can't generate a map
file for it.  Well it can, but it does you no good because all the map
numbers have to be in hex for C++ applications.  So you and the coders have
to be very clear about what your topics are, what your context ids are, etc.
This is one case where communication with the coders is a MUST.

As for using RH, it's a great tool.  I've developed online help for both C++
and Visual Basic 4.0 applications.  I love it.  Before we had RH, I
developed help files in an undocumented Microsoft help tool.  Major pain.
RH is great and we looked at Doc-To-Help before we bought RH.

From: joanne grey <j -dot- grey -at- worldnet -dot- att -dot- net>
I have to agree. I started using RoboHelp with no programming background
and a very small amount of help knowledge.

After an inital learning curve (which was very minimal), I found that
the part of the day that I got to use RoboHelp became the part of the
day that I looked forward to. It's a terrific tool.

From: John Engler <spillman!jengler -at- uunet -dot- uu -dot- net>
Hey techsters,

It's true that makehelp generates a .hm file, but only in certain
development environments. We've just begun developing in Visual C++ and
it doesn't create a .hm file, only a .hh file. Apparently the .hh file
doesn't include the topic IDs for individual dialogs (although it does
include IDs for menu items and some other dialogs, for example the whole
window). Without the .hh file, you have to go in and link Visual C++ IDs
and Robohelp IDs manually in the aliases section of the .hpj file (this
is what I've read, although I haven't been able to make this work yet).
I'd be grateful to hear from anyone who has had this same experience
because I still haven't figured out how to make my context-sensitive
help work right yet.

  Mike Norton
     mwnorton -at- formmaker -dot- com
Here's another idea:

     Our programmers added to our applications a startup parameter which
     tells you the context ID sent to WinHelp when you click on a Help
     button or press F1. While it doesn't solve all ID problems, it
     certainly lessens your dependence on the programming units and vice
     versa. You might ask your programmers if they could do the same for
     you.