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: Giving up on XML (Long) From:Troy Klukewich <tklukewich -at- sbcglobal -dot- net> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Fri, 16 Mar 2007 11:32:59 -0700 (PDT)
Hi Gene:
I think you bring up a good point. When pouring old wine into new bottles we sill end up pouring out old wine. :-)
>From a manager's perspective, I can recount some of the major reasons why we moved content to XML while I was at Borland:
* Reduce the amount of time writers spend on formatting and fixing formatting on large documentation projects
* Reduce translation costs
* Support topic reuse (lower writer maintenance and lower translation costs)
* Eliminate desktop publishing through automating multiple formats for flexibility and scale
In terms of automating PDF production, the legacy formats required numerous fixes to intermediary formats, which were then duplicated for each localized language. The end result was that PDF production for large projects was often delayed for weeks (or even months in some cases) and was extremely expensive to localize.
After automating PDF production with XSL:FO, we ended up with a PDF that was almost identical to the previous look and feel, but only required minutes to generate. It essentially was free. Localized XML was then piped back into the same automation system and we generated localized PDFs in a matter of minutes, too, eliminating the delay and allowing for simultaneous localized shipments.
We saw a reduction in localization costs of at least 30% across the board, which when dealing with multimillion dollar localization budgets is very significant. I have heard of other companies saving even more. Content localization costs for larger companies easily exceed the cost of an entire documentation department.
We also saw an increase of content production of about 30% from our writing teams, which allowed us to cover more projects in the company with existing writers. Writers were spending more time developing content, which is their core competency. Some writers appreciated not having to worry about presentation and focusing on content. Some writers missed crafting the appearance of their documents.
We found that writing in structured XML was a fundamental shift for most writer. It was not really a tools issues, but a different way of thinking. Training and change management is essential.
I would say that XML implementations are best suited for larger, global companies with large product and documentation sets. It's a batch process that scales well. The larger the company, the greater the cost savings that XML and automation provides. Then again, small projects and companies have a way of becoming large projects and companies, so it is worth considering XML in start-up scenarios, too.
Troy Klukewich
Senior Manager, Documentation
And Documentation Services
Message: 33
Date: Wed, 14 Mar 2007 08:34:36 -0700
From: "Gene Kim-Eng" <techwr -at- genek -dot- com>
Subject: Re: Giving up on XML
To: "techwhirlers" <techwr-l -at- lists -dot- techwr-l -dot- com>
Message-ID: <009101c7664e$459bf740$0301a8c0 -at- genekoptx2>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
I would agree with this. Much of the difficulty people have trying
to use XML is that either they or someone directing their efforts
is trying to "convert our documents to XML," but their docments
are perfectly well-designed Word or Frame projects that have no
real need to be structured documentation and will derive no real
benefit from being "converted" to a structured format. Expending
the effort or expense to build or buy all the necessary infrastructure
for XML when the end result is exactly the same PDF that was
previously being produced in Word or Frame always looks like
the boondoggle that it is.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
