Sunday, July 05, 2009

Compendium's software design, and argument mapping

This connects both to a recent post here, and to an email conversation between some of Compendium's inner core, where we've been debating some feature/design decisions. One hot topic has been the idea to retire the idea of IBIS / argument node types (Question, Idea, Pro, Con, Argument) in the default set. The debate reaches back to some of the early decisions and motivations when we created Compendium as a new software tool, which certainly took much of its basis from the desire to extend and customize Corporate Memory System's QuestMap, which was built around the IBIS rhetorical method. I thought I'd put some of my contentions here.

==

Compendium (as distinct from QuestMap) was designed from the start to allow different kinds of discourse to be interwoven with each other. Certainly affording, but not limited to -- or necessarily including -- argument mapping and IBIS.

What we have seen is that many of Compendium's users don't see a lot of the benefits and functionality of the software, in part because there are still remnants of the user interface that foreground IBIS, even though the rest of it has moved beyond that. People get hung up on the "argumentation" aspects, and if they are not interested in argumentation per se, they lose interest in Compendium.

On a software level, it also makes us preserve a lot of structure that really doesn't fit into the tool as designed/intended.

We want people to use Compendium for representing multiple ways of looking at issues, ideas, etc. If IBIS or other argumentation methods are part of their methodology (or if they discover IBIS on their own after adopting Compendium), the software should support it. But IBIS -- or any other single method or representation scheme, such as mindmapping (by far the majority of our downloaders that disclose their reason for interest in Compendium) -- should not be seen as the front door that potential adopters have to go through.
Users will come to IBIS if it makes sense to them (Jeff Conklin's work goes farther than anyone else's in that regard). But they won't use it just because the software shows them some node types that they may or may not use.

Part of what we've built into Compendium now is the ability to create branded versions with custom startup maps and other materials, so making an "IBIS Compendium" that looks like it is (only) an IBIS tool is now completely available. But many people want to use it for widely varying reasons, and we want to support that.

To me, the real brilliance of QuestMap as software was the ease and rapidity with which people could create and manipulate a hypermedia information space. What Compendium was about, from a software development point of view, was taking those hypermedia aspects and extending them in many directions.

From that point of view, IBIS, great as it is, is not a central aspect. It's transclusions (which we're going to rename to "embed" to catch up with the Web), templates, and tags, coupled with extensibility and customization, along with a host of new capabilities and concepts that have come from many different sources, which are central to Compendium as software.

1 comment:

John Wade said...

It also makes us secure a lot of structure that really doesn't fit into the product as developed.