Selecting the right authoring tool for the job

This section is for announcements, information and discussions relating to the help community -- for example news about events and seminars of interest, developments in help technology and so on.

Moderator: Tim Green

Post Reply
scottabel
Posts: 2
Joined: Mon Jul 31, 2006 12:23 pm
Location: Sarasota, Florida
Contact:

Selecting the right authoring tool for the job

Unread post by scottabel »

<this post was revised at the request of the site admin on August 1, 2006 .. the title has been changed also, from "A look inside my RoboHelp and FrameMaker Crystal Ball" to "Selecting the right authoring tool for the job">

There has been much chatter about the demise of both RoboHelp and FrameMaker. RoboHelp is not dead. New versions of FrameMaker are in the works, as are new FrameMaker plugins for DITA and for S1000D. I predict you'll soon see new versions of both products. But, is focusing on the demise of one tool or the introduction of another any reason to change how you create help content?

As a consultant that helps organizations select software tools and train their staff to use them, I have to learn about all types of tools from a wide variety of manufacturers. I stumbled across this forum and a new help authoring tool about which I was unaware while working with a pharmaceutical industry client who is struggling to improve the way they create, manage, and deliver content to customers, regulators and others. I have no opinion which tool is "best" because that's not the question I'm trying to answer. I'm trying to find the best way to mange content for each of my clients.

So, no matter what tools you select -- just make sure you do a proper analysis of the true costs of your current content lifecycle. It's really not about tools. It's about recognizing your content is a business asset and managing it as such. It's about return on investment. It's about reuse. It's perhaps about translation, compliance, and risk avoidance. When you boil this down, it's about selecting a methodology for producing your content (think Ann Rockley's Unified Content Strategy) and then matching your business requirements with tools that will actually help you deliver value to your stakeholders, customers, and your organization.


Scott Abel,
The Content Wrangler, Inc.
www.thecontentwrangler.com
Last edited by scottabel on Tue Aug 01, 2006 6:17 pm, edited 1 time in total.
User avatar
Dean Whitlock
Posts: 577
Joined: Thu Sep 01, 2005 5:59 pm
Location: Thetford Center, Vermont USA
Contact:

Unread post by Dean Whitlock »

Hi Scott,

You seem to be very committed to Adobe products; however, I myself would find it hard to justify using RoboHelp and Framemaker - two separate programs for two basic forms of output - when you can use H&M to get both types of output (and at less than half the cost). Someone with a large number of separate help projects already in the RH and FM formats, and therefore facing a huge conversion process, surely has to take those hours into consideration. If they are smart, they will also balance the effort of that conversion against the current on-going effort of moving content from RB to FM or vice versa in order to get on-line help and printed help that work together. They must also consider that DITA from Adobe is a promise, not a reality. H&M works great now. There's no crystal ball like the present!

Best,
Dean
User avatar
Hal Heindel
Posts: 22
Joined: Sun Oct 09, 2005 11:19 pm
Location: Rochester, NY - USA
Contact:

Unread post by Hal Heindel »

Dean Whitlock wrote:You seem to be very committed to Adobe products.
Sometimes, Dean, it isn't so much a question of what tools you like and are committed to, but of what tools you already own and are proficient in. In our print shop, Adobe products such as Pagemaker, InDesign, Framemaker, and PhotoShop are as common as a hammer on a carpenter's tool belt. We already have these programs for publishing our software manuals - we don't need to buy them.

What we didn't have was a HAT. Our first tool was ForeHelp. When that company went belly-up we switched to RoboHelp. For the last few months we've relied on H&M to generate .CHM files, far and away the easiest help authoring program of the bunch. Not to mention that the full product price is no more than a RoboHelp upgrade! Now, if H&M were to allow Framemaker import or offer DITA (which is real and no longer a promise in Framemaker 7.2), we could stop keeping an eye on RoboHelp and Flare altogether.

I suppose this should have been posted in the wish list!
Hal Heindel
http://www.printfire.com
User avatar
Tim Green
Site Admin
Posts: 23155
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Unread post by Tim Green »

Hal,

XML in general and DITA in particular have been the flavor of the month for some time now and the hype surrounding them is comparable to that surrounding anything to do with the Internet before the first dotcom bubble burst. Actually, DITA was seriously considered for some time as the possible XML format for H&M by the EC Software development team, among other things because it would have made sense to use an open standard that already existed. Unfortunately, it was completely impossible to use it because it would have been too restrictive.

There are just too many things that the majority of users need and want to do in their help and documentation that cannot be represented in DITA. We already have users complaining all the time that they want more features supported in H&M -- using DITA would have meant removing both features and functionality instead of adding them, and making it impossible to add many attractive features in the future.

It is quite possible that import for DITA, DocBook and similar formats may be added in future versions of H&M. Export to DITA would also be possible, theoretically, but it would be a very "lossy" export, and everything that was stripped would be completely gone and would thus not "come back" on re-import.

Even though opting for DITA would have been by far the easier option it was thus decided to create the H&M XML Schema, because that was the only way to have an extendable XML instrument that would be capable of handling everything that H&M can do both now and in the future. In the short term this creates some problems, but in the long term it will be much better than opting for the easy way out and the restrictions of DITA.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Post Reply