stressfree - wiki

Wikis in plain english

David — Thu, 14 Jun 2007 10:59:52 +0000

This is a nice little video for explaining to those who do not know or understand what wiki are without using words of more than two syllables. It does not push the theoretical envelope in any way but it is fun to watch all the same.

Capturing workplace knowledge with Drupal

David — Wed, 06 Jun 2007 12:03:11 +0000

Formally recording what we have learned in the workplace is a worthwhile process that is often forgotten or not undertaken because there is no time or immediate incentive to do so. Web-based technologies such as wikis and blogs have demonstrated that enabling people to quickly publish and publicise their knowledge within their peer group is potentially a very powerful means of undertaking collaborative knowledge capture. This article explores how Drupal, an open-source content management framework can be used to facilitate this process in a community centric manner.

So much to know, so little time

A workplace such as an architecture practice generates a lot of 'on the job' knowledge which at the time can seem obvious or worthless but afterwards can be invaluable. Such knowledge can range from the most appropriate window detail to use in a certain situation, to the most efficient way of modeling that window detail in the office CAD package. Usually these little morsels of knowledge are never formally recorded because it is just more work that typically is not budgeted for, or acknowledged by, management. As a consequence finding an answer to one of the aforementioned questions becomes dependent on your ability to understand the workplace's knowledge topography (i.e. who knows what). But even though it maybe common knowledge in your workplace that Bob has a collection of decent window details or Andrew 'the CAD guy' will help you out, what happens when they are not available, or even worse quit their job to work at the more fashionable architecture practice across town?

Technology to the rescue (sort of)

During the later bit of the 20th Century 'knowledge management' was a buzz-word because to a certain degree it was felt that with the onset of the 'knowledge economy' we would all soon be drowning in a big sea of knowledge (that's a lot of knowledge). Consequently many complicated and expensive systems were developed to act like sponges and absorb all this dangerous knowledge. Unfortunately whilst many of these systems did an excellent job of storing and searching the information that was put into them, the highly structured manner in which this data had to be entered made it painful for the average, overworked and under-appreciated employee to undertake. It must of come as some surprise to many employers when they realised that whilst their employees were not using their expensive workplace knowledge management systems they would gladly spend hours of their free time (and no doubt some of their employers) writing blogs and participating in wikis such as Wikipedia on the public Internet. Given the massive adoption of both technologies it comes at no surprise then that we are now trying to understand how to leverage these tools in order to capture workplace knowledge.

What are these two Web technologies and how are they different? At its simplest form a blog is a series of chronologically ordered texts casually written by a single person on a subject matter of their choosing. In contrast a wiki is generally a more formal and structured set of documents that any (authorised) person can edit how they see fit. Both are similar in that the processes of publishing and publicising new content is instant which provides immediate gratification and information for those partaking in the process. However whilst conversation in the form of comments is encouraged around both, blog comments generally spurs open ended debate, whilst comments on a wiki are usually intended as feedback for improving the underlying document.

Mixing and matching to find a combination that suits your environment

Ignoring technology for a moment a workplace's knowledge cannot be translated purely into an encyclopedic-like volume or assembled as a collection of personal thoughts. The best strategy to adopt in this environment is a 'horses for courses' approach. Some aspects of the business will be recorded and utlised most efficiently as a wiki-like document, whilst extracting nuggets of personal knowledge from employees will require a blog-like environment. However what is most important is that a healthy and incentivised environment for conversation needs to be created for all employees to participate in. The last thing a workplace needs is for the platform to become a venue for one person to blow their own horn or a tool for management to enforce how things should be done.

A diagram illustrating the relationship between blogs, wiki and groups in a workplace knowledge capture system (click to enlarge)

As is hopefully apparent from the description above both blog and wiki have their own set of benefits and drawbacks. Whilst a blog is an excellent means of recording one person's opinion or off the wall process it is not a useful venue for collaboratively putting together a set of 'best practice' documents. Likewise whilst a wiki enables a group of like-minded people to assemble a homogeneous knowledge base it stifles personal opinion in favor of group-think, or even worse allows the resident alpha-male to stamp his (or her) mark on everything that gets recorded. Currently we do not have a Web concept that encompasses the best of both worlds and because of the forces at play I doubt one will ever exist. As a consequence an effective workplace knowledge capture system should attempt to blend both blog and wiki in a manner which positively reinforces both functional requirements.

Enter Drupal, the jack of all trades

Most blog or wiki software packages available today are simply that, a blog OR wiki software package. There are very few that are both and even fewer that do them both well. Drupal is one such software package that is capable of enabling simultaneous and seamless blog and wiki-like functionality in the manner required of a workplace knowledge capture system. Drupal is a mature, open-source, PHP-based content management framework that is used worldwide on thousands of Web and intranet sites. Unlike a more traditional, one size fits all content management or wiki system, Drupal is intended to be extended and modified to suit the exact functionality required. This capability makes it ideal for use as a workplace knowledge capture system because it can be tailored to fit the intended environment and is capable of changing as the workplace evolves.

Blogging in Drupal

Drupal comes standard with a blog module built in which allows all users to have their very own blog that other people can view and comment upon. Creating interesting blog posts is greatly simplified through the use of word-processor editor modules such as TinyMCE with extensions like IMCE. These enable even the most technically challenged people to create rich, structured documents complete with embedded photographs and diagrams.

The TinyMCE rich-text editor within Drupal (click to enlarge)

Wiki-like functionality in Drupal

Drupal does not yet have wiki functionality built in by default. This being said it is possible to create a versioned document type that can be edited by all users with only a few mouse clicks. When combined with the diff module this versioned, fully editable document has the same characteristics of a wiki document without the annoying wiki syntax (which many would say is a good thing). There are wiki syntax modules in development for Drupal but in reality a rich-text HTML editor like TinyMCE is far easier to pick up and use by your average employee when compared to the often cryptic world of wiki-markup.

Taxonomies in Drupal

Having lots of content is a great, but like our mothers always warned too much of a good thing will lead to stomach aches and tooth decay. Just because something has been written down and is in a database does not mean it will be easily found. Drupal allows content to be categorised in many different ways from a highly structured taxonomy through to very fluid, user defined tags. Both types of categorisation have their benefits and drawbacks, but being able to mix and match both systems depending on the type of content enables staff to locate what they are trying to find in any number of ways. For example taxonomies can be browsed or viewed as a cloud, used to assist in search request or, with the aid of modules like 'similar entries' can forge links between disconnected content.

Identity in Drupal

Identity management is another hot topic within the I.T. world at the moment and Drupal is very powerful in this regard. By default Drupal uses an internal user database but it can be configured to pull user information from a central source such as an LDAP server. Functionality such as this enables it to be integrated seamlessly into an office environment where employees generally have existing accounts for file and print services.

Building communities around business topics with Organic Groups

On an active website what generally turns out to be the hardest part of the interaction process is deciding what is or is not interesting to you. The last thing you want to do on a busy work day is comb through all the new bits of information on the workplace knowledge base just to find out nothing touches on your specific interests. The Organic Groups module resolves this problem by allowing users to create groups within the Drupal site which can be subscribed to by associates who have similar interests. As content is posted to this group the subscribed users can be notified by email or RSS feed of the developments rather than having to manually check. A secondary but no less important aspect of the module is that it enables the group to flag what they are discussing as private so that only those subscribed and authorised can view and partake in the conversation. In a large, multi-faceted organisation a capability such as this is important because not all knowledge capturing is a public affair, especially if the information is confidential or sensitive.

There is no such thing as a free lunch, but the food is cheap

Drupal does not have a 'workplace knowledge capturing' module because each workplace is different and for such a tool to be successful it needs to be tuned to its environment. Fortunately Drupal is a fluid platform so deployment can happen very quickly with the intention being that the system will be changed to suit the workplace based on feedback and uptake by the staff. Being open source with a large user base there are very little setup cost s and support from the community or local consultants is easy to come by. If you are considering setting a knowledge capture system up then I would recommend exploring how blogs and wiki can be used in partnership with each other in your workplace and whether Drupal could be the stage where it all takes place.

Note: For a list of useful Drupal modules checkout my Diigo Drupal bookmarks for many of my favourites.

DokuWiki - My favourite Wiki tool

David — Wed, 11 Oct 2006 09:17:25 +0000

Whilst Wiki markup language can be a little intimidating for the novice user it is hard to argue with the overall success of the Wiki concept especially when you take a look at sites like Wikipedia. I have tried a number of Wiki tools but DocuWiki is my favourite for a number of reasons.

Firstly it just seems to work with very little hassle, mainly because it is written in PHP and does not rely on any back-end database, preferring instead to save all data to files on the disk. I also like it because it gets up and running without any major configuration process, if you have the correct PHP extensions loaded and file permissions set it will just work with almost no questions asked. To top it all off if the extensive built in functionality does not meet your needs it can be easily extended through the use of plug-ins as this Linux.com article illustrates.

wiki
php

On Wrap-ups

David — Mon, 15 May 2006 10:04:09 +0000

A Mash-up in the Web sense is when you grab a bunch of disparate API’s, say Google Maps and live crime statistics and come out with something whose sum is greater than that of its parts (in this example chicagocrime.org). A Wrap-up is my term for the grouping of hyperlinks and tags with a supporting wiki-based summary of the ideas, issues and decisions reached within the identified dataset. In both cases the outcome is of more inherit value than its component pieces. Yet without the individual value of the compontents the end result lacks credibility or interactivity, making the concept as a whole less appealing or conclusive.

As I said in my last post a major issue we were facing in the Reasonate testing was quickly gaining an global overview of a project or individual’s progress without having to read and understand numerous scrapbook-like blog postings. Just to complicate matters these posts are often related to, but not explicit in their overall meaning or relationship to the design’s end goals. Or how I put it more pragmatically last time round:

“What was needed was a mechanism easily ‘wrap things up’ into a format that was easily disseminated by the casual observer yet retained the rich chronological underpinnings the blogging process had successfully established….”

This process of wrapping up tied into something mentioned by both Robert Amor and Mark Burry when I had seen them last (at separate times). Both had mentioned Australian research into the use of Wiki’s in the design process, or more specifically the work of Jane Burry on wiki.

My initial reaction to wiki is negative. This is in part because I’ve seen a number of software projects try to solve their problems by creating a wiki only at the end of the process to have a very expansive website filled with lots of very empty pages. Also I feel by their very nature wiki are viewed as authoritative sources of information rather than places for conversation or debate. Probably the best argument I have for this is that the most successful wiki are authoritative in purpose, such as Wikipedia and community-orientated software documentation like those in place for Ruby on Rails or the Hula Project. In most situations the edits made are not viewed as some form of ongoing debate but rather a case of who can get the last word in on a subject matter usually very close to the author’s heart. There are many examples of this on Wikipedia such as Adam Curry’s revisionist edits on Podcasting and perhaps more worryingly attempts by employees within the U.S. Congress to publicly pimp their politicians.

Attitudes like this don’t bode well to wiki use within the initial phase of conceptual design which is why I have focused more energies on the use of blogging in this area. However as has been found with Reasonate testing, too much stream of thought and scrapbooking of ideas and not enough authoritative opinion can be just as bad as single, dominant personality commandeering a wiki for use as a personal soap box.

Enter the Wrap-up.

One of the most useful things I find about Wikipedia entries is not the text itself but the external references usually listed at the bottom of the page. These references act as reassurance and further reference for the subject matter detailed in the wiki document. The Wrap-up would be the intelligent collection of aggregated project blogs, files and tags provided through the Reasonate API for summarising (wrapping up) in a wiki environment.

Over the last few weeks my attitude towards what Reasonate programatically has changed after a very fruitful meeting with Mike where we discussed Web 2.0 services and how they related to Reasonate. The logic behind this thinking will appear in my next post but to summarise I see Reasonate now as a 'Building Information Aggregation Service' (BIAS). Rather than a standalone user experience Reasonate should be a service that pulls together various project information sources and then projects this information against a defined participant/project structure. The outcome of this process would be an intelligently searchable index interfaced primary via a Google-like API, or for a more simple explanation, think Technorati for design projects.

With this intelligent index you can then construct search terms that form the basis of the project wrap-ups. You could for arguments sake construct wrap-ups out of an explicitly defined set of URL’s but this is ineffective. For one URL’s in the real world are not constant, domain names change, software behind blogs is updated breaking older URLs and content is deleted or edited to the point where it no longer bears any resemblance to its former self. Secondly its difficult to justify something that is arbitrary, a data-set constructed of a specific date-range, tag and author combination by its very definition begins to tell a story, whether it is useful or not comes down to the authors of the wiki wrap-up.

For example a conceptual design wrap-up may specify the following content constraints:

Published between X & Y dates
Submitted under the Project A category
Submitted by members of the design team

This filter would create the backdrop for the wrap-up Wiki entry and through its data-set establish those participants in the project who hold editing rights. The search filter would also be used as the basis for establishing associated resources to the wrap-up Wiki such as links to files, blogs and tag clouds. This would remove a lot of the manual groundwork associated with a wiki and leave the authors free to concentrate on one thing, wrapping up the activities embodied in this aspect of the design process.

Being able to define intelligent search filters would also hold significant productivity improvements when it came to generating the wiki wrap-ups or simply understanding design progress. Rather than having to review the entire process to establish appropriate ‘wrap-up’ moments template rule-sets could be applied based on prior experience. Also perhaps more importantly wrap-ups like the ‘brief’ could be easily reassessed during the design process to see if the underlying conversation has changed significantly enough to justify a reassessment of the ‘brief’ wrap-up. For example, if the wrap-up was written in March how many new posts/tags since then have been introduced to the underlying filtered set and how does this influence the summarised idea?

On a slighty different (but similar) discussion thread

As an endnote something that came to mind as I mentally debated the 'meaningless page full of links scenario' versus a more intelligent search filter based on approach was a recent podcast discussion between Doc Searls and Steve Gillmor. Doc Searls employs a very hyerlink rich blogging style, sometimes to the point that the post itself becomes slightly meaningless (unless reading 'here is good, so to here and here but not this' makes sense to you). Steve's underlying point was that the power of the hyperlink lay not in its end-point but rather its intent and how others have (or have not) found the link as a tool for furthering some intention useful. This concept feeds into his ideas around gestures, especially the Gesture Bank and the AttentionTrust. These movements are something I must admit I struggle to understand but on listening to this podcast I definitely agreed with his opinion that a pool of static hyperlinks without explicit intention hold a lot less value than one may like.

WikiCalc

David — Mon, 13 Mar 2006 01:16:07 +0000

WikiCalc is a new piece of online software from Dan Bricklin that is attempting to bring the venerable spreadsheet to the Web. NewsForge is running a review of the initial alpha release and it seems pretty good. Recently he was interviewed on the Gillmor Gang about this software and his ideas around it. It is a fairly nice idea now that we live in an Internet full of Ajax and rich interaction. My initial feeling was that he was angling for a Google/Microsoft/Yahoo buyout but surprisingly he has put the source code online for others to download. This is a good thing from a free software perspective and hopefully with the support of others there will soon be a viable (and hopefully embeddable) spreadsheet application for the Web.

On the subject of Google last week TechCrunch ran screenshots of Google's Calendar application that is still in development. It seems nice enough though the market is getting pretty full of Ajax calendars. It will be nice if it can pull events out of plain text email and display your schedule in GMail in a similar way that Zimbra can tell you whats happening 'tomorrow' or 'next week' when reading an email. Mike Arrington who runs TechCrunch had a pretty good sparring contest with Steve Gillmor afterwards on the Gillmor Daily podshow. It is quite a funny listen as the pro-Google Steve attacks the more logical and reasoned Arrington on his opinion that Google is more than a little bit evil and are making a number of wrong steps.