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.
> Increasingly, I find myself in discussions with other members of my
> documentation team on the advantages of Winhelp over Webhelp (I'm
> a Webhelp
> proponent).
>
> We are exclusively delivering web-based applications, and we are
> delivering
> Webhelp with them. The issues stem from some writers' insistance
> that using
> RoboHelp Classic to create Winhelp files and then "generating"
> Webhelp from
> them is just as effective as using RoboHTML to create Webhelp directly. I
> find that going the Winhelp-->Webhelp route creates truly hideous
> HTML. The
> Winhelp proponents argue that the process of opening the Webhelp files
> (originally created as Winhelp) in RoboHTML is what mangles the HTML.
>
> Jennifer Delmerico, Sr. Documentation Specialist
I ran up against this issue a few years ago and it drove me crazy too. The
HTML generated by RoboHelp was so bad that I was amazed that it would
display at all. It was full of redundant markup that substantially increased
the size of the files and it also made it impossible to apply a style sheet
so that the help files would match the HTML used in the rest of the
application. I ended up doing a lot of post-processing to clean up the files
(HTML Tidy is great for this).
I got frustrated enough that I called RoboHelp and spoke to their support
people. According to what I was told, they generated the HTML from the
Winhelp files, not from the the original Word documents (which probably
would have produced better HTML). This was in RoboHelp 7, so it sounds like
they haven't improved it since.
Given that you have a web-based application, I don't see how you can use
WinHelp at all. Even if your user's could open a help file from the web
server, it'd only be useful for people on Windows. You have to use an
HTML-based solution.
You haven't said whether you are trying to single-source printed docs and
the HTML-based help. If you are, I'd take a good hard look at using
FrameMaker with WebWorks Publisher, which produces much better HTML than
RoboHelp. I switched from a FrameMaker/RoboHelp setting to
FrameMaker/WebWorks and I'd never go back to trying to work with RoboHelp.
If you are not single-sourcing, then why not go to a straight HTML tool,
such as Dreamweaver, to get your HTML the way you want it, then import the
files into RoboHTML? Or use the HTML Workshop without RoboHTML.
For more on single sourcing, see the article "The Joy of Single-sourcing"
by Hedley Finger on the Articles page of my web site.
Best
Keith
--
Keith Soltys
keith -at- soltys -dot- ca
Host of "Internet Resources for Technical Communicators" since 1994
Now at http://www.soltys.ca/techcomm.html
Out of work and looking for a job or contract in Toronto.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
TECH*COMM 2001 Conference, July 15-18 in Washington, DC
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com
---
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.
