This is fantastic news on a number of fronts. First, it’s further validation of our strategy to have the ideas take over the world, not the code. As I’ve said from the beginning, the purpose of PurpleWiki is to be a vehicle for ideas. Our goal was not for PurpleWiki to become the Wiki, but for other Wikis to steal our best ideas. There are now three Wikis with Purple Numbers — Kwiki, Zwiki, and PurpleWiki — with hopefully more to come. (IG0)

Second, the fact that Chris was able to implement this as a Kwiki plugin makes Kwiki a more viable option for Blue Oxen Associates as its Wiki platform of the future. This is a good thing for many reasons. (IG1)

Chris has also been doing some expounding on Wikis. His entry, “Why Wiki?”, is old hat for folks who know Chris, but it’s a nice, clean summary of his views for those who don’t. His framing of augmentation versus automation (discussed in much more detail in his paper, “The Computer As Tool: From Interaction to Augmentation”) is powerful, and I’ve borrowed it in my own thinking and writing. I also liked this line: (IG2)

Architecting these sorts of tools may not solve poverty and hunger, or alleviate suffering in the aftermath of a disaster, but the tools can augment people actively doing that work. I happen to be good at making the tools go, so that’s where I look to fit myself into the puzzle. (IG3)

Chris’s thoughts on Wikis as an external cache is another good piece. Two quick comments. First, viewing Wikis as an external cache reveals an important constraint. They are most valuable to folks who are already immersed in a conversation, because those folks already have some context that aids them in exploring the Wiki. For example, Wikis used for self-documenting events are not so good at involving those who did not participate, but they are extremely valuable for those who did. At the same time, they are better than nothing. If someone is motivated enough, they can use Wikis as a springboard for acquiring the context they need, and thus gain value that way. Think Out Loud is good. (IG4)

I’ve found that in order for outboard processing to work there’s several design and process guidelines that have to be reached. Here are some: interaction must be highly responsive, noise in the interface must be minimized, structural mechanics and metaphors in content need to be consisent, names must have value, it must be there when you want it, when there is a shared brain its context is shared as well (e.g when some members of the company have a discussion about design it it is done in an archivable fashion). (IG6)

(Emphasis is mine.) It’s ironic that Chris cites highly responsive interaction as a requirement for collaboration on an asynchronous medium to work. I agree that this is an important pattern of effective collaboration, but I wouldn’t go so far as to say it’s a requirement. There is an alternative mode, one that emphasizes deep thinking augmented by infrequent, but deep interactions. A big void in the collaborative space are tools that augment this mode of interaction. See my design notes on Abelard for an example of what such a tool might look like. (IG7)

One Response to “Kwiki::Purple, Wiki Deep Thoughts”

By “highly responsive” I meant specifically that amount of time you have to wait when clicking to edit, or searching, or following a link. My brain’s moving too fast to pause a few seconds while the wiki server decides what I’m doing and then gives me a chance to do it. Slowness is a barrier to facile use and as one’s needs with a wiki become more optional, every barrier grows.

Which says nothing about the alternative mode: I completely agree that there needs to be deep thinking and deep interacting. But even in that scenario, the tools used need to be highly responsive.

Interaction is yet another one of those terms with too many overloads.

We seem to be in the midst of an upswell of interest in these things. It’s good to see this conversation going again. Thanks.