Library clips

In a few posts I have talked about a support team using blogs (micro-blogs), forums, and wikis to get work done.

In regards to blogs the idea is to that we have an unstructured, low barrier to entry type tool to quickly publish fragments about experiences, tips, solutions, ideas…in fact we can publish by email, so this blends in with current rountines.
BTW - this isn’t just altruistic, I often do it as a way to remember what I know, but at least I’m keeping notes in the open for all to see.

Can blogs be harmful? I think it’s how you use them.

I think it’s of absolute importance that people understand that blogs are based on a currency format, they are similar to a newspaper or a journal.
A blog entry that was true last month may no longer be true anymore or correct, or there may be a better way to do the same thing.

So even though a blog is technically a database, I feel that it shouldn’t be a solutions database, especially when it’s a massive group blog.

eg.
POST 1
2 months ago someone may of posted about a feature in the software that has an error with editing a file
- someone may leave a comment saying we are working on it, and here is a workaround

POST 2
2 months later what could happen is that someone else (different to the person who created the comment) may post that the problem with editing will be fixed in the next release and we won’t be getting this till next year. Plus we have made some patches to our software and the workaround that people were using to edit files no longer works

Now someone searching a blog may come across the first post, try the workaround and it fails.

What should of happened?

The person who made post 2 should have also left a comment on Post 1.
- but 2 months have past, are they going to remember, especially when they didn’t participate in the first post

Or perhaps the person searching could of browsed the tag “edit”, and would’ve found the most recent post about “editing”
- this wouldn’t be viable if 20 posts since then have been made about “editing”
- plus we have to assume the authors are using the correct tags

What would be good practice is that the URL of Post 2, be included in Post 1, this way Post 1 will have a trackback link, that takes you to the new post.
- even better, is something I have posted called “Sparklines” which rather than add a trackback link to Post 1, will automatically edit Post 1 and put the trackback link in the post itself.

But regardless of all this, we are relying on people to follow all these subtle rules.

The point I’m trying to make is, just because blog content is visible, it doesn’t mean it’s all correct, it’s not a website that is re-edited and updated, rather it’s a blog, where you write a new post as an update…old posts may be incorrect as time goes on.

Another example…

I made a blog post describing a particular functionality of a piece of software.

We now have a new release of this software and this month old blog post is now outdated.

What’s good practice?

I need to make a new post about how this feature now works.
Then re-edit the old post to point to the new post or a leave comment on the old post
- but what happens 5 releases later, will I have to update each past post?

What are your views?

Do we have to retro edit or comment on all blog posts to keep things neat and tidy?

Wikis for solutions

I’m much more inclined to use a wiki for a solution database, as the concept is more about going back to “the entry” and re-editing it.

In this instance the blog post is not the solution, but the messenger.

eg.
1. This wikipage is solutionA for errorA
2. Write blog postA to tell people about it, include perhaps some casual (personal) and contextual content
- also include the link of the blog post in the wikipage

So far this makes sense, but it has a high process barrier to entry as you have to share twice
- write the wikipage (perhaps via email), then write the blog post (perhaps via email)

A new patch on your software means that solutionA for errorA no longer applies
3. you re-edit the wikipage
4. Write blog postB to tell people about it, include perhaps some casual (personal) and contextual content
- also include the link of the blog post in the wikipage

In this example the wiki is the solution database that gets corrected and updated, where the blog is just the messenger, and old message become out-dated, but that’s OK, because we know the blog is currency based. This doesn’t matter too much anyway because if someone visits blog postA it will still link to the same wikipage, so they will land on the correct solution.

NOTE: it would be good to re-edit blog postA and include a link to blogpostB, or use trackbacks to link them together, or perhaps grouping them with the same tag is enough…either way re-editing blog posts is higher maintenance, or not as common as old posts fall off the radar, and people may be aware they are date-stamped and may be outdated.

A blog is a blog and a wiki is a wiki

The case I’m making is that I don’t think it’s safe or good practice to use a blog as a solutions database, it’s more for sharing current happenings, where posts do not get re-edited, rather a new post is made (just like newspapers).
The blog post is not limited to just pointing to the solution, it can involve some personal context and peripheral information, or workings out (experience) that led to the solution, whereas the wikipage is a more focused formal and official solution.

The scenario comes to mind of someone following what is said in a blog post causing some kind of error or disaster. It’s essential people understand the nature of blog posts, and that they are not official…perhaps a message could be reinforced in the banner, and people can leave comments to clarify before acting on information in a blog post

Whereas a wiki is generally not a newspaper, it’s moreso a book that never goes out of date as it’s pages are continually re-edited.

In saying this it seems, you could always trust the support wiki, and you can trust recent blog posts, but how recent?
Do you trust a blog post 2 weeks old, a week old…who knows that could now be old news.

I think as long as a blog post points to the wikipage solution, then whether you click on an old or new blog post about the same solution you will always land on the correct wikipage.

What about wiki comments?

I suppose an alternative is to subscribe to wiki comments
- if a wikipage is updated, a comment can be left to let everyone know
- in this respect the wiki comments double up as a notifications feature of current happenings (which is what a blog does best)
- it doesn’t make wiki comments a blog, but the comments can be used for a blog-like way of updating people

This post is the reversal perspective on the flexibility and visibility of social tools. That is these tools are so unstructured and flexible that we can use them for unique purposes (as Ross Mayfield says, we, the users, put the complexity into the software).

I don’t think blogs are harmful, but I think they are so unstructured that people may decide to use them for inappropriate purposes. The problem is that it may work at the input stage, but it may not work at the seeking stage. I have demonstrated a scenario above where it’s so easy to post solutions in a blog, but people seeking a solution may find an old entry of that solution…this is not friendly and may have consequences. Instead a wiki is a more official solution as only one page always represents the solution, and even better is combining its use with a blog so we can explain how we came to the solution.

Just consulting a wiki solution page we get a focused error and solution, but reading a companion blog post we get what happened at the time and thought processes involved. This blog post may give away clues or trigger a thought to solving another solution that the wikipage didn’t reveal, as the blog post is more diffuse, not as focused on the endpoint.

Unstructured tools like email have been used for purposes that just don’t stretch, eg chain conversations and announcements, problem being that it’s too closed and messy.

Social tools are not immune to being used the wrong way either.