Since I started being more involved with a specific DITA product, I am seeing opportunities for modular writing everywhere. This may be a case of "when the only tool you have is a hammer, then every problem looks like a nail", but every new prospective technical writing assignment looks to me like an opportunity for a modular approach.
A modular approach to technical writing doesn't mean adopting a particular technology or tool, it means adopting a different way of thinking about what you write. In an August 2001 article in Technical Communication, Michael Priestley of IBM urged writers to "ditch the book as the basic structure" in order to maximise the potential benefits of content reuse using DITA.
But even without adopting DITA, thinking of content in a more granular way can have benefits. Don't think I'm writing "three books for this client's product", rather think "I'm writing seventy-five topics". Ask yourself how this material can be split up into smaller stand-alone portions ("chunks")? Where are the concepts, and where are the procedures? What user steps are needed in more than one situation? What material needs to be repeated in every publication?
You can then decide separately how to assemble those topics into whatever publications and formats are most suitable. There are dozens of different tools to help make that job easier, and each tool has its own pros and cons.
I know that many technical writers think that a modular approach can be artificial and limiting, but I take the opposite view. It liberates technical writers from worrying about the presentation of technical information, so that they can concentrate on getting the content right - timely, accurate, concise, and relevant, and del=ivered as close as possible to the point of need.
How Pantheon Moved their Docs to GitHub
2 days ago