A Wiki Workflow for Publishing
An excerpt from Alan J. Porter’s WIKI: Grow Your Own for Fun and Profit [1].
Buy now at: Amazon.com [2], Barnes & Noble [3].
| Company: | XML Press |
| Location: | Fort Collins, Colorado, USA |
| Purpose: | Build high quality publications efficiently |
XML Press, [4] the publisher of this book, is a small publishing company dedicated to publications for technical communicators, engineers, managers, and marketers.
When XML Press began work on WIKI: Grow Your Own for Fun and Profit, they wanted to take advantage of wiki technology to the greatest extent possible. They saw that wikis could help streamline their processes and increase the interaction among the author, editors, artists, and reviewers.
In addition, they wanted to experiment with new ways of authoring. Most of the books in their current and planned catalog are authored in XML, either DocBook or DITA, and their backend production processes are optimized for XML. However, not all authors are familiar with XML, and the learning curve is steep. Creating an authoring process that avoided direct authoring in XML, and provided the other benefits of a wiki, seemed like a worthy objective.
Based on advice from the author, XML Press chose PBworks, and used the hosted version (http://pbworks.com [5]). PBworks gives authors a rich text editor, as well as the ability to directly use HTML. It exports content in reasonably clean HTML, so conversion to DocBook XML was straightforward process.
Here is an outline of the development process:
-
The author created a wiki page for the outline and separate wiki pages for each chapter, case study, and appendix, along with separate wiki pages for the preface, foreword, bibliography, and colophon.
-
The author wrote sections in the wiki using a brief set of guidelines created by XML Press. Those guidelines described how to markup links (internal and external), footnotes, index entries, and so forth.
-
As draft sections were completed, the primary XML Press editor reviewed them and made comments directly in the source.
-
Periodically, the content was exported and converted to DocBook XML. Then, PDF and ePub versions of the book were generated using an automated process, and the results were then uploaded back to the wiki for review by the author.
-
Technical review was done in the wiki, with reviewers inserting comments directly into the text. The author could then make the requested changes directly in the content.
-
Copy-editing was done in the wiki, after which, the content was exported to DocBook XML for final production.
Overall, the only work not done in the wiki was final production of the printed and ebook versions.
Using this process had several important benefits:
-
Until galley’s needed to be reviewed for print formatting, there was no need to pass printed or PDF copies of the content between the author and editor.
-
High levels of participation from the review team; much more than XML Press has seen with other books.
-
High quality PDFs of the book-in-progress were readily available, even in the early stages of development.
-
Significantly reduced production time. From the final, copy-edited version to the first printed copies was three weeks, a good part of which was spent waiting for the printer.