| |
 |
Thursday, August 22, 2002 |
Digging into k-logs 8
Entropy, big-KM, klogging and the wheel. Roland's Natural Klog Progression..
I spoke of four klogging roles last week: catalyst, coach, armorer, practice leader. Matt Mower advocates the the role of "Intranet Editor:"
Much as the users of a Wiki should occasionally re-factor pages that are becoming "busy" I think that a good intranet editor should be grooming the klogs in their organization and drawing together useful strangs to form part (or all) of the static intranet.
Roland Tanglao builds on this:
I think a natural progression for knowledge is:
- blog breaking news
- harvest it periodically (say weekly) into an FAQ and/or other knowledge base type of documents
- Put the link into a a directory that supports transclusion like Manila style directories.
K-Log => (FAQ or other knowlegebase article) => directory.
K-Logs need to be periodically (at least once a month) harvested for content that should go into an FAQ or other knowledgebase document and links that that should go into a directory. This is the job of a K-Log editor :-)! I have been trying to do this with VanEats but after a klog gets to a certain size, it really needs to have some time set aside for it.
Practice Leader is probably the closest to a dedicated multi-author editor. Summarizing work in a field, showing the aggregate progress and useful threads. Structuring knowledge into FAQs or other KM systems may be a natural progression, especially as klogging tools and KM tools build bridges.
Entropy, bad.
Fighting entropy, expensive, slow.
Self-review is a powerful tool for learning. Going over my own posts for the past week, month, and quarter has shown patterns I missed, ideas I was skirting but never wrote outright. It reinforced brief social connections, blogs to which I linked to and people with whom I briefly corresponded. It takes concentrated time and effort. It helps me to print out all the pages on my blog for that period; something about shuffling through paper.
Folks are trying hard to automate this work. Summarizers. Cluster analysis. Text to Structure converters. Taxonomy systems.
But the expert author of the original content is often the best judge of relevance.
[a klog apart]
» I think one of the things about klogs is that are no better than any other KM system when it comes to entropy. In fact they are likely to be a hell of a lot worse -- it's just the entropy matters less. Any information system that isn't properly maintained has the potential to quickly deteriorate into chaos.
The fact is that most people don't want to have to find just the right place to put something. Most people aren't going to review what they have done. You can force this behaviour, you can encourage it. But is it really necessary that everyone has to become a librarian in order to function in a knowledge environment?
My alternative is that we recognize and promote the value of good editing (and, hence, good editors). Have an editor/practice leader to head each area whose responsibility it is to aggregate good knowledge. Then reward them when they do it well. Example: Look at the number of search engine queries for specific keywords. Tie those keywords to projects/areas. If the number of searches trends downwards something is working. Okay, too simplistic? Then suggest something better!
An area I have been thinking about is how I would integrate the idea of uploading files to a KM system when klogging. One approach would be to provide some kind of clever dialogue to allow the user to specify where they want the file to end up. That sounds like hard work for me & for the user.
Alternative strategy: Allow the user to put a file in an enclosure. Radio will upstream it to the KM server as part of the RSS feed. The KM server will toss the file into an upload bucket in an area based upon the metadata of the post (ala liveTopics). It's then up to the practice leader for that area to decide where the document actually belongs and move it there (or indeed if it belongs at all).
Is this less efficient? Maybe so. Is it more effective? I think so.
Agree? Disagree? Ideas? [Curiouser and curiouser!]
12:22:28 PM Google It! 
|
|
Digging into k-logs 7
Roland's Natural Klog Progression..
I spoke of four klogging roles last week: catalyst, coach, armorer, practice leader. Matt Mower advocates the the role of "Intranet Editor:"
Much as the users of a Wiki should occasionally re-factor pages that are becoming "busy" I think that a good intranet editor should be grooming the klogs in their organization and drawing together useful strangs to form part (or all) of the static intranet.
Roland Tanglao builds on this:
I think a natural progression for knowledge is:
- blog breaking news
- harvest it periodically (say weekly) into an FAQ and/or other knowledge base type of documents
- Put the link into a a directory that supports transclusion like Manila style directories.
K-Log => (FAQ or other knowlegebase article) => directory.
K-Logs need to be periodically (at least once a month) harvested for content that should go into an FAQ or other knowledgebase document and links that that should go into a directory. This is the job of a K-Log editor :-)! I have been trying to do this with VanEats but after a klog gets to a certain size, it really needs to have some time set aside for it.
Practice Leader is probably the closest to a dedicated multi-author editor. Summarizing work in a field, showing the aggregate progress and useful threads. Structuring knowledge into FAQs or other KM systems may be a natural progression, especially as klogging tools and KM tools build bridges.
Entropy, bad.
Fighting entropy, expensive, slow.
Self-review is a powerful tool for learning. Going over my own posts for the past week, month, and quarter has shown patterns I missed, ideas I was skirting but never wrote outright. It reinforced brief social connections, blogs to which I linked to and people with whom I briefly corresponded. It takes concentrated time and effort. It helps me to print out all the pages on my blog for that period; something about shuffling through paper.
Folks are trying hard to automate this work. Summarizers. Cluster analysis. Text to Structure converters. Taxonomy systems.
But the expert author of the original content is often the best judge of relevance. [a klog apart]
12:21:05 PM Google It!
|
|
Digging into k-logs 5
Klogging up the intranet.
Just thinking about intranets and klogs.
I think klogs bring the role of a web or intranet editor sharply into focus.
Much as the users of a Wiki should occasionally re-factor pages that are becoming "busy" I think that a good intranet editor should be grooming the klogs in their organization and drawing together useful strangs to form part (or all) of the static intranet.
I wonder what kind of tools would make this easier? [Curiouser and curiouser!]
12:20:01 PM Google It!
|
|
Digging into k-logs 4
Klogging issues.
I had a very useful and productive meeting on Friday. I gave my first klogging pitch and, despite the roughness of the material, it didn't go too badly wrong. I was pitching to friends which has it's plusses and minuses but overall it's the right place for your first pitch.
Here are some of the important issues that were raised:
- Having klogs can easily overlap with existing formal systems. For example when klogging a difficult interaction with a student (these guys are at a University) does this mean that you don't put the information into the CRM system? Or when klogging about a problem with the printer should you not fill out a helpdesk ticket? It's not enough to answer that these kind of formal systems are often under-utilized, the people aren't trained, etc. since it's hard to argue this with a client who has invested in these systems. Indeed you may be pitching to one of their sponsors who might not take kindly to such assertions.
- Klogging as presented so far is a decentralizing technology. However the natural tendency of most organizations (at least in my experience within the UK) is to want to centralize. The idea of employee's having greater autonomy is not desirable. Of course they won't say that up front, however...
- Many people will fear that klogging could be used as a control tool that lets unscrupulous managers see exactly what they are doing and maybe even document their job so that they can be replaced by someone cheaper. It's a sad reflection on todays workplace, but it is a reflection.
- Security. This is closely related to the de-centralization point above. At the moment klogging systems (because they are basically blogging systems where security isn't an issue) have little or no inherent security. This will limit their value as people will feel unable to klog anything sensitive.
- Big-KM vendors will embrace klogging. This is really only of interest to people espousing klogging solutions based on products like Radio or MoveableType (is there anyone?). My own belief is that the Big-KM vendors will do their usual job of missing the boat, missing the point then coming to the party with a hotchpotch solution.
These issues are not new but are, to my knowledge, unresolved. I'll be looking for answers in the days and weeks ahead. Anyone got a headstart on me (please!)? [Curiouser and curiouser!]
12:19:32 PM Google It!
|
|
Digging into k-logs 3
Fixing intranets with klogs.
Fixing intranets. It's interesting how the same issues seem to come up in bunches. Over the last month, I have now talked... [Column Two]
» James has written an interesting post about some of the common problems with intranets that he encounters with his clients. As someone interested in how klogging (I'll use the term for now!) could affect the role of intranets and content management his issues seem particularly relevant to me. In preface to my remarks I should point out that I am choosing to address static content rather than the possible dynamic web applications you might find on a typical intranet.
The issues, re-ordered slightly to suit my responses, are:
- The intranet has grown over time.
- Manual processes (using Frontpage or Dreamweaver) are used to publish pages.
- A lot of information has been published, but the site isn't being used.
- There is little high-level structure, and users are not able to find information.
1. If you want a logical hierarchical structure then organic growth is a problem. It's like running water, it flows down along the path of least resistance and doesn't care about the direction. Same with people, they'll squirrel stuff anywhere that makes sense today (have you taken a good look at your my "My Documents" directory lately?). Of course if you're klogging then this organic growth is part of the package. Whether that bothers you is probably a factor of points (2), (3), and (4).
2. This is most obviously solved by klogging software. It's one of the fundamentals.
3. Hard to say but I guess much of the information published may be of low quality. In my experience no matter how hard publishing to an intranet can be, creating information is harder still. This leads to variable quality in that information. Variable quality leads to low usage. Low usage provides little incentive for new information to be created and so on.
Klogging address this in two ways I think:
- When you have something to publish it's dead easy: click, type, click.
- You can publish in bite-size chunks. This means that if you have a small but useful piece of information you can just klog it. You don't have to pad it into a long document to make it worthwhile. You also don't have to find "just the right place" for it to go, it just gets klogged. That chunk can exist in it's own right, waiting for the day someone needs it.
Which brings us rather neatly to (4)
4. As it stands klogging is a decentralizing technology that doesn't encourage a formal hierarchical structure. You klog and, if all goes according to plan, people will subscribe to you and they will link to you. Will they be the right people? Does it make information any easier to locate? Not automatically no. But then hierarchical structures don't necessarily make life any easier. Once a hierarchy is more than about 2 levels deep it can cause it's own navigation issues.
Some people might argue that a healthy klogging culture coupled with a Google search appliance (or any search engine that has a pageranking algorithm I guess) could well make it easier to find what you're looking for. I think theres something to be said for that.
My own approach is to allow for easy metadata-enabling of klogs. My hope is that combining klogs with topic maps will allow new structures to be grown from them automagically. This can complement the pagerank based search and provide new ways of finding and traversing group knowledge.
So should you scrap the intranet and replace it with klogs?
I don't think so. But perhaps you should think carefully about what you want your intranet to achieve and whether some of your goals for information publishing and dissemination couldn't be better achieved with a klogging strategy. [Curiouser and curiouser!]
12:18:53 PM Google It!
|
|
Digging into k-logs 2
Dear Amy Wohl, the Baby Bust is enough reason to klog widely and soon..
Hi, Amy.
You wrote via Ernie the Attorney via snowdeal.org | conflux:
One of the tough tasks in KM is getting expertise located in an organization (that is, figuring out who has it on a subject by subject basis). Tougher still is validating its credibility with other members of the organization. Toughest of all is getting the experts to agree to share their expertise with others, except as part of their regular job. Employees who have spent a career lifetime enhancing their value because they "know" something others don't are logically reluctant to give away their valuable expertise...
Amy, the baby boomers are starting to retire in droves (you know who you are). How competitive is a firm when 20% to 40% of its most experienced people leave? You can fight to get and keep talent but that doesn't fix Mary-who-left-Tuesday being the only one who knows how to get that payroll program to work.
There is no technology fix. Just a human one. Whether you call it a Learning Organization campaign or a Knowledge Management program, you still have to get people engaged. Talking. Sharing. Growing. Enjoying the process. Becoming more effective, more marketable. Making their workplace better.
The only tools that matter are ones people really use.
That's where klogs (knowledge or enterprise weblogs) come in.
KM Systems are to Treacle as Weblogs are to Honey. People gag on most KM systems. And get a sugar high off of blogging. So people use them. Start your engines and gun your motor, your KM go-cart is off and running. It isn't ready for NASCAR, it won't make it to the moon and back. But your project, your people, are going in the right direction. Can you say that now or for any other toolset?
btw, if you know anyone interested in setting up a consulting practice to help large orgs, public or private, survive the coming Baby Bust, drop my name. pwolff@dijest.com.
Ever yours,
- Phil Wolff [a klog apart]
12:18:16 PM Google It!
|
|
Digging into k-logs 1
Of Tom Gilbert and K-logs.
A while back, I had offered a challenge for McGee to pass along to his students. He did so, but none of them stepped forward. I was disappointed, but am willing to accept this as an indicator of their intelligence. :-)
So I guess I'll have to do the heavy lifting, and that means all this will dribble out over some time. Bad for my readers who might want to get this in one chunk; Good for me to have more time for reflecting about this.
I'll start off with a direct quote from Tom Gilbert's Human Competence: Engineering Worthy Performance, p178-9. BTW, if you are interesting in management, Human Performance Technolgy, KM/KS, behavior analysis, or performance improvement, you should get two copies of this book (one to keep clutched tightly in your hands, and one for loaning to others).
Principles of Information Flow
The requirements of an information system sensibly designed to give maximum support to performance are absurdly simple, and they can be summarized in eight steps:
- Identify the expected accomplishments, mission, responsibilities, and duties.
- State the requirements of each accomplishment. If there is any doubt that people understand the reason why an accomplishment and its requirements are important, explain this.
- Describe how performance will be measured and why.
- Set exemplary standards, preferably in measurement terms.
- Identify exemplary performers and any available resources that people can use to become exemplary performers. [Gilbert defined (p40) "exemplary performance as the most sustained worthy performance we can reasonably expect to attain." So an outlier achievement (e.g., an NFL running back having back-to-back 1,000+ rushing yards seasons) should not be held up as a standard, since it is unlikely to be sustainable.]
- Provide frequent and unequivocable feedback about how well each person is performing. This confirmation should be expressed as a comparison with an exemplary standard. Consequences of good and poor performance should also be made clear.
- Supply as much backup information as needed to help people troubleshoot their own performance and that of the people for whom they are responsible.
- Relate various aspects of poor performance to specific remedial actions.
These steps are far too simple to be called a "technology," but it may be that their very simplicity helps explain why they are so rarely followed. I suppose that people tend to look for more complex reasons for seemingly complex problems, and therefore more complex solutions.
I believe the following about these principles:
- It is indeed a "technology", just as the socratic method might be considered a technology of learning.
- A k-log could certainly be used to help accomplish some of these steps.
- These are precisely the things a good manager should be doing (and more importantly, has direct control over!), to promote an efficient and effective work environment, whether they use a k-log or not.
[gRadio]
12:17:45 PM Google It!
|
|
LiveTopics 4
liveTopics and Categorization.
Ernie asked me what the big deal was with liveTopics. In explaining it to him, I figured out why I was excited about it. (Interesting lesson for KM - you can't share what you don't know, and you don't know something until you can explain it.)
liveTopics makes it easier for me to add meta data to my posts. This alone is useful - because context around content is critical for others to benefit from it. But liveTopics closes the loop by automatically creating an outline of all posts to my blog, sorted by topic. The result is a far better navigation tool for my blog - because it increases the likelihood that anyone interested in a particular item (myself included) will be able to find it quickly.
The outline contains the item title as well as any other topics associated with the item. That alone gives the reader context - this is a post that's about liveTopics. But if you only really want to know about liveTopics as a KM tool, then only follow links to posts that also contain "KM" associated with them.
For Radio users, there are some critical advantages (as I see it, your mileage may vary) to liveTopics:
- No duplication of content. If I posted one item to three categories, it created three copies of that item. This always bothered me - not only does it create duplication at Google, but it also means that multiple people could link to the same item but use different URLs. Tracking inbound links (and thereby creating some map of who's reading what) is difficult when the content is duplicated. Besides - I work for a CRM company, and we're pretty religious about single instance of a record... categories just rubbed me the wrong way.
- Categories should route content. Using preferences files in Radio, Radio can easily take care of posting to multiple sites. But categories create duplication (see above) and can bury relationships among related blog entries. liveTopics, by contrast, highlights those connections and makes it easy to drill down into more "related" topics.
- Cross-referencing becomes easier. I had used a categories macro to highlight what categories were included in a post, but your ability to browse by category was limited to the calendar. If you posted only periodically to a category, you forced users to adopt a non-standard navigation scheme in order to find your content. (Translation: it required additional effort, therefore it was less likely that they would actually dig deep enough to find anything of value.)
- Less rigidity in categorization. By the nature of the categories implementation in Radio, you are effectively reduced to a fairly rigid list of categories to post to. Yes, it's possible to create new categories - but as a practical matter, Radio really wants to limit you to pre-existing categories. liveTopics allows you to create topics on the fly - just type in any word and liveTopics will associate the post with that new topic.
I've already updated all of August's posts by removing category information and replacing categories with liveTopics. I'm very impressed with Matt Mower - extremely speedy replies and even better patience with me as I got my legs under me. There are still some rough edges, and Matt's already identified some things that will get further work. Rest assured, however, that liveTopics is big. If there were any doubt that Radio could really serve as a powerful KM platform, liveTopics goes a long way to erasing that doubt completely. [tins ::: Rick Klau's weblog]
12:08:58 PM Google It!
|
|
LiveTopics 3
liveTopics Google Jazz.
One of the things I really enjoy is learning completely new technology by just trying to make it work. (This is what Dave calls "bootstrapping".) I'm not a programmer, but I can meddle just enough to learn as I go.
I have a feeling I'll be doing a lot of exploring with liveTopics. After seeing an explanation of how Marc Barrot added a new macro to his weblog, I added the same template - the result being that you can now see "related" reading for each post I make to this site. (Note: after seeing the initial results, I'm a little disappointed in Google's ability to relate items in its collection to these posts. But that's Google's issue.) This is a great example of how complementary technologies (Radio, activeRenderer, liveTopics) can combine to present a powerful knowledge sharing and distribution platform.
Ask yourself this: two years ago, would you have thought it even remotely possible that a desktop application could automatically publish and archive web content, seemlessly integrate API-level calls to the world's most popular search engine, separate presentation from content - all for $40? Radio has some rough edges, but to see this kind of stuff in action is exciting.
As I write this, I'm in the midst of a conference where vendors are selling comparable systems for much more money. What separates them from Radio at this point more than anything else is domain expertise. The vendors here know their market (and their users) far better than Userland does. As a result, things that are important in the legal market - security models (including ethical wall security), document profiling, document management, meta data, Outlook integration, etc. - get the most attention. But the difference between Radio as a content management platform and many of the high-end portal platform players is one of degree, not magnitude.
Question: is there an opportunity for someone to take Radio as a development platform and build new applications? I'm completely ignorant of Frontier and Manila, but I think that's what they are. I'll have to learn more about them. [tins ::: Rick Klau's weblog]
12:07:53 PM Google It!
|
|
LiveTopics 2
liveTopics to create virtual weblog channels.
Here's an idea I've been thinking about for the use of liveTopics.
At the moment as author's we categorize our posts for our readers. If using default Radio by explicitly putting them into categories (or, by default, not doing so). With liveTopics I can add some granularity to that. But basically it doesn't have too much impact on my reader. It also doesn't give the reader much choice.
What I'd like to do is offer the reader is the chance to create their own categories and here's how I think it would work:
We add a "customise this site" button that pop's up a list of all the topics available on the site.
The reader can then group topics they are interested in together to create "virtual channels." These along with the default selection are bundled up into a cookie that is stored in the readers browser (with their permission).
The next time the reader visits the page they only get posts that match the selected "virtual channel." along with a drop-down to change channel and the customise button.
Anybody else think this is an interesting idea?
[Curiouser and curiouser!]
12:06:53 PM Google It!
|
|
LiveTopics 1
Playing with liveTopics.
Just downloaded liveTopics, an interesting extension of Radio that adds potentially valuable meta data to weblog posts. This is a tool developed by Matt Mower, and represents an important "next step" for Radio as a KM tool.
From Matt's site:
Topics are used on your weblog to provide cross-reference links to related items and can also show what you are and have been talking about in your postings. Cross-referencing is further enhanced by the ability to publish a Table of Contents (ToC) for your weblog (note the ToC uses the excellent activeRenderer by Marc Barrot). The two-level ToC liveTopics creates shows all the topics used in your weblog. Under each topic is a chronological list of each posts associated with the topic. In turn, under each post is listed the other topics associated with that post. This is a powerful addition to your weblog and greatly enhances it's navigability.
Here's what I love. Marc Barrot builds activeRenderer, a great UI enhancement to Radio. Matt takes that and builds on it to extend the UI by creating new ways of navigating through weblog content and adding meta data to boot. I haven't learned all the ins and outs yet, but I think this is big.
Stay tuned. [tins ::: Rick Klau's weblog]
12:06:17 PM Google It!
|
|
© Copyright 2002 Jim McGee.
|
|
