Jane's Technical Stuff
Archives
May 2002March 2003
May 2003
July 2003
August 2003
June 2005
July 2005
August 2005
December 2005
January 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
Wednesday, September 03, 2008
"Grow your wiki" with Stewart Mader
This evening, I headed over to The Werks to hear Stewart Mader, author of Wiki Patterns, talk about using a wiki successfully within a work environment.
I have been using TiddlyWiki to collaborate on a project level for about a year or so now - and the most recent project has probably been the most successful to date as we've sent each other links to wiki pages, both frequently updated pages as more information is uncovered, and used it as a central point. I was interested to find out how I can use a wiki more, and more effectively. I was hoping for some organisation strategies and tips, but that wasn't really what the evening was about so I will have to do some research myself on that.
Stewart was a really engaging speaker, and is obviously passionate about his subject. He had some really good uses for a wiki which I'd not thought of but actually make a whole lot of sense - things like meeting agendas. His example was that you write up an agenda and email it out to the attendees. You get three replies asking for changes to that agenda - someone wants an item removed and two others want items added. So now as the meeting organiser you've got 3 changes to make, and then you have to send it out again. As he said, you can almost guarantee that someone will have already printed out the agenda before the revised version is sent out and so will end up at the meeting with an out of date version. Instead, if you put your agenda on a wiki, then every attendee can check it out, and make changes as appropriate. During the meeting minutes can be typed into the wiki directly if it is a laptop friendly meeting by any or all attendees. So, the whole process immediately is a lot more collaborative.
During the Q&A session someone mentioned using google docs as a more collaborative mechanism for documents. As Steward pointed out this isn't the same thing as a wiki, and he is also concerned that google docs is quite geeky. He mentioned Buzzword as a less geeky, more UI friendly alternative - so I'm off to have a look at that.
We also discussed enterprise wiki tools, and the following were mentioned as being worth a look
In summary, a great talk, which resulted in me adding lots of "consider a wiki for x" tasks to my remember the milk task list to give some thought to when and where a wiki would be a benefit in my working life
I have been using TiddlyWiki to collaborate on a project level for about a year or so now - and the most recent project has probably been the most successful to date as we've sent each other links to wiki pages, both frequently updated pages as more information is uncovered, and used it as a central point. I was interested to find out how I can use a wiki more, and more effectively. I was hoping for some organisation strategies and tips, but that wasn't really what the evening was about so I will have to do some research myself on that.
Stewart was a really engaging speaker, and is obviously passionate about his subject. He had some really good uses for a wiki which I'd not thought of but actually make a whole lot of sense - things like meeting agendas. His example was that you write up an agenda and email it out to the attendees. You get three replies asking for changes to that agenda - someone wants an item removed and two others want items added. So now as the meeting organiser you've got 3 changes to make, and then you have to send it out again. As he said, you can almost guarantee that someone will have already printed out the agenda before the revised version is sent out and so will end up at the meeting with an out of date version. Instead, if you put your agenda on a wiki, then every attendee can check it out, and make changes as appropriate. During the meeting minutes can be typed into the wiki directly if it is a laptop friendly meeting by any or all attendees. So, the whole process immediately is a lot more collaborative.
During the Q&A session someone mentioned using google docs as a more collaborative mechanism for documents. As Steward pointed out this isn't the same thing as a wiki, and he is also concerned that google docs is quite geeky. He mentioned Buzzword as a less geeky, more UI friendly alternative - so I'm off to have a look at that.
We also discussed enterprise wiki tools, and the following were mentioned as being worth a look
In summary, a great talk, which resulted in me adding lots of "consider a wiki for x" tasks to my remember the milk task list to give some thought to when and where a wiki would be a benefit in my working life
// posted by Jane @ 9:36 PM 
Comments:
Wednesday, September 12, 2007
TiddlyWiki
Whilst at barcamp Brighton I spent some time talking to Paul and Phil from BT Osmosoft (who sponsored vast amounts of pizza and beer) and amongst other things they were reminding me about tiddlywiki, a single page wiki file. I made use of tiddlywiki within monkeyGTD for a while, but haven't revisited for some time.
Armed with a USB stick with sample tiddlywiki sites on I decided to give it a go for storing test cases for a project I'm working on at the moment. I set it up and got it running pretty quickly, although I decided to forgo the "If running on safari run these commands" instructions and work on firefox instead (anything for a quiet life!). I deemed this a success and took the wiki into work and set it up there, along with creating a project based one to store tasks and stuff. Of course, I'd missed the fact that this was a single user only wiki by design and so it wasn't long before Simon inadvertently overwrote my changes.
A few searches of google and various suggestions later I stumbled upon tiddlylock. This solution is nothing more complicated than a tiddler with code in it and tagged with systemConfig, but it seems to do the job nicely enough. Now if I make some changes to the wiki, and Simon attempts to make changes too, it tells him that I have it locked at the moment, so he can read it, but won't be able to edit. With some discipline from both of us, i.e. saving our changes immediately, this will become a workable solution which doesn't involve us having to find a server somewhere and install and maintain a full wiki solution.
Armed with a USB stick with sample tiddlywiki sites on I decided to give it a go for storing test cases for a project I'm working on at the moment. I set it up and got it running pretty quickly, although I decided to forgo the "If running on safari run these commands" instructions and work on firefox instead (anything for a quiet life!). I deemed this a success and took the wiki into work and set it up there, along with creating a project based one to store tasks and stuff. Of course, I'd missed the fact that this was a single user only wiki by design and so it wasn't long before Simon inadvertently overwrote my changes.
A few searches of google and various suggestions later I stumbled upon tiddlylock. This solution is nothing more complicated than a tiddler with code in it and tagged with systemConfig, but it seems to do the job nicely enough. Now if I make some changes to the wiki, and Simon attempts to make changes too, it tells him that I have it locked at the moment, so he can read it, but won't be able to edit. With some discipline from both of us, i.e. saving our changes immediately, this will become a workable solution which doesn't involve us having to find a server somewhere and install and maintain a full wiki solution.
Labels: barcampbrighton, tiddlywiki, wiki
// posted by Jane @ 6:53 PM
Comments:
