RSS FeedArticles
Saturday, February 02, 2008
Content Managers: Extract the Full Benefits of Structured Authoring
By Eric Kuhnen, special to The Content Wrangler
If you manage a technical publication department, search for the phrase “assembly line” in Wikipedia and study the paragraph entitled “Overview: a culmination of many efforts.” In the middle of that paragraph is the following sentence:
...[T]he way that most manufactured products were made was that a single craftsman or team of craftsmen would create each part of a product individually by hand, using their skills and...tools..., and assemble them together into an assembly, making cut-and-try changes in the parts so that they would fit and work together....
If they saw only that sentence, most technical publication managers would mistake it for a description of today’s method for creating technical content. In reality, it’s a description of industrial manufacturing before the advent of the assembly line. What is in common practice in the early twenty-first century for creating technical content drove up automobile manufacturing costs in the early twentieth century, keeping cars out of reach of working class society. The solution to the problem of cost was the introduction of the assembly line with all of its inherent cost efficiencies and volume scalabilities.
The twentieth-century assembly line is the logical progression of earlier advances in general manufacturing. Technical developments that gave rise to interchangeable parts enabled serious consideration of supply logistics and factory layout. The result was manufacturing process that dramatically reduced automobile production time, unit cost, and human resources. The assembly line was patented by Ransom Olds in 1901, but popularized by the Ford Motor Company in 1913. By 1930, more than 250 automobile companies that had not adopted the assembly line were out of business.
In a similar vein, the rise of structured authoring techniques and standards signals a fundamentally different process for manufacturing technical content. That process inevitably takes on the characteristics of an assembly line, particularly as to segmentation and specialization. Furthermore, it is as unorthodox to today’s technical publication craftsmen as the automobile assembly line was to automobile craftsmen before 1901. Still, it’s a technical publication manager’s job to build content at the lowest unit cost and at the highest volume. You can watch your group’s functions become outsourced to lower-cost craftsmen overseas, or you can reshape the world of technical content manufacturing and turn the technical publication department into your company’s distinctive competitive advantage. To that better end, this article explores how a technical publication manager could set up a publication assembly line using recent advances in structured authoring.
A Few Recent Advances
Recent advances in structured authoring owe much to the groundwork in markup language development laid over a forty-year period. Generalized Markup Language was a 1960’s-era invention by IBM to separate the act of creating text from the act of formatting text. Scribe, of early 1980’s vintage, further extended this separation through formatting styles and a formal grammar for controlling the use of descriptive elements. In 1986, Standard Generalized Markup Language (SGML) burst onto the scene as a full-fledged meta-language, its flexibility serving as the basis for more useful markup languages such as Hypertext Markup Language, Extensible Markup Language, and DocBook. Naturally, the entire history of markup languages cannot be reproduced here, and some details are still hotly debated around the water cooler. Still, the presence of these later markup languages rests squarely on the shoulders of previous work.
Despite advances in markup languages, the reasons for their current adoption within large organizations occludes their hidden potential to enable highly efficient structured authoring. Here’s why—No one incorporated assembly-line manufacturing into the design these markup languages. Indeed, the principal reason for the development of SGML was the preservation and exchange of machine-readable documents across several decades. No thought was given to enabling efficient text creation. Its more popular successor, XML, was invented to retain the essential power and purpose of SGML while streamlining some of its flexibility. Even DocBook’s design (as an SGML application--now an XML application--for describing technical documents) did not incorporate any notion of text as comprised of interchangeable parts--the foundation of modern assembly-line manufacturing. Naturally, then, there were no serious attempts to re-think the way a technical publications department operates.
The introduction of the Darwin Information Typing Architecture (DITA) enables a shift in the technical publication paradigm. Its basic design--dividing content into small, self-contained topics--prompts an author to view a document not as a series of chapters and related sections but rather as a collection of separate topics. By drawing upon a supply of these pre-written, self-contained topics, it is arguable that a writer should be able to produce a greater overall volume of content than would otherwise be possible if it was necessary to recreate this material each time it was needed in other documents. Indeed, that is the theory and much of the current practice around the use of DITA.
DITA’s design for content reusability is akin to an interchangeable part in manufacturing. In industrial manufacturing, a part is considered interchangeable if each and every copy is identical to the original. In content manufacturing, an interchangeable part is a reusable, self-contained topic. When the topic is needed in a new publication, the writer inserts a pointer to the archived original; no cut-n-paste; no editing to fit context. DITA gives technical publication managers one of the key technologies to establishing a true content assembly line: the interchangeable part.
Another key “technology” is the practice of minimalism. Minimalism favors short, task-oriented content over long, narrative material. It is surprisingly difficult to master because it requires an economy of words and a conscious suppression of one’s own writing style. The need for word economy gives rise to approved technical vocabularies--a reasonable necessity to maintain accuracy--but also recommended descriptive terms, a point of sharp division among authors. Eviscerating any traces of individualism reduces not only cliches and colloquialisms (these are difficult to transport across countries and languages) but also certain constructions that add variety to otherwise banal technical prose. Technical writers who think of themselves as craftsmen or artists may resist some elements of minimalism, but its foundations are rooted in the science of Instructional Design and its virtues are described extensively by Dr. John M. Carroll.
Minimalism is essential in two ways. First, its two primary elements have analogs in modern assembly line techniques. That is, word economy is similar to the idea of repetitive movements, while suppressed individualism in text calls to mind the factory-worker concept.
Second, a “minimal” topic has a higher opportunity for reuse elsewhere because there is very little extraneous material to become ensnared in mismatched contexts. Said another way, long, narrative material exists to connect one idea to another. Reusing that text means ensuring that the “connective tissue” contained in the narrative matches the context of the surrounding material. Minimalist topics, devoid of narrative text, have almost no “connective tissue” at all. It is comparatively easy to drop this material into new contexts.
Structured Authoring in an Assembly Line
With these technologies now available, a technical documentation manager has the essential ingredients for assembly-line structured authoring. First, agree to some ground rules:
- No single person writes a whole paragraph of text. The work of writing a paragraph is broken up into specialty tasks, one for each component of a well-written paragraph.
- Quality assurance now includes “readability” at the paragraph level to check for semantic problems arising from multiple authors contributing one sentence each.
- Subject-matter experts (SMEs) contribute material only as lists, notes, steps, or design notes. They don’t contribute finished sentences. SMEs are like automobile design engineers and very much unlike manufacturing engineers. Design engineers are very good at describing how a thing works, but it’s outside their training to describe to build it efficiently. That’s what manufacturing engineers do. Likewise, SMEs have great technical knowledge about a thing, but they are not experts in assembly-line structured authoring.
Second, study industrial manufacturing. A modern assembly line is built around discreet, repeatable tasks, not around each author’s knowledge of specific subject matter. This realization drives new thinking about the creative process in writing, who to hire, and how to construct workflow.
Start with the creative process in writing. When content creation is viewed as a manufacturing problem, then the assembly line is the worst place to find thoughtful, creative individuals crafting topics that blend seamlessly into the fabric of the overall document. Why? Because the assembly line grinds to a halt when specialized tools don’t work, or information from SMEs comes in late, or even when the writer misses an important collaboration meeting . What is needed on the content assembly line are writers who know how to build single sentences from a few fragments of information and who can do this all day long. A structured-authoring assembly line is not so much a “creative” environment as it is an assembly environment. In fact, the whole “line” is really just a collection of assembly tasks where each task introduces an interchangeable part into the partially constructed document. There are tasks for:
- Building document outlines, sub-outlines, sub-sub-outlines, etc.
- Massaging SME input into standard forms (i.e., building the beginnings of an interchangeable part); standard forms might be lists, paragraph fragments (no topic sentences), figures, images, tables, etc. There would be a separate task for creating each standard form.
- Writing topic sentences based on standard technical forms
- Writing concluding sentences based on topic sentences
- Writing captions for figures, images, tables, etc.
- Writing section, chapter, and document titles
- Building tables of contents
- Building indexes
New Skill Sets; New Hiring Needs
All of these are highly repetitive tasks requiring distinct skill sets, which requires new thinking about whom to hire. For example, a document manager would look for someone with outlining skills to perform the document-outline tasks. Since his only job would be to build document outlines all day long, it would be best to hire someone who is good at recognizing topic “flow” even though he may not be very good at punctuation. A similar line of reasoning would inform the screening policies for other roles and tasks. The need for expensive craftsman who can perform every function would be replaced by the need for inexpensive laborers who understand enough of the source language to be competent in their jobs.
Defining New Workflow
Finally, reexamine workflow. The manager of a content assembly line needs to rebuild the workflow to favor the assembly of information components, not finished topics. Finished topics are what come out of the assembly line. There would have to be a multiplicity of quality assurance steps to ensure good “fit and finish” in the writing and adherence to overall “manufacturing” quality standards. There’s nothing revolutionary about building workflow, except that what constitutes a “step” in the workflow would be very different than what is typically found today.
Naturally, documentation managers have to weigh the benefits of a content assembly line against the needs of their individual contributors. Creatively minded authors would balk at the suggestion that they conform to this kind of assembly-line structured authoring; I would, too. Business, though, is about fielding the best team, and there is no arguing that the level of control, accountability, and efficiency found in a structure-authoring assembly line would improve dramatically even as the unit costs to produce technical documentation would drop and the scalability would increase. The result would quite probably be a distinctive competence in the market because the technical publications department integrated with the overall product creation process without relying the institutional knowledge and limited production capacity of irreplaceable craftsmen.
Conclusion—Content managers know that structured authoring is by no means new, but they have yet to realize the full application of its invention. These untapped benefits reside primarily with content manufacturing, or the application of assembly-line manufacturing techniques to the process of content creation. Content manufacturing remains an unexplored subset of content creation because it represents a fundamentally different style of thinking by content managers. However, if the current rise of DITA and minimalism are to have lasting benefits, it will be through innovative technical documentation managers recognizing the suitability of these technologies to the problem of content creation to build some of the world’s first true content assembly lines.
About The Author
Eric Kuhnen is Managing Partner at Focal Partners. He can be reached at .
Filed under: DITA : Technological Innovation
Comments
By Tony DaSilva on February 4, 2008 -- 3:13pm
Mr. Kuhnen writes:
“Even DocBook’s design …did not incorporate any notion of text as comprised of interchangeable parts”
Not true, actually.
Nothing prevents you from writing interchangeable, topic-oriented content with DocBook. It provides you nearly everything you need to write just the sort of granular, topic-oriented content Mr. Kuhnen believes is reserved solely for DITA. With DocBook, you can detail a task, reference information, or a concept, recurse the heck out of it within your document (online help, web page, pdf, or whatever), reuse it in other documents, or stick that bit of content in a CMS and do all those things you’d expect that system to do.
Of course, there’s more to writing effective topics than choosing one schema over another. You can write topic oriented content in DocBook or write narrative content in DITA. You can be as strict or as loosey-goosey as your heart desires. While DITA makes a rather good stab at enforcing the concept - task - reference model, it’s is only as strong as your willingness to obey those restrictions. There’s no invisible hand compelling you to write tidy, compact, standalone topics - no matter which schema you use. That’s a skill (bordering on a craft, but not quite an art) to be learned. It’s an approach that requires planning and discipline.
Mr. Kuhnen’s assertion that DocBook is unsuited for topic oriented content is demonstrably false. There may be plenty of good reasons to choose DITA over DocBook (maps, specialization, hanging with the cool kids), but topic orientation is not an item where the two standards offer much of a difference.
As for his breathless enthusiasm for a Taylorite utopia where individualism and creativity is “eviscerated,” it seems to this sometime craftsman – sometime laborer – sometime manager, that Mr. Kuhnen understands the work of technical communicators about as much as he does DocBook and DITA. That he triumphs a long surpassed model of industrial organization raises even more serious questions in my mind concerning his fundamental understanding of the modern enterprise and its stakeholders.
Tony DaSilva
By Eric Kuhnen on February 5, 2008 -- 4:56pm
I agree completely that topic-based authoring can be accomplished within DocBook. Indeed, the credit owed to DITA for popularizing topic-based content creation does not preclude the use of other markup languages for that same purpose. For an excellent discussion on implementing topic-based authoring in DocBook, I recommend Norman Walsh’s thoughtful blog entry entitled “DITA for DocBook” written October 21, 2005. Be sure to read all of the comments.
By Eric Kuhnen on February 5, 2008 -- 5:13pm
Sniping about relative merits of DITA and DocBook vis-a-vis topic-based authoring is beside the point: DITA popularized the technique in a way that DocBook did not, just as the C++ programming language popularized object-oriented programming in a way that earlier languages such as Modula II or plain-old C did not. It is entirely possible to build object-oriented programs in these earlier languages, but they did not *lend themselves* to that programming technique. Back the main point of all of this: DITA’s “encouragement” to build topic-based content qualifies it as a building block for assembly-line content manufacturing. At some point in the future, the art of assembly-line content manufacturing will expand to the point that a new markup language needs to be invented that incorporates assembly-line control structures of some kind in its design. It will have been possible to get by with DITA for awhile, but its own design limitations will eventually become apparent, a new language will be invented, and with that new language will come even better ways at looking at the content assembly-line. And, we will be having this discussion all over again with those who argue that it can all be done in DITA.
Eric
By Eric Kuhnen on February 5, 2008 -- 5:35pm
In response to both comments about the out-dated nature of the 1913 assembly line, I wish to draw a parallel between the discussion and debate preceding the writing of the United States Constitution and the article’s proposal that draws heavily on the first manufacturing assembly line. The Founding Fathers of the United States themselves drew heavily upon the Roman and Greek models for government, using them as the baselines for the bicameral legislature but adapting things to the then-modern era. Similarly, Taylorism is no utopia, but it is a beginning. Newer ideas such as bottom-up involvement, the total-quality management approach of Dr. W. Edwards Deming (embraced so widely and thoroughly in Japan), and other such improvements to transfer more “thinking” to the assembly line worker are all worthy of consideration when building a content assembly line. But you have to start from a prototype and work out certain details first.
Finally, Mr. DaSilva may raise any number of questions as he sees fit. The trends, though, are unquestionable; content creation jobs are moving to low-cost locations, and senior business managers care little for the bruised egos of their departing content craftsmen.
Eric
By Tony DaSilva on February 6, 2008 -- 11:45am
Clever, clever, Mr. Kuhnen. But just whose ego is bruised, I wonder?
By Emma on February 6, 2008 -- 12:08pm
I disagree with Eric’s assessment that business managers care little for content - in fact, the smarter companies are realizing that good content - timely content - personalized content - delivered when users need it, in the way users need it - is crucial to corporate survival. That’s what content management is all about - managing information as the valuable corporate asset that it is.
However, as long as people such as Eric Kuhnen are around, who continue to believe that content - information about products and services, and how to use them - is a COST to the organization, rather than an asset, we’re in for a long slog uphill.
Content - good content - is not like computer code, and cannot be assembled that way, for one simple reason: human beings are not computers. Rather than insist on applying an outdated - or even an updated - industrial model on an essentially human concept: communication, we should all be thinking about the ways in which people gather, interpret and act uponinformation. For that, we need to turn to the cognitive sciences, and not to mechanistic models based on a binary world. Yes/No and Black/White may work for computers, but the world of human interactions is way too complex for that kind of simplitic thinking.
By Eric Kuhnen on February 6, 2008 -- 2:11pm
Emma’s thoughtful reply contains a number of gems worthy of closer examination. To wit:
“I disagree with Eric’s assessment that business managers care little for content - in fact, the smarter companies are realizing that good content - timely content - personalized content - delivered when users need it, in the way users need it - is crucial to corporate survival. That’s what content management is all about - managing information as the valuable corporate asset that it is.”
What I find fascinating about this description of what senior managers want--good content, timely content, personalized content, delivered when users need it--is that these are *manufacturing* terms. In fact, if I were a technical content manager attempting to pursuade senior business managers to fund a prototype content assembly line, I would use your exact terms.
More to come…
By Eric Kuhnen on February 6, 2008 -- 2:15pm
To Emma’s comments: ...that’s what content management is all about - managing information as the valuable corporate asset that it is. However, as long as people...continue to believe that content - information about products and services, and how to use them - is a COST to the organization, rather than an asset, we’re in for a long slog uphill.
The content assembly line is *not* an argument against the value of information. It is an argument about the *cost* to produce that information in greater quantities and at equal or greater quality than is currently possible under the “craftsman” manufacturing model.
So, when rebuttal arguments to the content assembly line sound like, “...people...continue to believe that content - information about products and services, and how to use them - is a COST to the organization, rather than an asset...”, then there is some blurring of the discussion between the value of information and the cost to produce that information. To be certain, there is no question that technical information about products, services, and the best means to using them, are *assets* to an organization. However, if one company can produce a variation of that asset at cheaper overall cost and comparable quality when compared to another company producing a similar asset, the first company will do better in the market. Senior business managers are always looking at ways to cut the costs to produce quality assets. My argument to technical content managers is: give your senior managers another option (besides outsourcing) that drives down costs, maintains quality, increases capacity, and bequeaths a competitive advantage to the organization--build a content assembly line.
Eric
By Eric Kuhnen on February 6, 2008 -- 2:28pm
Emma responds truthfully: “Content - good content - is not like computer code, and cannot be assembled that way, for one simple reason: human beings are not computers...”
I agree with the foregoing, but I don’t see its relevance to the discussion. Software programs are instructions--written by humans--for the correct operation of a machine toward a specific output. Similarly, good content is also a set of instructions--again, written by humans--for the correct understanding of a human in pursuit of a specific outcome. Both sets of instructions are written by humans, and a discussion about a content assembly line is a discussion about the act of writing those instructions. Furthermore, the article and follow-up comments have always centered on the manufacture of technical content that is read by humans, so citing the distinction between humans and computers as an implied rebuttal against the manner of constructing good content seems irrelevant. I might have responded: “Cars--good cars--are not like computer code and cannot be assembled that way for the simple reason that cars are not computers,” and then asked whether it was the existence of cars or computers that argued *against* the content assembly line. So, I don’t see how the original response is relevant.
Eric
By Eric Kuhnen on February 6, 2008 -- 2:34pm
Emma writes: “...we should all be thinking about the ways in which people gather, interpret and act upon information. For that, we need to turn to the cognitive sciences...”
The preceding point argues in favor of content *design* and the way that content is consumed by the reader, not the way content is *manufactured*.
To take a larger view of this debate, the underlying premise of the article could be the separation of design from manufacturing, which I suspect to be the truly unsettling point. If someone believes that it is impossible to separate content design from content manufacturing, then the content assembly line makes no sense. But the current practice of craftsmen-driven content assembly moves toward outsourcing to lower cost craftsmen who--by the way--would be similarly improved in their skill and output by discussions about the ways in which people gather, interpret and act upon information. Therefore, to counter the move to outsourcing, the fundamental “impossibility” of separating design from manufacture must itself be tossed out in favor of the notion that content design *can* be separated from content *manufacturing*, which then opens the door to thinking about a content assembly line. The article simply looks at the tools of structured authoring with that assumption in hand.
Eric
Recent articles
Moving Legacy Content To XML: Affordable, Self-Service Analysis/Modeling Tools Needed, Survey Says
Ware are You? Web Content Delivery Strategies
Information Architecture for My Office
Plain English Videos From Common Craft Make Understanding New Technology Easy
U.S. Federal Government Silences Typo Spotters; Forces Them To Stop Encouraging Others
Twing.com: Searching Online Forums and Communities Just Got Easier
Subscribe: Direct Inbox Delivery
Get The Content Wrangler Newsletter delivered straight to your home or work Inbox. It's full of content goodness.
By Emma on February 3, 2008 -- 4:58pm
Very interesting analogy - and unfortunately one that real manufacturing companies have long since discarded, because the repetitive nature of the assembly line tasks, and the level of system knowledge required to get a high-quality end result are at odds with one another. And those tasks that remain simple and repetitive have long since been taken over by robots. To take Eric’s analogy to its logical conclusion is to suggest that eventually - if we can program them adequately - computers can take over from human writers. In theory this is all well and good, but it ignores the one thing that only humans can do: make good situational decisions. And that’s because human beings - unlike computers - don’t actually make decisions based on information input and processing; they make decisions based on pattern recognition. I think I’m going to have to write a more extensive article about this, and submit it to TCW.
Until then, suffice to say that the example Eric uses - auto manufacturing - is already outdated; in the most successful auto manufacturing companies in this day and age (Toyata, Hyundai, Nissan - and to some extent Daimler-Chrysler) cars these days are made by teams of skilled workers, who have multiple areas of expertise, and who work closely with engineers, designers and marketers. No more monotonous tasks with no connection to what came before, or comes after. As Tom Davenport is quoted as saying: “These days, even in manufacturing, people make more decisions than things”. And when it comes to decision-making, we can no longer speak of task-driven workers. They are now knowledge workers. This discussion should not be about dumbing down and commoditizing technical writing; it should be about developing ways to harness the value-add of human decision-making. What to say, and how to say it, to maximize understanding.
More to come ...