Atlassian - 8 ways to use a wiki

http://blogs.atlassian.com/news/2007/05/15_ways_to_use.html

Wikis and RSS in business

Two pieces from Information Week worth a look:

Order From Chaos Via RSS

How To Use Wikis For Business

(Even more) things you can do with RSS

Here’s a long (and continually expanding) list of things you can do with RSS.

It’s a wiki page, so it can be expanded as more and more people have more and more idea - and naturally there’s an RSS feed.

Yet more electronics in my pocket

This time, it’s a Blackberry - and this is my first attempt at a blog posting from the built-in browser.

First impressions are that it’s a bit of a faff, caused mainly by the lack of a mobile stylesheet for the blog engine - which results in rather a lot of scrolling and clicking. But I’m suprised by just how fast it’s possible to Type with just your thumbs, and the device itself is cleverly put together to make the small form factor as usuable as possible.

The next challenge is to see if I can find a Blackberry blog client, and then see if it actually works…

Tiddlywiki, redux

I’ve mentioned Tiddlywiki in the past - put (not so) simply, it’s a self-contained wiki that doesn’t need any server or database backend. Which is a complicated way of saying that you can create a Tiddlywiki and send it via email as an attachment, so that the recipient can read it without needing to connect to an internet-based server.

It’s a fiendishly clever use of HTML and Javascript - and it’s got one of the slickest interfaces I’ve seen in a wiki (not things of beauty, generally). And now there’s a server-based version - which although it loses the portability aspects, does mean that now the beauty of the interface is available as on a full-blown wiki.

Uses for wiki, part X+1 of Y: arranging meetings

Ever played email tag with a group of people while you’re trying to arrange a meeting? Ever fixed a date and time only to find it’s no good because the most important participant forgot to update their Outlook schedule for that day?

Play tag no more, because a wiki might be the answer. Here’s what we do.

Let’s say we’re trying to arrange a meeting between 10 people from different organisations. We’ll simply create a page on our wiki titled ‘Potential meeting dates for meeting X’ and send out an email with the link. The page has a list of everyone’s name and a list of the potential dates - so individuals can visit the page and delete the days they’re not available. Not only that, but they can see at a glance what other people are doing - so if it’s going to be one of those situations where not everyone can make every day, you’ve got a chance for the optimum combination of date and participants to emerge.

If the wiki page has an RSS webfeed, it’s trivial to subscribe to it so that you’re alerted as soon as someone has added or changed their availability - no need to have to remember to check back. And you can also use the same page to publish and agree on the agenda.

Uses for wikis, part X of Y: Brainstorming

One of the key roles in a brainstorming session is the person who’s in charge of writing down the ideas. The central premise of brainstorming is that every idea is captured, no matter how ridiculous it seems at the time - and this normally means someone standing at a whiteboard scribbling furiously.

Which is all very well if everyone is in the same room - but how do you capture the ideas if you want to brainstorm with people on the other side of the world?

The answer - use a wiki.

You’ll still need someone to fill the role of scribe, but instead of choosing someone who can scribble fast but legibly, now you’re looking for someone who can type fast but accurately. Instead of writing the ideas up on a whiteboard, the scribe types them into a wiki page - which can be accessed from anywhere with a network connection, and instantly refreshed to see the ideas as they go up.

The wiki then becomes a permanent record of the ideas that were generated (saving someone a job of typing up the whiteboard) - and because all the best ideas happen in the shower, it’s there in the future for ideas to be recorded once they’ve happened.

The Fake Blogs Wiki

With all the recent fuss about fake blogs (and acting on a suggestion from Steve Rubel) we’ve set up a wiki as a ‘clearing house’ for details of blogs that marketing functions would like to have us all think are genuine, but are actually about as real as Piltdown Man.

The wiki is here at www.fakeblogs.info - so if you’ve never played with a wiki, here’s your chance. And if you’ve got details of a dodgy blog, post it up onto the wiki!

Making Collaboration Work With Weblogs And Wikis

Over at Projects@Work, there’s an article by end-user analyst Cathy Webber about “Making Collaboration Work”, in which she outlines a roadmap for collaborative success with five suggestions for managing that process. It’s a very well-written and cogently-argued piece - well worth reading - but stops short of being too prescriptive about how to go about putting those suggestions into practice.

I thought it would be interesting to map the tools that we use on a daily basis with our clients to the suggestions that Cathy makes. It’s probably worth a read of the article first, but here’s my take on where weblogs and wikis could fit in.

Continue reading »

Explaining wikis

One thing we struggle with on a regular basis is explaining wikis to our clients (particularly potential clients!) If ever there was an application that has an “ah-ha!” moment it’s a wiki. There just seems to be some built-in mental block that we’re either born with or acquire from somewhere that web pages Can’t Musn’t Won’t Be Changed.

Which is ridiculous when you think about it - why should a web page be any different from a document, or a whiteboard, or a spreadsheet? We think nothing of scribbling with a marker, or tweaking the numbers, or editing the words. So why is there this mental block around make a change on a wiki page?

And when people get the concept, I swear you can sit on the other side of the conference table and see the light bulb go on. In fact we’ve ended up referring to ‘Ah-ha!’ meetings - it’s the point in our relationship with the client where wikis suddenly become a potential solution to some of their problems.

We’ve used a variety of language to try and explain our way around this block - mainly using analogies like whiteboards and spreadsheets and documents. With varying success, it has to be said - but one thing we’ve not done so far is tell a story.

This morning I came across this post at Monkey Magic. It’s someone who’s having exactly the same problem as we are - and they got the point across with a story:

The moral of the story (which doesn’t really need saying): its better to start with a load of old crap than aim for an idealised version.

I’ll use this the next time I need to explain a wiki.