Register (free!) to see more.
What is OpenID?
In traditional single-sourcing, technical writers must collect content from SME (subject matter experts) and add their own content in a publishing tool (such as FrameMaker). Then the technical writer uses a conversion tool (such as WebWorks) to generate multiple outputs (such as PDF and online help).
While effective, this workflow suffers from one major flaw — it requires that all content be placed (or converted) into a single format; in this example, FrameMaker. Consider the multiple SMEs that may contribute content to a single deliverable:
- A developer may write a technical specification in MS-Word.
- A sales person may create a web page in Dreamweaver.
- A marketer may create a whitepaper in Acrobat.
The technical writer must consolidate this content (either by using the cut/paste method or some sort of import/conversion tool) and and his own original editorial content. If one of the SMEs changes their content, the change must be "pushed" to the technical writer (noted by the dashed lines in the following figure) — effectively duplicating what the SME has already done. In this process, although there are multiple content sources, there is only a "single" source that creates the content.
Figure1. Traditional Single-Sourcing Process
Each content may be stored in a centralized repository for backup and version control. However, the content is stored in its native format — making it nearly unusable to anyone with the same software. (Ever try importing portions of a MS-Word document into FrameMaker?)
There must be a better way.
Consider an alternative: multi-sourcing. Here, instead of using a single source (FrameMaker), each content provider works with their own content, in its own native format, and simple adds their content to a CMS. The following figure illustrates one possibility.
Figure 2. Multi-sourcing Possibility.
Here, each content provides works on their content in its native format, but stores the content in the repository as XML. This of course, requires that each application have the ability to fully round-trip the XML files. The technical writer, like the other providers, is able to use (or link to) other content directly, by using the the XML file. No more copying/pasting!
A content management system (CMS) takes the necessary XML "pieces" from the repository and creates the specific deliverables. These deliverables (in their final form) could even be stored in the repository for version control.
The biggest implications of this type of process?
- EVERYONE becomes a content provider
- Tool transparency
- The technical writer changes from "publisher" to "content provider"
The biggest challenges of this type of process?
- How can MS Word serve as the Subject Matter Expert's authoring tool, when Technical Writers need valid XML?
- Everything in the repository should be stored as (valid) XML. It will be up to the contributor's specific tool (e.g., MS-Word) to handle the conversion from XML to its native format (and then back). (Rick)
- Should the Documentation Team extract the MS Word info and bring it into a single-source environment, what happens when the "source" MS Word files are updated?
- I (Rick) propose no. This is the extra conversion step that I'm trying to avoid. The CMS publishing tool "automatically" does this.
- What happens when you need to use/update/reuse parts of the MS Word files?
Additional discussion coming...
Contributed by Rick Sapir. Some rights reserved.
Challenges contributed by Dainis W. Michel edits.
{SUBMIT()}{SUBMIT}
