Single Sourcing: Building Modular Documentation

Scott Abel writes "Kurt Ament has hit the nail on the head! His latest effort, Single Sourcing: Building Modular Documentation is a valuable reference for those of us who seek to save time, effort, and money by implementing a productive method of creating information once and reusing it often." It's not a big book -- just 246 pages. Read on for Abel's brief review. Single Sourcing: Building Modular Documentation author Kurt Ament pages 246 publisher William Andrew Publishing rating 10 reviewer Scott Abel ISBN 0815514913 summary How to build modular documentation you can re-use in different formats for different audiences and purposes Ament covers the issues -- step by step -- that many others only discuss. He lays out a simple roadmap, complete with real world examples that have worked -- or not worked -- for his clients.

In Chapter 1 (About Single Sourcing), he carefully defines "single sourcing" and explains related concepts (reusable content, modular writing, and assembled documents) in ways that are easy to understand and free of techno-jargon. And, he does us all a big favor by addressing the negatives associated with using technology to assemble documents by explaining that it actually takes more creativity to write content that can fit into multiple media, for multiple audiences, than it does to continually rewrite information over and over again each time it is needed.

Chapter 2 (Building Documents) and Chapter 3 (Structuring Content) are of particular value to those seeking to understand the shift in thinking required to master single sourcing. Writers, programmers and managers will all benefit from these chapters. Each chapter is packed full of tips and examples you can begin using today!

Chapter 4 (Configuring Language) explains how to "configure" your writing to support and increase usability while Chapter 5 (Leveraging Technology) touches on issues including conditional text, conventions, localization, translation, variables and more. As are the previous chapters, Chapter 5 is written in clear, concise language and is not a chapter business types should skip. In fact, it's just the opposite. Managers and decision makers need to understand the concepts explained in this chapter because many of the benefits a single source strategy can deliver are made possible by combining good planning with the right technology. And, while this chapter is certainly not about selecting software tools, the author helps his readers understand some of the issues they will need to understand as they begin thinking about their strategy and the types of functionality they'll need to support with the tools they select.

What I like most about "Single Sourcing" is that Ament went straight for the meat of the issues. He doesn't belabor points or confuse the reader by jumping back and forth from subject to subject (as so many poorly written IT-related books do). Instead, he supplies us with a book you can read in an afternoon and use the information contained within the next day at work.

But, be forewarned. You're going to want your sticky notes and your highlighting markers nearby. Chances are you'll be using them a lot!

Other resources:

• Kurt's site: http://www.infotektur.com
• Book site: http://www.infotektur.com/books/singlesourcing/ind ex.html

Scott Abel (abelsp@netdirect.net) is a content management strategist who assists his clients in planning and preparing for content management initiatives. Scott is a frequent presenter at industry and professional service seminars, an instructor at Indiana University Purdue University at Indianapolis Community Learning Network, and vice president of the Society for Technical Communication (STC), Hoosier Chapter. You can purchase Single Sourcing: Building Modular Documentation from bn.com, though new copies are currently out of stock. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Maven does some neat stuff with documentation....

[tcopeland]

....using Maven's xdocs, you can generate both HTML and PDF docs from the same XML source file.

We use this on GForge and it works pretty well....

Tom

Re:Wonderful review, only one question

[HWheel]

The Single-Source SIG (special interest group) of STC (Society for Technical Communication) defined single-sourcing as "using a single document source to generate multiple types of document outputs; workflows for creating multiple outputs from a document or database source."

For more information:
http://www.stcsig.org/ss/index.htm

Re:use XML

[Ozan]

And there is already a nice DTD for documentation called DocBook.

There are also various XSL and DSSSL stylesheets to convert the docbook xml into html, xsl-fo, pdf, latex etc.

Best thing with XML is, you can pack all of the documentation in one single place and create various documentations according to each audience (user, professional user, developer, etc) and language. There is no need to write duplicate informations, you only have to add certain attributes to the xml tags.

Re:Use Eiffel

[joto]

Use Eiffel

Because of design by contract the code is pretty much self documenting.

Yeah, right!

Design by contract won't make your code any more self-documenting than design by committee.

If you want self-documenting code, write something ridicoulusly simple. If you are doing something hard, you need explanation beside the code (unless you assume that everyone reading the code will be a domain expert, but in that case I wouldn't call it self-documenting).

Eiffel isn't even designed to be self-documenting. It is designed to facilitate run-time (and in some very few cases: static) checking of program invariants, preconditions and postconditions. This will help for correctness, but not much for documentation. In many cases, the code will be easier to understand without them. (Not that I would recommend it, I do like DbC, but only as means to correctness, not as documentation).

Sure, writing down assertions will in some cases help you in how to use an interface, or help you with other underlying assumptions in the code, making it easier to change something without breaking it. But it will never tell you anything about what the code is supposed to do, why it's supposed to do that, and why this way has been chosen to do it.

Now, go re-read your Eiffel book, and come back evangelizing it when you understand it's purpose!