Thoughts on “Context-Sensitivity” and Dynamic Output Reconfiguration

I wrote the 2010 trends article for STC Intercom magazine. One of my predictions there was the emergence of “dynamically reconfigurable output,” which I took from an item in the News Digest section of an issue of ComputerWorld from around 2005. That item’s take was that XML, and xMetal in particular, could let us do cool things, such as creating online information that was sensitive to its “context.”

If you’re in tech comm, you may have been doing context sensitive online help systems – that know where you are in the application and display only relevant information – so what’s the big deal? But that wasn’t the idea of the item in ComputerWorld.

The idea there was online information that changed depending on its context, the example being an aircraft service manual whose content changed automatically based on whether the temperature was above or below freezing. (So this manual served two “audiences”.) Or consider smart phone and mobile device apps whose display mode shifts from portrait to landscape automatically, depending on whether the device is horizontal or vertical. (So this manual also serves two “audiences”.)

From tech comm’s perspective, this idea of “context sensitivity” has two interesting angles.

First is simply the idea that “context” means different things to different people and we in tech comm can no longer take that meaning for granted. (The article Context Matters by Beth Schultz, in the September 21/28 2009 issue of ComputerWorld, discussed “context” as the tagging of equipment in a hospital to define its location and make it easier to find. Anyone hired to do “context sensitive help” for that hospital who assumed the standard meaning of “context sensitive” would run the risk of creating the wrong project.)

Second, and odder, is the idea of dynamic reconfiguration as a means of serving different audiences, like below-/above-freezing or horizontal/vertical in the examples above. Such situations are easy to handle using today’s help authoring tools – create one project and, using conditionality and other single sourcing features, generate one version of the output for each audience. We then leave it to some other mechanism to direct users to the right version of the help depending on the circumstances – temperature, physical orientation, etc.

The problem with the multi-output approach is that it’s cumber- some. We have to create one output per audience, which can become challenging as the number of outputs grows. Better to create one output that can modify itself.

We’re slowly heading there. Mark Logic ran a webinar in October 2009 entitled “Dynamic Delivery Is Where It’s At: Custom Documentation From Multiple Formats” that offered some possibilities. And I’ve been told about various proprietary, code-level experiments in online help authoring. I’m just not aware of any developments at the help authoring tool level yet.

If you’re aware of any work on dynamic output reconfiguration using help authoring tools or as proprietary, code-level experiments that can be discussed, I’d love to hear about them on general principles, or possibly as an Intercom column or, if you can get to me between before March 19, possibly as a proposal for the Beyond the Bleeding Edge session at the annual STC conference.