TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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
David:
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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 http://www.ehelp.com/techwr-l
---
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 http://www.raycomm.com/techwhirl/ for more resources and info.
