Diff for Why is the result often a million little pieces even though DITA does not encourage authors to chunk information in such a way?
In pursuit of the ultimate techCom information architecture
Tue, 2013-05-07 17:05 by Jonatan Lundin | Tue, 2013-05-07 17:09 by Jonatan Lundin | ||
---|---|---|---|
next diff > | |||
Changes to Body | |||
Line 3 | Line 3 | ||
</p>
| </p>
| ||
<p>
| <p>
| ||
- | <span>The second issue relates to the size of a topic: how big or small shall it be, which leads us to a more profound question: what is a (DITA) topic? It seems that many users adopting a topic based authoring approach are confused about how to address these two issues. Many users of DITA end up managing millions of small fragments, called topics. And they ask themselves, since each topic has an overhead cost associated with it: Do we really need to chunk our content into millions of pieces since that leads to "millions of cost" and upset user since they are getting unusable small fragments in their on-line help? Others are worried that they chunk content in too big files which overloads the user and hinders reuse. This blog post discusses various perspectives on this issue and tries to sort things out. <a href="http://www.excosoft.se/index.php/about-us/blog/item/54-why-is-the-result-often-a-million-little-pieces-even-though-dita-does-not-encourage-authors-to-fragment-information-in-such-a-way-a-million-little-pieces" target="_blank">Read more</a>.</span>
| + | <span>The second issue relates to the size of a topic regarding how big or small shall it be, which leads us to a more profound question: What is a (DITA) topic? It seems that many users adopting a topic based authoring approach are confused about how to address these two issues. Many users of DITA end up managing millions of small fragments, called topics. And they ask themselves, since each topic has an overhead cost associated with it: Do we really need to chunk our content into millions of pieces since that leads to "millions of cost" and upset user since they are getting unusable small fragments in their on-line help? Others are worried that they chunk content in too big files which overloads the user and hinders reuse. This blog post discusses various perspectives on this issue and tries to sort things out. <a href="http://www.excosoft.se/index.php/about-us/blog/item/54-why-is-the-result-often-a-million-little-pieces-even-though-dita-does-not-encourage-authors-to-fragment-information-in-such-a-way-a-million-little-pieces" target="_blank">Read more</a>.</span>
|
</p>
| </p>
| ||
In pursuit of the ultimate techCom information architecture
Why is the result often a million little pieces even though DITA does not encourage authors to chunk information in such a way?
A lot of discussions and confusion in social media has recently, as it seems, dealt with two issues concerning the use of DITA (see for example a discussion in the DITA awareness group on linkedIn or another discussion on LinkedIn or a blog post by Tom Johnson). The first issue relates to when shall we nest topics and when we shall not, that is, shall DITA topics be kept as separate files or shall authors instead use a <dita> document and nest topics within it? The discussion regarding this first issue is about advantages and drawbacks and when to not do one or the other. Some say "nest, yes!" and some say "leave it, period!".
The second issue relates to the size of a topic regarding how big or small shall it be, which leads us to a more profound question: What is a (DITA) topic? It seems that many users adopting a topic based authoring approach are confused about how to address these two issues. Many users of DITA end up managing millions of small fragments, called topics. And they ask themselves, since each topic has an overhead cost associated with it: Do we really need to chunk our content into millions of pieces since that leads to "millions of cost" and upset user since they are getting unusable small fragments in their on-line help? Others are worried that they chunk content in too big files which overloads the user and hinders reuse. This blog post discusses various perspectives on this issue and tries to sort things out. Read more.