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.

Please do follow this link if  you want to ping Stewart with examples, we would like to know too!

From the weblog: Common Craft. This case study provides some very useful and practical tactics for improving your rank in the Goolge search results.

Challenge: I planned to use search engine results as a promotional tool for the new venture. I knew that achieving high search-engine rankings could be an effective way to find new clients, so my challenge was to make CommonCraft.com appear as high as possible in Google search results. Below is the strategy I used to achieve #1 rankings for targeted phrases in Google search results.

This is a case study documenting best practices in using a weblog to achieve #1 rankings in Google. Below you will find a link to a .pdf file as well as the complete text of the case study as a weblog entry.

Download the PDF Here (90kb, 1 page)