Re: Overcoming archaic doc tools?

Subject: Re: Overcoming archaic doc tools?
From: Sandra Charker <scharker -at- connectives -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 24 Aug 2001 11:00:43 +1000

At 05:57 AM 2001-08-24, Jeanne Fuller wrote:

Well, I mentioned my suggestion for a more modern doc tool than BookMaster in my weekly status report yesterday. Within hours a senior writer came over to give me the "change is too difficult" party line. I mentioned the suggestions several techwhirlers here gave me, and she said they will look into it more seriously now. Thank you so much!

It's not good to rock the boat in this company, but I'm not giving up without a cautious, level-headed fight. I even brought in my FrameMaker demo CD in case I have the opportunity to show it is an improvement.

I'm late to this thread, but here's another take.

In about 1996 I investigated some options for moving from Bookmaster to a QWYSIWYG tool. I got in touch with a former IBM documentation manager whose product had been sold off to another company. The cost of continuing with BookMaster while leasing machine space and time from IBM was so high that they decided to transfer to FrameMaker on Unix, using their own boxes. Unfortunately I don't have my records any more, but from memory:

* The document set was some 50,000 pages

* The conversion took months (that probably includes finding someone to do it and a tough testing period) - don't remember how many people were involved, but got an idea elapsed time was in the range 3-6 months.

* As a group, the writers took about 12 months to become really productive with the new environment, and some never made it (this might be comparable with programmers moving from procedural to OO programming). This length of time surprised me until I made the shift myself - productivity plummets because nearly everyone gets distracted by the look of their words on screen. These guys were also having to adjust to a different operating environment.

* Time to publish did NOT fall until several releases after the conversion (sorry, don't remember how many). In particular, production time (i.e. from approval to ready for distribution) was substantially longer with Frame than with BookMaster. Thinking about it now, I don't know why this was so: memory tells me that the final tweaking took longer with Frame, but I can't see why that would be; might be just a matter of where you draw the lines between production phases.

Don't know if this is of any use to you, except as a reminder that sometimes the cost of change really is too high. It might be that BookMaster really is still the simplest and cheapest way to support your document set. If you get the chance to dig into it, you'll find that it's powerful and flexible, and very reliable.

Bookie's formatting power and flexibility are not usually in the hands of the writers; in current language, it separates template design completely from writing, and it's possible for writers with years of experience on the tool to be completely unaware of how to change the appearance of their work. BookMaster is an ancestor of SGML, and implements the separation of content, structure, and formatting. That has pluses and minuses; this list could probably still fight about them, though not as fiercely as it once did.

Of course, sometimes the cost of not changing is too high too. For writers, the learning curve is pretty long, and that's a bitch (though I remember the BookMaster manual with fondness - it was even funny, if you read closely enough). For your own sanity, remember that those files, like HTML files, are just text, and it doesn't matter what you use to edit them. Provided you can swap between ASCII and EBCDIC, you could use any decent text editor and set up macros for the Bookie tags so that you don't have to remember or type the tags. If your company doesn't already have something like that, it might be a valuable tool for them because it could enable new people to become productive more quickly (your experienced Bookie people probably won't get much from it).

Good luck, and try not to close your mind completely to the strengths of an archaic tool. If you can find ways to make those strengths easier for current eyes and fingers (like your own) to apply, you'll likely give yourself an easier time as well as learning a packet.

Sandra Charker
mailto:scharker -at- connectives -dot- com


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** 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

A landmark hotel, one of America's most beautiful cities, and three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/

---
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.


Follow-Ups:

References:
Re: Overcoming archaic doc tools?: From: Jfuller246

Previous by Author: Framemaker download
Next by Author: Re: Issues with Adobe Acrobat and PDFs? (take II)
Previous by Thread: Re: Overcoming archaic doc tools?
Next by Thread: Lone Technical Writer


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


Sponsored Ads