« Siemens Device Promises Skype Integration | Main | PopTech Bloggers Dinner TONIGHT »

Iterative Blogging: BlogDoc 1.0

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:

  • The latest version of the document (template retrieving the last post in each category)
  • Version Control by section (all the posts in that category and associated comments)
  • A lifestream of all updates. (the master blog, a time log of all changes and reissues)
  • Authoring Information (contribution by author and commenter)
  • Comments - Comments by version / section release and comments by time.
  • E-mail notification of updates and RSS / Newsreader integration.
  • Release Notes: Using the "Extract: function" a short release note can be captured and related to each "sectional reissue".

    Extending Functionality with Additional Categories:

  • News: This is news on progress, particular data or investigative findings, thanks for inputs, recognition etc. These are primarily process and planning updates.
  • Scanning: Data that may affect the outcome or provide additional context for the document. This data can also be assigned and associated with the document to enable a live form of footnotes and substantiation.
  • Meetings or Forums. Specific dates and timing reminders.

    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:

  • Did we create new and less foreign avenues for participation (eg lower the bar for a non-blog / non-wiki culture?)
  • Provide additional functionality around the document blog format that enables the blog environment to grow. (For example the Scanning and Reference Function?)
  • Can this approach to the "plan" then lead to additional blogs in support. Particularly Status or team development blogs that may include insights and learnings on the implementation and achievement of the document objectives. Typical headings may include Perfomance, Plans, People and Policy items.

    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

    Recent Comments

    My Furl


    Creative Commons License
    This weblog is licensed under a Creative Commons License.
    Powered by
    Movable Type 3.32