RE: Duck! A context-sensitive help tools question...

Subject: RE: Duck! A context-sensitive help tools question...
From: Ed Klopfenstein <eklopfenstein -at- proclarity -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 20 Aug 2002 08:52:58 -0600


Our shop has been working with both programs for sometime now and feel the
difference is basically in scale. If you're interested in making English or
Non-Asian based help that doesn't have too many topics (sub 3,000) and is
basically hand written, then RoboHelp HTML is fine. If you're looking at
creating much larger help systems that may have to interact with database
systems or XML or may need automation, then go the Frame/WebWorks route.

That said, realize that I write a 3,500+ topic help file for my company's
SDK. We're transitioning away from RoboHelp because management of the files
has become a real headache: It's difficult to localize, difficult to
automate, difficult to track broken links. We're also translating our SDK
support files into Japanese and Chinese soon and quickly found that
RoboHelp's "premier" support seriously lacking. The only help RoboHelp
offered was to buy their Asian edition (which is $1,000 per license, per --
Asian -- language). Why bother buying a support agreement! And don't even
get me started on how the program supports JavaScript, the way it munges
entities, or how it totally rewrites the content between PRE tags.

So, part of my job now is to write an application that pulls the text out of
RoboHelp's HTML into XML so we can manage the files using a database and
Frame. Which is another issue when you grow past RoboHelp's very real
limits: You either end up managing multiple help projects (a bear) or you
end up writing a lot of code to customize an upgrade solution.

Now, the Frame/WebWorks route is no magic bullet either. There are very real
limitations to that environment when you build large systems. One that I'm
finding is creating context-sensitive help, especially as we migrate to the
.NET environment and need to support HelpIDs "AND" XML. However, because of
Frame's modular code structure, IF YOU CAN WRITE CODE OR BUY CODE, it's
easier to customize that environment to support database calls or whatever.
And with WebWorks, it's easier than RoboHelp to change the underlying
template and thus the look and feel.

To sum, if you want easy startup, use RoboHelp; if you want an environment
that grows as your help system grows, use Frame/WebWorks.

It's not a sin to use either: just different costs and benefits.

Ed Klopfenstein

Technical Writer
ProClarity Corporation
PO Box 8064
Boise, ID 83707
eklopfenstein -at- proclarity -dot- com <mailto:eklopfenstein -at- proclarity -dot- com> <>

Check out the new release of RoboDemo, our easy-to-use tutorial software.
Plus, buy RoboHelp Office in August and save $100 with our mail-in rebate.
Get details and download free trial versions at

TECHWR-L is supported by ads and sponsorships...and donations.
You can help maintain the TECHWR-L community with donations

You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit for more resources and info.

Previous by Author: RE: funny job postings redux
Next by Author: RE: Duck! A context-sensitive help tools question...
Previous by Thread: RE: Duck! A context-sensitive help tools question...
Next by Thread: RE: Duck! A context-sensitive help tools question...

What this post helpful? Share it with friends and colleagues:

Sponsored Ads