As Noz rightly points out, I may be looking at this through a single myopic lense and taking a polemic stance of “us and them.” But from my point, a major change is coming that will change all the rules. And I don’t make the rules, I just try to exploit them.

–Cloud computing. Go see any roadmaps for MS, IBM, Google, HP, Amazon and others and tell me a big change is not underway already. This means big changes for all software and information developers.

–Web 2.0. People aren’t coming to your site, you have to go to them at their congregation points. Information and data need to be open and accessible in the future.

–The Symantec Web. The major reason for using structured content is to mark up content meaning and put it together dynamically for readers/users/researchers.If this isn’t done, I don’t see a reason for anyone to take the time and money to move to single sourcing. I do believe in dynamic single sourcing practices, however, using symantec tagging and dynamic composition. I think those organizations currently structuring content have a leg up on those who don’t, but I would not start a topic-based, single-sourcing, DITA, structured content strategy until the question of publishing and interacting with all other content and emerging products based on cloud APIs and backend resources.

–Information turns over 25 percent annually. With this much change, do internal, closed, single sourcing practices really pay for themselves?

I will try to lay out my views fully in my next posting.

“No, sir, your clothes are lovely! Buying some my new pieces from my fall collection would realise the ROI on that outfit!!”

I go to a lot of content-related events. Every year I get to hear various from-the-horse’s-mouth success stories on single sourcing and DITA. Obviously, if you’re presenting at a conference, chances are you have something positive to say about you project. From my experience you’re generalising in a way that’s quite over the top. I have so many different point-by-point counter arguments to this that I can’t find a point of entry.

I have to say main two things: 1) You seem to take an ‘us and them’ approach:
“The main issue for me is between authoring static in-house documents using single-sourcing methods before publishing, or capturing information sources dynamically after publishing from online social networks, linked data sources, and knowledge mashups . ”

These are not two mutually exclusive alternatives. Modern intelligent content solutions combine these approaches for the benefits that they yield, and for regulated industries like Pharma, Gov, Medical Devices, Oil and Gas, Military, Microprocessors etc. etc. etc. only a bipartisan solution can be allowed to work.

So, I call your ‘antiquated thinking’ jibe and raise you a ‘throwing the baby out with the bathwater’ comment that just because there’s valuable new concepts and technologies adding to the tapestry of our industry, like those you focus on on your site, that doesn’t mean that the buzzwords of yesterday are somehow to be dismissed and ridiculed as obsolete

2) a lot of this seems to be predicated on the ‘it’s hard so let’s not do it’ concept. A bit like “snowboarders tend to fall as they’re learning so let’s not bother trying”. Anyone who said it’s easy is lying or selling something. The question is then whether it’s worth it. You think not, many agree, many don’t. The boat has not sailed by any means on that discussion.

I look forward to an opportunity to lock horns with you about this in future.

- Noz

My take-away points:
– One-to-many publications require a single-sourcing authoring environment. Internal single-sourcing of content is required when delivering product doc for multiple products from a common doc set. Like the code, UI skins, etc., the doc needs to have multiple builds requiring conditional text and topic reuse strategies. (Marc’s strategy)

–Reuse of common doc topics for training materials possible. I have never seen doc used as part of training or in professional services engagements. Mostly because of lack of will or poor execution or most likely bad politics between depts. But I do think Karol’s scenario is another good argument for internal single-source authoring.

–Both Marc and Karol’s doc sets are inside-out reference and feature-based guides for specific products. This is the norm. When I say “inside-out,” I mean that it starts with the PRD requirements, through development and testing to provide feature-based reference and fundamental tasks. This is in contrast to the “outside-in” approach of defining customer needs and practices. This is a distinction I am also making nowadays. I think it is one of the major changes occuring in tech writing.

–Real-time updates? There’s also something to be said about Karol’s use of conditional text and reuse of content to react quickly to different publishing needs quickly. I need to think on this.

–It occurred to me that with content already structured, Marc and Karol are all set up to move their doc sets to the web using semantic markup and specific ontologies for linked data and mashup delivery, when and if their products and services move out to the cloud.

–When it comes to single-sourcing, don’t throw out the baby with the bath water. Single-sourcing practices and topic based authoring tools can serve the same purpose for writers as the Integrated Dev Environment (IDE) does for developers. FM, Flare, Blaze, Robohelp serve as the tech writer’s IDE in setting parameters, reusing core routines (topics), and building deliverables.

My questions:
–Do Marc and Karol also use topic-based writing practices? With distinct concept, task, and reference topics sequenced for delivery in multiple formats? (You can have unstructured content and still single-source doc sets.) Do any of you use these basic DITA or Docbook DTDs?

–I am assuming Marc does a lot of conditional text to publish multiple product guides. Is he also using structured text mark up with XML and a standard or custom DTD?

My Comment:

I think it is clear that single-sourcing of doc has a role in authoring, organizing, and building doc sets of closed, internal content. For writers, I see structured XML content, reuse of topics, and single-source publishing as I see MS Visual Studio, Eclipse, JBuilder, or other coding IDEs for developers.

Which brings up my main issue:
If the products supported by Marc and Karol do not have pressure to move to web services and protocols, then why should the doc move from a static Web 1.0 delivery of posted pdf manuals and integrated help to Web 2.0 marketing, collaboration, and content integration? I don’t think it should.

I am not sure of the product challenges for growth for any of these products or to defend competitors. I am assuming that like MS Office, Adobe, and other apps large and small, the Google online apps phenom is putting pressure on product managers to look at new in-the-cloud services.

But until that day, why change anything? The internal single-sourcing repository stands as the sum total of product information needed to turn a profit. And the products only need to be updated as features are updated. As long as these conditions stay in place, then I agree that in-house authoring using single-sourcing practices and tools is the only way to go.

But of course my next question is: How long can any software product resist moving to service oriented architecture and open cloud computing and still survive?

I guess what I am trying to say is that doc writers have the same pressures, opportunities and uncertainty as the developers as open web protocols, social networking, personalized content, and Web 2.0 moving to Web 3.0 appears on the horizon.

–Lean single-sourcing: I agree that you can use single sourcing on projects with limited use. But most companies I worked for made it across the board practice, thereby eliminating any advantage.

– repeatable content. For help files with basic conceptual, task, and reference information that needs to be reused and has a longer shelf life (I guess product life). I see it effective for those docs that come with my HP or Dell or Apple laptop. But this is also the stuff I immediately throw out with the box. It is required but low value doc. It changes incrementally but much of the content is used by multiple products.

–translation of low value content. If you have boilerplate type of content (as described above) then it makes sense to have it translated and then reused. That saves a lot of money. But it is low value stuff. Take for instance your Apple Mac help files. That level of constrained content about iLife apps and the Mac OS needs to be shipped with the product as baseline content. It could be single sourced quite well–as they do. But then again, this is staid information for the most part and Mac looks to other web sources for good content.

–High value content. Information that I am looking for in using iLife apps, such as GarageBand best practices and integration with certain types of MIDI connections will not be found in the low value content (help files or shipping doc). This is the type of content that I find on the web from users. How can we single source this content? Using mashups and linked data.

Single sourcing in the cloud after publishing. In-house authoring of content is very limited. The real value is from the sociale interaction posted as web comments. Why can’t we single source from the cloud instead of the corporation’s database?

I would like to know more about the situations where single sourcing works. Is it in basic product doc? Is it for a single author building a respository of topics they can order and reuse on a personal level? Is it going to synch with the cloud computing and cloud retrieval of content that is coming?

Just a few random thoughts.

It certainly takes an investment of time and money, but implemented properly, single sourcing does work.