Monday, January 02, 2006

Bridging worlds

Compendium has a deep pedigree on the IT side of the world. It was born in an information technology R&D lab and spent its early years doing projects with mostly an IT flavor, such as requirements analysis and process modeling. Moreover, from the start we thought about it in terms of how to be able to bring data in from other tools and databases, as well as how to send data out again, and also how to communicate between tools in real time.

But this has also been a conundrum from the beginning. The nature of Compendium is to bridge the worlds of facilitation/group process, artifact creation, methods and models, and computing -- how to make things that can help groups of people deal with complex situations, and how to do so in a way that makes it as easy as possible to fit that making in to pre-existing or desired IT/computing environments and tools. The principle is that these should not be separate, and should not have to be thought about separately. Part of the 'value now, value later' core principle is to be able to work facilitatively with data and to work with data facilitatively.

In other words, the world we live and work in already mixes and matches these seemingly separate domains -- most of us work in groups, anyone reading a blog or an email deals with all sorts of computing tools everyday, most of us make things that others are going to look at, work with, or use with software, etc.

The conundrum is that for many people we've come into contact with, these worlds are or may as well be separate. Particularly, many people that are comfortable with or interested in group process and facilitation tend not to be interested in computing per se, and vice versa ("technical" people tend not to be as facilitative / communicative). There are of course many exceptions, but this phenomenon is broad enough to have been troubling over the years.

For me there is no inherent separation, and Compendium is meant to help bridge these worlds -- to make it possible and easy to do facilitative things in a computing environment, to make meaningful representational artifacts that aren't necessarily separate from "data", and to be able to work with data and computing tools in a facilitative and expressive way. They should not have to be separate domains requiring separate specialists. Although there are many approaches, such as aesthetic computing, that talk about the aesthetics of using software as well as how to use software to make aesthetically rich artifacts, few seem to extend this to the facilitative realm. It has been difficult to tell this story in a way that's convincing to its ostensible audience -- people who work, or could work, in this bridging way.

No comments: