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

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

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

“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…

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.

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

Eric

“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