Some tech writers are wiling and able to shift to the new information management practices. (Some of those REMAIN artists. They need not change identity; they may just compartmentalize their profession from their art.) Others will not. Just as young people like my psychiatrist friend may choose not to go to medical school, some current tech writers will change careers when the market gets better.

From an organizational development prospective, I don’t think it’s feasible to take a whole occupation’s worth of mid-career and senior-level individuals selected for one set of personality preferences and work styles and expect them to adopt an entirely different set. Of course that’s a challenge for today’s managers! Squeezing blood from turnips isn’t the solution, in my opinion.

Credit for the title, however, belongs entirely to Scott. My original title was the much more prosaic “The Case for Inline Linking”. I rather fear that Scott may have been trying to get me into trouble with the DITA community, but I do have to agree that “rethinking inline linking” does trip off the tongue.

The other cases are things with no canonical names, and things with canonical names that authors are not familiar with (like topic ids, for instance). My preference is to avoid asking authors for canonical names that they are not otherwise familiar with. This is almost always possible, and a huge boost to productivity.

For things that have no canonical names of their own, the options are to invent canonical names (which, since they are invented, authors would not be familiar with) and to use a table of equivalents (or something equivalent) to match the various possible terms that the authors might use. The table of equivalents does have to be maintained, of course, but this can be done outside of the writing flow. To me, one of the key to achieving writing quality and productivity is to avoid breaking the writer’s flow with system tasks, so I consider this a big win, despite the need to manage the table of equivalents.

And yes, I agree that not every piece of content can be written this way. There is no one universal solution to the authoring challenge. Indeed, the majority of content will always be unstructured and unmanaged. We will always have to rely on content intelligence as well as intelligent content.

Boy, this discussion has drifted from the proper place of links in a topic! It does sort of illustrate how we move from topic to topic, which I guess says something about the role of links in content, though what it says may depend on how you feel about discussions that wander off topic. I love them.

Thanks, Scott, for providing the forum for Mark’s post and all this conversation. Cheers!

What a thoughtful and thought-provoking analysis. I love the way you always question accepted “wisdom,” combining research with common sense and an open, inquiring mind. (“Before information consumption, comes information seeking.” Etc., etc.) Clear, deep thinking–and beautiful writing to boot. Keep it coming!

Marcia

Similarly, the information needed to describe the use of many software tools and products has its own structure if you make the effort to discover it. This can make writing new content much more efficient. Many times, the organization and structure of books and topics (read chapters in traditional FrameMaker environments) is left entirely to the writer to invent each time even when similar types of information are known to be needed.

At my last employer, I was authoring in a structured XML environment to document an embedded OS that was itself configured in XML. I used topic types that were highly structured to match the content needs for each configuration and programming task. The topic structures were instrumental in efficiently extracting the necessary information for each task from the development team. Without the topic type specificity, writing each topic would have been reinventing the wheel each time. This type of topic structure also makes finding information efficient for the audience as they are able to rely on familiar and reliable organization in the documentation.

Similarly, processes need to be streamlined and designed to make delivery of the information efficient. Too many times, technical publication departments rely on home-grown or commercial tools and processes that were cobbled together over time and no longer fit the needs. This often leads to many manual work-arounds and hours of wasted time to make sure the content deliverables fit into the tool stream. We sometimes hang on to what is familiar long past its actual usefulness.

Regarding rules, I’m sure you’re right that there could be a rule written to describe any reasonable inter-topic relationship. But I’m yet to be convinced that this is the best solution for every team in every situation. For some teams, an all rule-based linking system could be just right. For others whose needs were different, it might introduce another technical bias – the tail wagging the dog again. In this case perhaps a hybrid system could be better. I’ve seen metadata-based linking work well alongside ID-based linking.