News Feed
Last week I stumbled across a potential blogging application that I've not entertained or seen used before. The solution jumped out when asked how blogs might be applied to an iterative document. I realized then that the pitch we were making for using blogs as part of a researching tool was ahead of the learning the client needed for an initial blogging project. I think what jumped out was something with viral potential to grow, and also concise enough that only one or two people need really commit to get it going so the benefits can start to emerge.
For the purposes of this example think business plan or a similar structured document with a fixed number of sections that will require a number of re-writes. At first glance this appeared to be a perfect application for a Wiki. I know others would even advocate forums for such development. In this case the organization had already experimented with wiki's and so far they have failed to become part of their collaborative landscape. So this small team was looking for a new vehicle from which they could update on iterations more effectively, provide a "living" state of the document now, enable both a comment format and enable version control and integrate it more effectively with e-mail and current work practices. Plus create learnings on blogs.
What we found ourselves suggesting was an Iterative Blog, one that would be designed and laid out to provide:
Key Iterative Blog Elements:
Extending Functionality with Additional Categories:
Creating additional structure around the document while providing specific responsibilities for sectional content means the latest post in any category / section captures a stream of updates supported with release notes.
I'm still pondering the advantages of this versus the same document in a wiki. However I think the difference here is the formal assigning of it as a project and the contained format that the assignment of categories provides. Rather than recent changes… this format secures / provides the opportunity for commentary and context. As releases are issued the old discussion is not buried, rather one can see the full development of the document over time.
I think this is an important distinction for circumstance where the evolution of thinking might later be shared or where one might want to understand the evolution of the document and track down authors and comments. By contrast a wiki makes more sense for a policy or instructional document. Where best practice and a more static and permanent document is desired. It's quite possible that the document created above could be migrated into a wiki at the end of the creation project.
What I'd hope to learn from implementing a project like the above would include:
I'd appreciate it if you have examples of the above, or similar that you ping me or provide me with a reference link. I'd appreciate it.
Comments (1)
Drupal's [1] collaborative book feature enables much of what you're talking about, out of the box. While in the process of writing a Drupal user guide, I've started with an overview of the text-based node types [2] as well as the book module [3].
Feel free to Skype me at "borismann" if you would like to discuss this further. Cheers!
[1] http://www.drupal.org
[2] http://dev.bryght.com/t/wiki/DifferentNodeTypes
[3] http://dev.bryght.com/t/wiki/DifferentNodeTypes
Posted by Boris Mann | October 18, 2004 3:04 PM
Posted on October 18, 2004 15:04