Random thoughts about publishing

icon Site Feed

Labels

Acrobat DITA Open Toolkit DITA XMetaL FrameMaker DITA__TechComm DOS DRM Flash FrameMaker InDesign Microsoft Word PDF Photoshop RSS feeds STC SWF SnagIt TechComm Suite Twitter XSL DITA OT customizing specialization XSL DITA OT customizing specialization.php XSLT accessibility adobe analysis apostrophes blogs book business cake change management cmd comments concerts conferences cowbell cranky dita ditalini recipes potluck dita ditalini doctrain doctraineast07 doctraineast08 doctrainwest08 documentation drag and drop ePublisher Pro entertainment equations fish flare framemaker review free garlic georgina's gilbane08 globalization graphics WMF green hacking history humor is08 jobs localization madcap music outlook oxygen path names podcasts potluck predictions presentations print on demand publishing punctuation quark ratings recipes regular expressions reviews robohelp screen captures secured PDF specialization stc09 stc2008 structured authoring survey techcomm alliance technical writing tekom thirst for knowledge thunderbird toc2007 trademark training travel unspoken rule user group video games volunteering vote citizenship rights weather web 2.0 webcasts white papers wiki writersua2008 xmetal xml strategist xml xpubs xsl-fo xsl

Palimpsest

 

Norm Walsh has posted a provocative discussion of DITA and DocBook on his blog (a writeup of a presentation he delivered at the recent DITA 2006 conference).

My favorite part, though, is an explanation of a typical consulting sales process. The technical part of an XML implementation is difficult -- but the real challenge lies elsewhere, as Norm explains:
The non-technical problems [...] were the fact that writing reusable documents is different, often very different, from the way the authors had been writing. And authoring within a strict structure is different, often very different, from the way authors had been writing. And different means change and change is hard. In other words, training authors to write reusable documentation and training them to write correctly structured documentation, usually in a totally different kind of editing tool, is really, really hard.

Indeed. Managing expectations, change resistance, and learning to work in a structured authoring environment are much more challenging than the technical issues. I disagree, though, with Norm's concluding sentence:

And there was basically nothing we could do to help them with [the non-technical] problem.

There's quite a lot we can do to help with the non-technical side of the implementation:

  • We deliver introductory classes on structured authoring and XML concepts.
  • We assess the gap between current authoring practices and XML-based authoring. There's a big difference between a group that has and uses templates and a group that practices "as long as it looks good on paper, nobody cares what's in the file."
  • We help managers and technical leads develop a strategy to educate authors about the upcoming changes.
  • In some situations, we have done phased implementations to give authors more time to adjust.
What are your thoughts? Are there solutions to the "non-technical problem"?
9:41 PM Permalink | |

<< Home

divider


Scriptorium Publishing | Post Office Box 12761 Research Triangle Park, NC 27709 | (919) 481 2701 | info@scriptorium.com