The fantastic example knowledge resource that is Radiopaedia

This reprised blog post is a reminder of that amazing example of free and open knowledge sharing that is Radiopaedia

X-ray published in ABC news, taken from Radiopaedia 

As described in this fascinating article,   Radiopaedia is an online wiki where Radiologists all over the globe share online X-rays that are interesting, unusual, or demonstrate particular aspects of patient cases that others might learn from. When I was a geologist, there was a saying that “the best geologist was the one what had seen the most rocks”. Presumably the best radiologists are the ones that have seen the most X-rays, but no single radiologist can possible have seen a X-ray of every type of condition.

But now they can, thanks to this shared knowledge resource.

Radiopaedia was started in 2005 by Dr Frank Gaillard, as a way of storing online his digital radiographic images. Dr Gaillard had the inspiration to make this store an open resource, and in 2007 made it accessible to other radiologists. By 2015 Radiopedia had

  •  7 million hits a month 
  • 2 million unique users 
  • users in every country in the world 
  • more than 10,600 Twitter followers
  • 17,660 cases sorted into 7,636 articles. 

The vision of Radiopaedia is

“to create the best possible radiology reference and teaching site and make it available to everyone, for ever, for free….. By pooling our collective knowledge and experience we can make a real difference in how people all over the world are imaged and diagnosed”.

The letters of thanks from radiologists all round the world show how useful this resource is in supporting correct diagnosis and thus saving lives.

So what can we learn from this?

I think the primary lesson is that a simple technology solution which serves a knowledge need for a large user base can grow quickly and organically. The barrier to entry is low, and the benefit for users is very high.

Secondly, the starting point for this was one person choosing to open his personal collection to the public. Despite the well-known behaviour of knowledge hoarding, Dr Galliard’s decision to open his knowledge base not just resulted in value to other radiologists; he himself benefited from the massive outpouring of knowledge sharing.

The value is particularly great for radiologists, in that many of them work as lone specialists. A global community provides them with a very welcome link to other practitioners.

Also radiologists are visual workers. Their chief tool is images. The more images they can see, the greater their knowledge base. The best radiologist is the one who has seen the most Xrays.  A wiki is an ideal way to share visual imagery, and to make tens of thousands of Xrays available to view.

Also the wiki is not a standalone, but part of a KM Framework. This includes

For those of you working in knowledge management, this case history provides a model for how you can connect a large community of lone practitioners, for whom a shared library of images is a massively useful resources.

Are there lone practitioners like this in your company? If so, then Radiopaedia may give you some pointers in how to build a system to support them.

View Original Source (nickmilton.com) Here.

How to run a wikithon

We all know about the traditional lifecycle of Wikis. They start with a blaze of publicity, attract a dozen or so pages, then activity fades inexorably away. It doesn’t have to be like this! Try starting with a wikithon

Euro stem cell wikithon, image from wikimedia commons
The Wikithon is a piece of process that can be introduced into your Knowledge Management Framework in order to help with creation of a wiki-based knowledge resource. We know that Knowledge Management needs process as well as technology (as well as roles, as well as governance) and many wikis fail through lack of process. Without a process, they remain as empty pages waiting to be filled.

Enter the Wikithon

What is a Wikithon?

The name “Wikithon” is based on the term “hackathon” (an event in which computer programmers and others collaborate intensively on software projects). So by analogy, a Wikithon is an event in which content owners, community of practice members and others collaborate intensively on creating wiki content. Wikipedia call this an “editathon”.

A Wikithon is therefore a special event for creating and editing Wiki content, which may last from a couple of hours to a day or more. The event may be co-located or it may be virtual. As a side benefit, the Wikithon often introduces many new people to the concept of the wiki.

Example Wikithons

There are many Wikithon examples in the public sector, for example the Women in STEM wikithon (one of a series held to increase the representation of women’s content in Wikipedia), the annual wikithons at Colombia University to create the content for the WikiCU, or the Wikithon for creating the Making Mobile Gov Wiki, held in a coffee shop in Washington, shown in the video below.

In the private sector, ConocoPhillips has had great success with Wikithons, each of which may create up to 100 pages of new content for the company Wiki.

How to run a Wikithon

You can find advice on wikithons from Wikipedia, some of which is incorporated in teh guidance below. 
  • Agree the topic and scope. Which wiki content do you want to focus on?  It works best if each Wikithon focuses on a small number of defined topics, to give business focus to the event.  The sponsor is likely to be the owner of that topic, perhaps the relevant Community of Practice leader.
  • Decide goals for the event. Do you want to complete the content for a topic? For several topics? Or do you only want to “get started”?
  • Determine the logistics – the date, the time, the number of people expected, the logistics needed in terms of internet access
  • Decide on venues. Even if the wikithon is global, it is good to provide large rooms in your major sites where people can gather to collaborate. Make sure there is excellent connectivity from these sites to the network. Provide computers if necessary, or insist everyone brings a laptop
  • Recruit some experienced wiki editors to provide guidance and coaching
  • Order in some food and other refreshments
  • Advertise the event. Advertise within the community of practice, use your local KM champions to help drum up support, and seek to involve as many people as possible who are working on the topic in question.
  • Provide a way for people to sign up to the event, so you have some idea of the number of people who will turn up physically ( as well as those who will turn up virtually).
  • On the day, try to mix new and experienced users. Have at least one – preferably several – experienced wiki users at each physical site. Make sure new users know where to go to for help
  • Welcome people to the event, share the goals and the scope. Do a round of introductions.
  • Demonstrate how to find the wiki, and how to edit. Explain the “rules of the game”
  • Provide a “sandbox” area for new people to experiment with
  • Have a chat area where online attendees can interact
  • Ask people to bring existing material on their laptops
  • Keep a list of “work that needs to be done” and cross it off as the event progresses
  • Order in some food and other refreshments
  • Make it fun – use prizes, awards, stickers
  • Take photos
  • Hand out t-shirts
  • Afterwards, thank everyone who attended, and summarise all that was achieved on the day.

View Original Source (nickmilton.com) Here.

The "Designing Buildings" wiki

The “Designing Buildings” wiki is a nice example of managed industry knowledge

The Designing Buildings Wiki, pictured below and explained above, is a wiki for the construction industry.

It is active – with 5 million users, 14 million page views per year, and plenty of new edits and content added in the last few days. It’s 7500 articles cover topics such as project planning, project activities, legislation and standards and industry context, It also contains overviews of iconic buildings such as Number 10 Downing Street, the White House, the Palm Atlantis and the Bank of China Tower.

It looks like it uses MediaWiki technology, and is edited by Designing Buildings limited.  It has useful features such as a “related articles” box, and a “featured articles” section. It even contains a section on Knowledge Management in construction.

This is a really good showcase for the power of wikis

View Original Source (nickmilton.com) Here.

4 myths of the Enterprise wiki

An article from 2009 gives us 3 reasons why wikis are not the easy route to KM that many believe. I have added a fourth

This comes from an article in pcworld based on a interview with Danish Analyst Dorthe Jespersen. Dorthe’s believes that the organisational culture can be a real barrier to the adoption of wikis, and the idea that wikis will allow knowledge to spontaneoulsy emerge, as on Wikipedia, is unfounded.

Her three myths are as follows

 Myth One: Wikis will motivate employees to contribute content. 
 Jespersen describes the “Empty wiki syndrome,” or when a wiki is deployed without a clear purpose or is too general in its focus, resulting in a site with almost no activity. It helps, said Jespersen, to appoint someone to manage the wiki, ensure there is structure like guidelines and a basic information architecture, and that it is launched with content already posted because “it’s very hard to just react to this empty space for the user.”

 Myth Two: Employees know how to contribute. 
 The concept of a wiki may be simple, but contributing content is not necessarily logical for casual users. Jespersen said some organizations prefer to refer to existing written policies around content creation that say, for instance, employees are responsible for the content they produce. But policies can be tricky considering the goal is to strike a balance between governance and structure and flexibility. Some wiki-specific policies might include guidelines around creating pages that are easy to read by having a table of contents if the page is long, or having a naming system for links to ensure consistency. 


 Myth Three: Wikis will always provide the information employees need. 
 Although searchability is often a selling point of wikis, Jespersen said the reality is wikis are difficult to search through, unlike a content management system. Given there is little structure built into wikis, “it is difficult to structure this information to make it findable the next day even.” Content on a wiki can grow faster than the organization can keep up, she said, therefore the wiki managers must perform regular searches and quality checks of the content. Overall, Jespersen suggested starting with a pilot so that the true purpose and scope of the wiki can be first ascertained before an enterprise-wide launch.

Underlying all of this is a fourth myth, which is still prevalent, and which I feel should be added to the list:

Myth Four: Wikipedia is a good model for in-house Wikis

Wikipedia is the archetypal bottom-up Wiki, drawing on the wisdom of the crowds, and is often taken as a model of bottom-up voluntary free-form knowledge sharing. However it is a poor model, for several reasons:

  1. Wikipedia is successful because it draws on a huge crowd – the population of the globe. even though the percetnage of Wiki contributors compared to teh global population is tiny, that doesnt matter because the global population is so large. A similat tiny percentage in an organisation would mean that a very small number of contributors provided the bulk of the content.
  2. That tiny percentage of Wikipedia contributors is a skewed population.  Wikipedia contributors are 80-90% male, more than 65 percent single, more than 85 percent without children, around 70 percent under the age of 30. This is the wisdomn of a subset of the crowd. You do not want this skewed viewpoint in an organisation. 
  3.  Editing wikipedia is not a case of “everyone writes what they like”. There is usually editorial overview or moderation of most pages other then the fairly niche ones. A similar form of editorial oversight is needed in organisations as well.
  4. If you want more advice, see NASA’s 6 wiki rules
  5. This video….

View Original Source (nickmilton.com) Here.

Knowledge Assets – the "Knowledge First" format

The way we write reports, especially scientific reports, is not the way we should write Knowledge Assets in a Wiki.

Image from MaxPixel

I am consulting with a firm which is moving much of its current knowledge into wiki format, on order to take it out of the document library and to turn it into a resource that is in the public domain, searchable, hyperlinked, and constantly updated.

The problem is that many of the knowledge owners are scientists, and their default knowledge format is very much based on scientific reports. Many of their first-attempt wiki pages are composed as follows:
  • List of projects:
    • Project title
    • Project outline
    • Project objectives
    • Project results
    • Project conclusions
The conclusions are where the knowledge is found, and presenting it in this way means that the reader must scroll to the bottom of the page every time to find the knowledge, and that the reader must read every project to get a full picture. Also the knowledge is not updateable, as it is linkedin every case to a project.
We are now moving the content into a “Knowledge First” structure, as follows:
  • Here is what we currently know about this topic (knowledge summary or conclusions);
  • This knowledge is based on the following projects:
    • Link to first project, with full details;
    • Link to second project, with full details etc;
  • Here are the things we still don’t know, abut are trying to find out.
The links to projects could be hyperlinks to sections further down the page, to separate project summary pages, or even to the project reports in the document management system.

This less like the way knowledge is presented in scientific reports, and more like the way it is presented in newspapers; starting with the headline, then the introductory paragraph which summarises the whole story, and then “read on for more detail”. It is a reader-driven format, aiming to give the reader what they need to know in the most efficient way.

By presenting the material in this way, the reader can find the knowledge quickly, and then zoom in to the level of knowledge they need.  Also any update to the knowledge happens at the top of the page, in clear view, and any old, invalid conclusions can be overwritten.

Format your knowledge assets and wiki pages with the user in mind, and think “Newspaper format” rather then “Scientific Report”.

View Original Source Here.