Bookmarks for March 16th through March 18th

I find this stuff so that you don’t have to.

You can find all my bookmarks on Delicious. There is also even more stuff on my shared Google Reader page.

You can also see all the videos I think are worth watching at my video scrapbook.

Bookmarks for March 8th through March 13th

I find this stuff so that you don’t have to.

You can find all my bookmarks on Delicious. There is also even more stuff on my shared Google Reader page.

You can also see all the videos I think are worth watching at my video scrapbook.

Wikipedia a bad example for enterprise wikis?

Helen Nicol writes an interesting post about how to get wikis taken up within organisations. Using Wikipedia as an example, she writes, is a bad idea, because it sets unrealistic expectations of the amount of content likely to be generated, and will also likely scare people away.

Unfortunately, many companies begin their wiki experiments by trying to create the definitive knowledge asset on, say, knowledge management. This is a big ask for people who’ve never had their own contributions edited by someone they don’t know. It turns people off, and prevents them from recognising the potential in wikis. They need to start with a simple and non-threatening activity like a progress report or lessons learned review. Even a shared agenda would help as I said in this post some time ago. Starting small will really help people gain confidence enough to start working on bigger projects like knowledge assets.

This taps into a real problem for those wishing to encourage the adoption of these tools within their organisations. Saying wikis are like Wikipedia (which they can be, but…) is a bit like describing blogs as online diaries (which they can be, but…).

As I often say, the best thing is just to start using something, with a freely available tool, whether a blog or a wiki or whatever and then use that to demonstrate what you mean to the unbelievers. Much easier than making people think they have to start recording the sum of all human knowledge, or start publishing their innermost thoughts on the web!

Contribute to!

A few new pages have been created on the Digital Mentor wiki which are screaming out for content to be added, and it’s really easy to do so!

All you have to do to add to the wiki is click the ‘edit’ link on the relevant page, and then type in the site-wide password, which is printed on the top left of every page. No need to create an account, or think up a password to remember!

The pages that are open for contributions right now are:

  • What is a digital mentor? – Give your thoughts on what you see as being the important parts of the digital mentor role
  • Links – list where you have seen web pages and blog posts about digital mentors, or related stuff
  • Online tools – where have you seen online resources which could be used either by digital mentors, or by those mentoring the mentors?

If you don’t like using wikis, you can still contribute! Leave your thoughts in the comments here, or email them to me, and I will do the wiki bit.

Quick and easy consultation with PBwiki

I was presented with a little challenge last week at work. There was a requirement to change the information provided on various pieces of data, and to do this around 100 forms had been produced with the new information on, one for each field, and the aim was to get these forms in front of a selection of people so we could get their feedback on them.

This presented a number of challenges:

  • Emailing out all the forms to people would probably bring down the mail server, and would make it confusing for consultees to manage, and very difficult for us to organise the responses
  • Putting the forms on a network drive would undoubtedly have issues around access, and again responses would need to be emailed which would be a pain
  • Printing all the forms out multiple times would be rather wasteful, and once more collating responses would be nightmarish

So, the solution was devised to put all the forms on a wiki, one per page, and allow consultees to be able to edit the page to leave their feedback. This means that there is only one copy of each form online, and everyone reads the same one, and all the responses will be on the same page, so the collation will be done for us. Of course, the word ‘wiki’ wasn’t actually mentioned – it was just referred to as ‘a website’…

There are of course quite a few different wikis available. The short term nature of this exercise meant that a hosted solution would be best in terms of the speed at which it could be put together, and usually at this point I would be reaching straight for WikiSpaces. Instead, though, I went for PBwiki.

The main reason for this is the way people access the wiki. With WikiSpaces, consultees would have to first create an account with the site, then request to join the wiki and only once allowed in could they edit the pages. Not having any access control was out of the question. But PBwiki has a cool access restriction, which makes it possible for anyone who knows a common password to be able to edit the wiki. This was perfect to us, as we could email all the consultees with instructions and the password. Perfect.

This proves quite an interesting point – that even once you have identified the precise tool, it takes some serious consideration to decide precisely which platform you want to use. Also, while it’s good to have favourites, don’t let familiarity blind you to what other services have to offer.

Getting wiki with it

Interesting stuff going on at the Foreign and Commonwealth Office, with a wiki being built by Ben Hammersley using MediaWiki with a bit of skinning and the addition of a few plugins, like that which adds social network type features to the wiki.

It’s a nice piece of work, though I have personal reservations about MediaWiki as a collaboration platform, rather than just community-publishing content. But then it’s free as in beer and speech, and very quick to deploy.

Let’s hope that this wiki experiment isn’t vandalised to death like the last one that a department headed by David Miliband experienced.

In other wiki news, I have been taking a look at the white-label services offered by wiki-hosts Wikispaces today. For £500 a year, you can have as many wikis as you like running off subdomains of a web address of your choice. Each can have it’s own access criteria, and with the rich and easy to use functionality of Wikispaces, it’s an absolute bargain.

Playing with Google Sites

Huzzah! Google Sites has finally been added to my Google Apps account, which means I can start playing. I’ve created a test wiki here, whicha anyone can view, but if you want to have a go at editing it, you’ll need an account. Just mail me to get one (er, if I know who you are).

Overall, it’s pretty great. Dead easy to use, lovely interface, plenty of customisation options. You can have multiple wikis, all with different designs. Pages within wikis can be standard text and image affairs, or you can use one of the presupplied templates:

  • Dashboard – let’s you create an iGoogle style page with loads of widgets and RSS feeds etc
  • Lists – let’s you create to-do lists, issue trackers etc. There are a few templates for these, or just create your own
  • Announcements – effectively a blog within the wiki. Very nicely done
  • File cabinet – upload and share files. Easy to use – just a shame that files can’t be directly loads into Google Docs, you have to download them

The widgets and stuff can be embedded in any standard page as well, though. Essentially, if it’s available on iGoogle, you can have it on Google Sites.

Google doesn’t mentioned the word ‘wiki’ anywhere on Google Sites though, maybe because it scares people off, but possibly also because there are some decidedly un-wiki things about Sites, not least the fact that I can’t seem to be able to compare versions of pages, nor roll-back to previous ones. Also, you can’t create a new page just by linking to it, which is a bit poo.

These minor niggles apart, Google Sites is really rather good. It completes the circle of applications that might be needed by a small organisation to communicate and collaborate within Google Apps. It’s very professional looking, and is much, much better than Sharepoint. Seriously.

Wikis – which is best?

Well, it’s a question. Wikis are funny things, and building communities around them can be quite tricky (although advice like this helps). More than any other types of website, wikis demand community interaction, indeed, they are nothing without it.

There are a number of different ways a wiki system can be operated. One is by using a hosted platform, where you register your wiki at a site, and they host it for you. Unless you want to spend some money, the chances are that you will have to put up with having adverts on your wiki, and you’ll be limited in how you can customise it.

On the other hand, you could register a domain (i.e. and install a wiki yourself. This makes you responsible for maintenance, support etc, but also means you can completely customise the wiki for your own purposes, whether in terms of style or functionality.

So, which should you choose? As so often is the case, the answer is something along the lines of ‘it depends’. However, to help you decide, here’s a number of points to consider when working out what you want to do.

1. Have you a clue about coding?

If the answer to this is ‘no’, then please get a hosted service. You don’t need to be a skilled coder, able to generate reams of perfect PHP at will, to get a wiki up and running, but it helps if you know a little bit about these things. Otherwise, you are likely to get irritated very quickly, and that’s no good at all.


2. Do your users know what they’re doing?

If your intended user base are wiki working wonks who like nothing more than to collaboratively edit websites, then you are fine with either the hosted or self-hosted option. However, if the concept of wikis is new to your users, the hosted option might be the better one. Why? Well, they tend to be easier to use. Take Wikispaces, for example, which provides an easy to use wysiwyg editor for all page edits. This is much easier than using traditional wiki markup, which many of the self-hosted options rely on, which involves putting any number of ***asterisks*** or [[square brackets]] around words.


3. Will you need heavy customisation?

If your wiki will be a collection of basic web pages, with lots of text and maybe the odd image or embedded video, then most hosted wiki options will suit you just fine. However, if you want to have different methods of entering or presenting information available – for example by using a specific form for a certain type of information – then you will probably need a self hosted wiki which you can customise to your heart’s content (though remember point 1, above).


4. Traffic

Is this going to be the wiki of the century? Are the numbers of visitors to your wiki going to eclipse even those of Wikipedia? Probably not, but if you are planning on hosting your own wiki, do bear in mind that you are likely to be responsible for paying for bandwidth, especially if your site starts to gobble a lot of it up. Generally speaking, if you have a hosted wiki, this will be the provider’s problem, not yours. This is also true about uploaded content – if you will have lots of videos on your wiki, do bear in mind that you will have to pay for storage on a self hosted wiki. With all hosted ones, you should get a certain amount of free storage.


5. Instant networks

How about attracting people to use your wiki? One of the major problems a lot of platforms suffer from is the fact that they require users to have yet another account with yet another password to remember. This will be the case with any self hosted option, unless you are very clever (see point 1 again). However, if you put a wiki on a hosted network of wikis, then there is a good chance that some of your users will already be using that network, and will therefore already have an account there. Wikispaces is a good example of this.


6. Integration

The look and feel can be an important point for many sites – what’s the point of having a stylish theme for your website if when people click to visit your wiki it looks totally different? Some hosted wiki solutions will let you pay to edit the CSS (Cascading Style Sheets – a way of setting the design elements of your website) of the site, which will allow you quite a bit of room to customise the look of your wiki. But to retheme the guts of the wiki, you’ll really need to have a self-hosted one, where the source code as well as the CSS can be altered to suit your every whim.


So, there’s plenty to be thinking about. My basic rule would be to go for a hosted solution unless there are really good reasons not to, and my personal favourite platform for this is Wikispaces. However, if you really need to go for hosting a wiki yourself, then the best in terms of features and usability for me is MediaWiki, the system which powers Wikipedia.

Below I set out some of the options available. If yoy know of ones I have missed, let me know in the comments and I will update the list.

Hosted Wikis

Self-Hosted Wikis