I spent much of today constructing a FAQ for Compendium, in Compendium, then posting it as an HTML export. The contents were all taken from postings on the compendiuminstitute yahoogroup, which I edited a bit to fit into the format I was trying to follow. As usual, I didn't really plan it out in advance, more just winged it (wung it?) and created the categories, tags, visual layout etc. as I went along.
At the end I decided to put it up on the web (up til then I was just going to have it as an xml export for a small group of people to play with and give me input on how it should be), so that prompted creation of nicer containing maps and lists for the content. I also made a custom background using Snagit's editor then laboriously added it to each map. Then, when I went to upload all the HTML files to the kmi server, I realized that I didn't like having the long ugly URL that Compendium generates to mail out to people, and that if I wanted to avoid that I'd have to figure out how to do an HTML redirect, which I'd never done before. A quick Googling found examples of the code to use, which is very simple, and after a few trials-and-errors my shiny new site was in place.
I also recorded the whole process of making it using Camtasia. I did this for two reasons: first, for potential use in my own research. I could analyze what moves and thinking process were used in the creation of this particular artifact, which is different from most of the materials I've been analyzing, which are recordings of other practitioners doing work with groups in live settings. Second, I (or someone else) could pull snippets out to use in further training videos -- lots of different techniques and tricks illustrated in the course of making these.
Saturday, January 07, 2006
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.
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.
Subscribe to:
Posts (Atom)
Posts
