Wiki Advice Round Up

 My open tabs in NetNewsWire have exploded in the last couple of days with really good articles about driving wiki adoption and generally making wiki’s work. First up Making Wikis Work is a pretty good overview of all that is wrong with wikis. It’s odd to think that a technology as young as wikis has legacy cruft but they do.

In particular, WikiWords are no longer required or a good idea, use an editor that makes creating links easy or use a simple shortcut for creating links (the square bracket notation was easy for most people to learn, but you need to provide a completely GUI alternative as well).

Wiki syntax is the other big bit of legacy cruft – it’s probably the biggest barrier to wiki adoption now and wiki creators are all scrambling to add WYSIWYG editors instead but many are struggling to make it all work because wiki markup is so non-standard. Should have used HTML instead…

There’s some good suggestions in there for how to create a good wiki too. Not too sure that everyone would agree that hierarchy is the best way to organize things, but you certainly need to include good organization tools which most wikis lack.

Next up, Steward Mader nails one of the big problems with getting people to try out wikis – fear. It’s natural for people to fear new things and to fear criticism or looking stupid. Wiki’s have always tried to reduce barriers to entry for contributing but they still struggle with people’s fear of looking stupid. I think Stewart is too dismissive of this – we’ve got to find something that makes people feel safe while they get started and build up their confidence. It’s social not technical though so the solution isn’t going to be simple.

Nat Torkington talks about O’Reilly’s problem with ever growing mailing lists – Ephox has the same problem in both directions, extra people and extra content constantly being added to mailing lists. Our engineering alias has grown to include half the company so noone uses it anymore, they just type in all the actual engineers directly. Wikis are often a great solution to this if you can get people to use them – instead of pushing every message out to everyone you let people self organize around the conversations that interest them. Of course, you have to get people to actually use the wiki and pay attention to what’s going on there and it doesn’t resolve O’Reilly’s problems with NDAs etc. It does create a much more useful archive of information if the conversations are actually creating information (rather than just discussing and inspiring ideas). Probably not the solution for O’Reilly but wikis certainly can reduce the email load in a company and allow people to be more productive and actually get the information they need. Email tends to include a lot of people that don’t need to be involved and miss a lot that do, plus anyone who needs to know later has to start the discussion all over again.

Rahul complains about Google Docs rather primitive diffing capabilities. Being able to see what’s changed is another of the really obvious features that is rarely done well. Our internal wiki has some pretty awesome diff capabilities now but it still needs more work as quite a few types of changes confuse it. I’ll have to investigate how track changes could be used to improve it.

HiveTalk discusses how to hold meetings on a wiki. Good advice here but I’m hesitant to call it a meeting, mostly because noone likes meetings. I’d just call it a discussion. The idea of having a deadline is really important as is following up on actionable items. Of course because this is asynchronous people who don’t have good time management skills (most people) will tend to put it off in favor of doing something that feels more urgent so you need to be cautious of that and pester people if you really need their contributions. Often the best way to teach people to get involved is to go ahead and make decisions without them (doing the best you can) and let them live with it – depends how important the decisions and the person involved are as to whether you can get away with this though. Probably best to start with something like where the company picnic will be instead of business critical decisions.

Lots of good stuff in there – hopefully I’ll get a chance to look at them in some more depth because there’s a lot of overlap with the stuff I’m thinking about at the moment.