Library clips

A recent conversation has re-emerged at my work on How do wikis and blogs fit together?

One way is to think of the stock and flow model, wikis have perpetually re-edited pages, whereas blogs have a stream of date-based entries just like newspaper articles.

Wikipages can be seen as more definitive, whereas blog posts are about currency, opinion, etc…

A perfect example of this thinking is a paper by the CIA called The Wiki and the Blog: Toward a Complex Adaptive Intelligence Community. This is an award winning essay on how information sharing, and collaborative tools allow us to dynamically adapt to a changing environment (from an intelligence agency point of view).

I posted about this 3 years ago, so I’m going to quote myself here:

The idea is based on a workflow:

- repository
- blog
- wiki
- search (self explanatory)
- feedback

As the repository fills with information (structured or unstructured), we can be alerted by email or RSS for items within a category, user, keyword, most recent, etc…

Then we post blog entries, adding value (ideas and context) to this information (kind of a KM transference), people read the blog posts and are informed, creating further discussion.

The cream of the blog conversations is then added to a wikipage as the important and relevant information (filtered, and applied to the corporate context)

From the essay:

“The Blog will be vibrant, and make sea changes in real-time. The Wiki, as it matures, will serve as corporate knowledge and will not be as fickle as a the Blog. The Wiki will be authortative in nature, while the Blog will be highly agile. The Blog is personal and opinionated. The Wiki is agreed-uopn and corporate […] The Blog and the Wiki serve as successive refining processes for the unrefined ore in the intelligence repository.”

“…in the repository were most cited by the Blog over the last 24 hours. This feedback lets visitors quickly know what the community thinks is important…understand its impact…let visitors know what areas of the Wiki are changing most rapidly as an indicator of newly vetted knowledge […] top words…top blog postings…top sources cited.”

” As important as information sharing is to the success of the solution, it is even more important to know who is sharing what information. This allows intelligence officers to accurately understand where they are in the intellectual space of the intelligence community. It also allows intelligence officers to see what gaps exist and where changes need to be made.”

Since this essay the intelligence community has made a big impact at the latest enterprise 2.0 conference with it’s Intellipedia system and beyond.

How this relates to using a wiki as a solution centre?

(I think) a blog should not be a solution centre, whereas a wiki is ideal.

I guess a Tips and Tricks blog is OK, but “solution” is a more definitive word, so a wiki is more suitable.

A blog is simply a timestamped communication, similar to a newspaper.

If someone attempts to use a solution listed in a blog entry from 3 months ago, this could be outdated and not work, whereas the wikipage would always be re-edited and fresh.

Sure you can re-edit a blog entry, but its date-based format implies user beware when you are in the archives. Just like if I look at a newspaper article from 8 months ago, it may no longer be true, but that’s OK because the article has a date on it.

Within a community blogs, are great for announcements, experiences, tips, sharing links, ideas, etc…
When it comes to a solution, it should be created in a wikipage (then put the link of the wikipage on the wiki homepage or table of contents)

Then if you feel like it, write a blog post telling and pointing others to the wikipage solution, and sharing perhaps your experience and context in working out this solution.

This way the wikipage becomes the sanitised document, and the blog entry becomes the context, know-how, the “workings out” that led to this solution.

This blog entry is handy to notify people, but also the “workings out” type of content you share may trigger things in others to apply to related issues. Whereas the wikipage solution on it’s own may not be as prone to trigger correlations or ideas to other issues as the wikipage solution is sanitised, focused and more impersonal (whereas a blog entry may have more peripheral information).

Obviously you can be as personal as you like in wikis, after all it’s a free-text box, but for a solution centre wiki you may want to be more succinct and to the point.

What you could do is go back to this wikipage and put in a hyperlink to the blog entry…this way when someone is reading the wikipage solution they can click to the blog entry to find out what happened behind the scenes.

NOTE: a similar scenario could be applied to testing or tasks, where the wiki is the formal content, and the blog tells you the informal stuff about what happened.

A typical workflow

1. A support worker is dealing with an error

2. They check the solution wiki if there is a solution for this error

3. If not, they search their community support forums or post a forum topic

4. If they find a solution, they create a wikipage, then link to it on the wiki homepage

—

5. If they feel this solution is a crucial find and needs to be shared, they can then create a blog entry

A. This blog entry notifies people and points them to the wikipage

B. This blog entry includes informal, experiential and contextual information that is not included in the wikipage solution. The wikipage solution is more focused and to the point, whereas the blog entry may explain the workings out, and what took place.

6. If you like you can go back to the wikipage solution and put a link to the blog entry that expands more on the solution.

If someone has feedback or a question after reading the blog entry they can leave a comment.

In the past you have to be in the same room when someone discovers a solution, otherwise you may not know. The benefit of being in the same room is that you were there and experienced the build up to the solution, you know all the details, and you could discuss it as well.

The idea of wikis and blogs it to mimic what happens in real life, but extend it to a global village.

Further to this…

In the future someone may use this wikipage solution for a different issue, and they then may create a blog entry pointing to this same wiki solution (and then include a pointer to the blog entry, in the wikipage solution).

What we have in the end is an official solution wikipage, with links to blog entries which are essentially anecdotes about experiencing this error and solution.

This is an example of using new flexible tools to create explicit (wikipage) and tacit (blog entries) knowledge.

This is an example of a user putting the complexity into the software, instead of the other way around…see more at the end of this post.

UPDATE: Wikis and blogs can be used the same way when doing UAT (Testing). Your test results can go in the wiki, and the blog entry can notify and explain the test experience.

Related

The ubiquity of social tools in context of workflows
7 seconds to knowledge share
Is publish a dirty word in enterprise 2.0?