Saturday, December 8, 2007
Filtering Content
There has been a discussion on one of the lists about filtering content in output from DITA. There are many shades of grey, or gray. We have settled on using the topicref as the basis for the filtering.
We have organized our content into sections, which works very well for our stuff, and each writer is responsible for various sections (in their role as content author). We collect these topics into maps that will be referenced by the map created for a particular instance of a product manual.
Because the section maps filter the content (I can't imagine trying to pull together the thousand odd topics required to build a basic manual), the content author uses them to determine which products carry which features (which can change over time). The topicref, therefore, always points to a topic that exists. The topics are not filtered out by the attributes of the topic.
Within each topic, we may have sections that do not apply to a product, so those are filtered by their product attribute.
The topics, some people have argued, should be as self-describing as possible. Now, for us, the features trickle through our product line. It is rare that a feature is truly product-specific for any length of time. Also, we store our content in a content management system and the topics have metadata that is applied there. So, we can use that metadata to more fully describe the topic.
For the information architect, a role we all play at one time or another, the sections they pull into the final manual are like black boxes. We content authors ensure the information is filtered correctly, structured correctly, and is complete for the product at hand.
When our product teams whisper, the day before the deadline, that a certain feature is pulled, well, we change one attribute in one location to get the result we need.
We have organized our content into sections, which works very well for our stuff, and each writer is responsible for various sections (in their role as content author). We collect these topics into maps that will be referenced by the map created for a particular instance of a product manual.
Because the section maps filter the content (I can't imagine trying to pull together the thousand odd topics required to build a basic manual), the content author uses them to determine which products carry which features (which can change over time). The topicref, therefore, always points to a topic that exists. The topics are not filtered out by the attributes of the topic.
Within each topic, we may have sections that do not apply to a product, so those are filtered by their product attribute.
The topics, some people have argued, should be as self-describing as possible. Now, for us, the features trickle through our product line. It is rare that a feature is truly product-specific for any length of time. Also, we store our content in a content management system and the topics have metadata that is applied there. So, we can use that metadata to more fully describe the topic.
For the information architect, a role we all play at one time or another, the sections they pull into the final manual are like black boxes. We content authors ensure the information is filtered correctly, structured correctly, and is complete for the product at hand.
When our product teams whisper, the day before the deadline, that a certain feature is pulled, well, we change one attribute in one location to get the result we need.
Subscribe to Posts [Atom]
