How to Create a Knowledgebase Using Clearspace/SBS
Created on: Mar 20, 2009 1:48 PM by Ted Hopton - Last Modified: Mar 20, 2009 2:37 PM by Ted Hopton
Background
When combined with a defined tagging scheme, tag clouds offer a database-like capability to filter and select specific records, making it easy to create a "knowledgebase" application in Jive Clearspace/SBS with no programming or customization required.
This document illustrates the approach with a specific example.
What's a Knowledgebase?
I'm using the term knowledgebase to describe a system that offers functionality similar to a database application, but is
- not data oriented or intensive (and has no calcuations)
- requires no database programming or interaction or SQL
- easily manages user-generated content in free-form formats
Why Create a Knowledgebase?
A knowledgebase enables people to readily share their knowledge and tap into the knowledge of others. Of course, that's the general idea behind social business software (to use Jive's apt phrase), but a knowledgebase gathers together in a dedicated space many, many "records" which can be sliced and diced in valuable ways.
An Example: Wiki Wins Knowledgebase
We have an internal instance of Jive Clearspace, currently serving 4500 employees, and it's been named "the wiki" (never mind that Clearspace is much more than a wiki -- that train has already left the station -- it's "the wiki"!). We're six months into our implementation and we want to know what value the tool is providing. What benefits are we getting from it? And our CFO really wants to know the ROI (and I really want a good answer to give him!).
Since "standard" metrics around social media and communities are pretty much non-existent, I came up with the simplest measure possible: a win. A win is any benefit at all, no matter how small. Any time using the wiki helped you do your job or produced any kind of positive outcome, that's a win.
So, we're spreading the word that wiki wins count, they are important, and we need people to report them. Not only do we need to make it super-easy for people to do this (or they won't), but we also need a way to make sense of all the data we plan to collect. We need a knowledgebase.
How Does the Knowledgebase Work?
Records = Documents
Every knowledgebase record is a separate document. These documents are the "data" that the knowledgebase contains and can filter. So, we established guidelines for creating a document, or in our case, writing up a wiki win. Here's a copy of our document as of March 20, 2009 (recognizing that the original is a wiki document and is continually evolving): The specified document was not found.
Tag Cloud=Retrieval Method
The tag cloud widget for a space is the key to making the knowledgebase work, as it provides a visual and intuitive way to retrieve information. Here's the explanation we provide in our Wiki Wins Knowledgebase:
We have this text in a Formatted Text widget in the upper left corner of the page in a wide column, and we have the Tag Cloud widget directly below it. By putting the Tag Cloud in a wide column, and setting it to display 500 tags, it's easy for people to see the most popular tags so they can get started finding what they want.
After you click on one of the tags, you see a new page that offers you further filtering options, as well as a new tag cloud:
Here, you can select the type of content you want (documents, discussions or blogs), you see a list of all the content that has the tag you selected, and you have a new tag cloud you can use to drill down further.
Each time you click on a tag in the tag cloud that topic is added to the filter terms, further narrowing the selection criteria. This process can be repeated until the desired set of records has been found.
Tagging Rules: Required and Optional
We believe in the value of folksonomy more than taxonomy, but there are times when a tagging scheme is invaluable. To make the knowledgebase work, everyone needs to follow the tagging guidelines. (see: The specified document was not found.)
We have a set of tags that are required so that the knowledgebase will return the kinds of information that we need, but we recognize that creators of content know their material best, so we also encourage them to add any other tags they think would be helpful. We expect over time to identify new categories of tags that are adding value, and may move some of those to the "required" list.
Flexible and Adaptable Concept
The knowledgebase created in a space is potentially a flexible and adaptable approach for organizing all kinds of information. I came up with it originally as a calendar of events. Each document was to describe a specific event in as much detail as needed, and the tagging scheme would let us filter not only by date, but by whatever other criteria we wanted. From there it was natural to apply the concept to wiki wins. And we are just getting started!
Next up will be applying this concept to our Help Wanted space, where we have job postings from across the enterprise.
nnewcomer
says:
I think what's really important about what Ted is doing here is providing a path toward qualitative analysis of the community. I am in the process of auditing my community now to set benchmarks so that we can see what progress we have made in a year or so from now. I think putting in some additional ways for the community to lead me to the content that is making a difference is a good idea.
Ted Hopton
says:
Glad both of you like it!
I have, indeed, used tag groups and like them. In fact, I have many tag groups set up within the Wiki Wins Knowledgebase. The drawback with tag groups is they only go one level deep. You select a tag group and that's it -- can't drill down any further.
That's why I emphasized the tag cloud, instead. You get to drill down and drill down and drill down -- as far as all the associated tags will take you.
As for the nicely phrased, "path toward qualitative analysis of the community," yes, that's it exactly. By leveraging the power of the community itself to tell us what in the community is working well, we can identify the qualities that we should be highlighting and replicating. By starting with a large pool of qualitative data, we also lead ourselves naturally to discover quantitative data, too.
Thanks for posting this, Ted. Very slick.
Have you also used the Tag Group widget? It also takes advantage of a folksonomy approach to group content based on user-entered tags.
So for example, let's say you had 2 sub-spaces in a Book Club parent space, each named Leadership and Management:
Book Club
- Leadership
- Management
if you posted a document on a book that was on both leadership and management, you might get stuck trying to figure out which sub-space to use.
However, if you instead created tag groups for leadership and management, then you could just post the document to the parent Book Club space and use the tags to make it show up in both the Leadership and Management tag groups.
The Leadership tag group might contain tags like "leaders vision focus motivation", and the Management tag group might contain "managers employees relationships productivity".
If you tagged the document with "leaders" and "managers", then it would show up in both tag groups, and the Tag Group widget automatically handles the grouping/filtering on the Book Club's home page.