A free wiki has become another tool in my consulting toolbox
I’ve been working on a web services project for a customer over the last few months. I’m in Austin, the customer is in Atlanta, and the developer on the project is also in Austin (but not in the same physical office as myself). I needed a way to work with the developer and the customer on defining the web services, the interfaces, and the logic within. As I mentioned in an earlier post, I was drowning in the customer’s waterfall documentation. I needed a better communication vehicle than emailing Word documents back and forth.
I created a free wiki at pbwiki, which was super easy to do. Then, I started writing. From the office. From home. It was great. I created just a couple of pages at first. Defined the work to do for the first iteration. Marked it as so on the wiki. Pushed it out to the developer.
After a few days, my developer commented: I like the Wiki, so far it’s workin’ for me. I’d prefer we keep it.
So on we go. More pages, a TOC, an Open Issues page. For this particular project, I only allow myself and the developer to edit the wiki. The customer has read-only access.
Note: pbwiki has paid wikis available as well, with larger storage options, and more fine grain access control. For this project, the free version worked perfect.
I really like being able to subscribe to the wiki via RSS. This allows me to be notified of any changes the developer makes, the developer to be notified of any changes I make, and allows the customer to always keep up to date, if they so desire.
A couple weeks later, the developer commented again: This wiki thing is awesome, by the way.
I agree. It’s easy. Easy for everyone to get to. Easy to edit. No special applications or tools required (other than a browser).
Rock on.
Additional note: The free version of pbwiki includes Google ads, but I added a GreaseMonkey script to remove the Google ads, so I now have an ad-free free wiki.
