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.
Subject:RE: Help without manuals From:"Yigal Rahamim" <yigal -at- tds -dot- co -dot- il> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 8 Nov 2001 15:26:41 +0200
David Hi,
Thanks for your comments. I really didn't mean to open here a debate on
which tool is better.
I agree that there is a difference between Help authoring tools like
ForeHelp and RoboHelp and a tool like WebWorks Publisher.
I personally do not believe in full single-sourcing. I think that this makes
us more technicians and less writers. I agree that in large scale
documentation projects this is a must and have been developing a utility
called doc++ in the early 90s that used Word 6 to create object oriented
documentation. From my perspective single sourcing is a constrain. However
sometimes you don't have other choice. If this is case I found that tools
like Epic from Arbortext are the best way to handle single-sourcing because
real single sourcing require management through database.
By using the combination of FrameMaker and ForeHelp I think that I found the
compromise between the writer concerns to create usable help and print
documentation, and the organization's productivity and quality requirements.
This is what I call "discount" single-sourcing. It is hard to solve problems
when you see things in black and white.
ForeHelp maintain most of the information included in the MIF file. Before
you import the file into ForeHelp you map the styles, so if you make changes
in FM
re-import the MIF to FM you won't have to start formatting all over again.
What's nice in this method is that you still have the capabilities of a
great Help authoring tool to create usable help, and you still save time!!
I have tried that and it works. Of course there are some things to improve,
but it worked for me and for my clients.
As I mentioned in my recent email RoboHelp has just came out with the new
version that includes an import feature of FrameMaker MIF files. I haven't
checked this feature yet so I don't know if it does the same.
Regards,
Yigal
_________________________________________
Yigal Rahamim
Certified ForeHelp Trainer
TDS - Training & Documentation Solutions Ltd.
31 Lehi St, Bnei-Brak 51200 Israel
Tel: +972-3-5782818 Fax: +972-3-5782820
email: mailto:yigal -at- tds -dot- co -dot- il
Visit Our Web Site: http://www.tds.co.il/
-----Original Message-----
From: David Knopf [mailto:david -at- knopf -dot- com]
Sent: Wednesday, November 07, 2001 10:17 PM
To: Yigal Rahamim; TECHWR-L
Subject: RE: Help without manuals
Yigal Rahamim wrote:
| While researching single-sourcing I found two major approaches:
|
| The "real" single-sourcing is a database driven solution which is mostly
| based on XML. This approach does not allow "tweaking" of the output
| deliverables (manual, help).
|
| The other approach is very common I choose to call it "discount"
| single-sourcing. This approach uses a combination of common
| authoring tools
| like Word, RoboHelp, FrameMaker, ForeHelp, and WebWorks Publisher.
It's really not accurate to group the Frame/WebWorks Publisher solution in
with the RoboHelp and ForeHelp solutions. Here's why:
-> With RoboHelp or ForeHelp, you do not maintain a single set of source
files. Instead you export from your source files to some other output
format. For example, you create an HTML Help system and then you export to
printed documentation (in the form of a Word .doc file). Typically, a
significant amount of manual adjustments must be made to the .doc file
before you can actually print and distribute it. Therefore, you are not
maintaining a single set of source documents and, any time changes are
introduced to your HTML Help system, you must re-produce the printed
documentation and re-execute all the manual adjustments. This involves
changing the *output* of the single source process, which is a violation of
a cardinal rule in single source workflows.
-> With FrameMaker and WebWorks Publisher, you maintian a single set of
source documents in FrameMaker and, if you do it right, you absolutely never
under any circumstances need to make any adjustments to the output you
produce (HTML, HTML Help, WebWorks Help, JavaHelp, etc. etc.)
This is a non-trivial distinction that makes WebWorks Publisher a far better
single source solution for many who produce printed and online content.
RoboHelp MVP & Certified RoboHelp Instructor
WebWorks Publisher Certified Trainer
Member, Sun's JavaHelp 2.0 Expert Group
Member, eHelp's RoboHelp Community Advisory Board
Co-moderator, HATT & wwp-users
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Be a published author! iUniverse gives you: a high-quality paperback, a
custom cover design, and distribution to 25,00 retailers. Join our almost
10,000 published authors today. http://www.iuniverse.com/media/techwr
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
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.
