WikiWords Versus External Links

Suppose you are writing in a Wiki or WikiWord-enabled blog. Why would you use a WikiWord instead of an external link?    (3T)

For a more concrete scenario, consider a link to Blue Oxen Associates. You could either create an external link to http://www.blueoxen.org/, or you could use the WikiWord Blue Oxen Associates. I see several advantages to the latter:    (3U)

  • Easier to remember. Is it blueoxenassociates.com or boa.net? WikiWords are human-friendlier link names.    (3V)
  • Enter the link once. If your Wiki page includes the appropriate external link, and if that link changes, you only have to update the link once.    (3W)
  • Annotation. I often create Wiki pages to organizations that contain an external link and the contact information. Having the contact information on the Wiki page saves me from having to search the external site for that information.    (3X)
  • Backlinks. If you use a WikiWord, you inherit your Wiki’s Backlink functionality, which allows you to find other interesting and relevant pages.    (3Y)

The primary disadvantage occurs when the Wiki page simply consists of an external link. In this case, you force the user to click twice instead of once to get to the relevant information. I believe that this is offset by the other advantages of WikiWords.    (3Z)

Creating Motivation in Asynchronous Environments

I’m currently reading Leaping the Abyss: Putting Group Genius to Work, by Gayle Pergamit and Chris Peterson (who’s on our Advisory Board). The book is about the MGTaylor DesignShop process.    (2K)

Quick aside on MGTaylor: Founded by Matt and Gail Taylor, these folks have been around for almost 25 years, and are pioneers in facilitating what they call Group Genius. I had a chance to work with Gail and Matt at the recent PlaNetwork Conference, and came away in awe of their process.    (2L)

The MGTaylor process focuses on synchronous collaboration: same time, same place gatherings. Pergamit and Peterson write the following about the Design Shop experience:    (2M)

Without having attended the event — and discovered for ourselves both the costs imposed by some of our traditional procedures and the benefits that are possible within 72 hours — we would have remained curious, but not moved to action. (9)    (2N)

I had a similar experience at my first Dialogue Mapping workshop, taught by Jeff Conklin in July 2001. Prior to that workshop, I had read several of Jeff’s papers, and had come away with many interesting impressions of the IBIS grammar and the Dialogue Mapping methodology. However, those impressions were not motivation enough for me to try the process myself. One two-day workshop single-handedly created that motivation.    (2O)

I recently told this anecdote on our Collaboration Collaboratory mailing list, and suggested that synchronous collaboration was far superior at generating motivation than asynchronous collaboration.    (2P)

Is this true, and why? Are there patterns of asynchronous collaboration that excel at motivation?    (2Q)

I think it’s true. It’s simply a matter of show versus tell. When a group is sitting in the same room together, you can show whatever it is you want to show. When a group is dispersed, you can only tell them about whatever it is you want to show, and hope that they go and play.    (2R)

That said, I’m sure there are patterns of asynchronous collaboration for creating motivation; I just can’t think of many offhand. An obvious one is Tell A Friend — personal recommendations from people you trust. If my sisters recommend a book, I’m liable to read it. If my friends Justin and Cindy recommend a restaurant, I’m liable to try it.    (2S)

Grass Roots Peer Review

We had a Bay Area gathering of the Blue Oxen Associates Collaboration Collaboratory at Applewood’s Pizza in Menlo Park, California. Nine of us showed up, and we had a great time mixing and chatting.    (3P)

At one point in the evening, Brian Lincoln told Jon Cheyer his idea of Grass Roots Peer Review. They talked for a bit, and then Jon drew me into the conversation. Before we knew it, we were all discussing the idea,    (3Q)

Eventually, we started exploring a possible experiment that the collaboratory could perform. I posted a synopsis of that discussion on the tools-yak@collab list.    (3R)

A Unit Test Success Story

I spent the past few days closing out PurpleWiki bugs in preparation for our impending v0.9 release. And once again, unit tests saved my butt.    (3I)

Automated unit tests are like programming with a net. You invest a little bit of time up-front writing the test, and then you save a ton of time later. Most importantly, unit tests give you confidence to experiment. You can dramatically refactor your code without worrying about unknowingly breaking something.    (3J)

I’ve used unit tests on a number of small projects, and have been pleased, but not overwhelmed with the results. However, my experiences with unit tests and PurpleWiki have been extremely gratifying. Our unit tests have consistently caught bugs that might otherwise have stayed hidden for months, even years.    (3K)

Extreme Programming (XP) advocates writing tests before writing code. I cheat a bit here. I usually write a few test cases, write the code, then write the automated unit test. Same goes for bug fixes. More importantly, we mandate a unit test for every bug fix. If changes to the source code revive an old bug, the corresponding test will catch it immediately.    (3L)

On a related note, I ran into Chris Sepulveda, an old college acquaintance, last week. He’s been an XP consultant for several years, and he recently moved from NYC to the Bay Area. We had an excellent discussion about XP patterns and adoption. In particular, he bemoaned how narrow thinking about the methodology prevented many people from incorporating it into their processes effectively. XP is as much about philosophy as it is about methodology.    (3M)

Chris is loaded with good thoughts, and is slowly but surely sharing them with the rest of the world on his blog.    (3N)