Peter Jones also wrote:
>Some of what
>you've said earlier seems to me to point away from this.
>Personally, speaking as someone who has not actually used it but looking
at
>the screenshots I find it back-to-front in the pattern of construction as
>well as the finished diagram. I have to think, reverse that thought,
>articulate it in the display, and reverse interpret to read it again
later.
Not sure I understand what you mean by back-to-front here. Can you amplify?
We've pretty much always found that it's hard to look at QM/Mifflin screens
that you weren't involved or engaged in. If you know where and how to look,
it's a different story. This could indeed be regarded as a 'weakness',
although I see it as more of a trade-off against the other benefits.
One strategy we've employed in dealing with this is the concept of
'representational morphing' in which the representation can be morphed into
a more conventional form (threaded discussion, outline, document.... forms
to be named later...). Simon Buckingham Shum and I discuss this in
"Collaborative Sense-Making in Design: Involving Stakeholders via
Representational Morphing",
http://kmi.open.ac.uk/kmi-abstracts/kmi-tr-74-abstract.html.
I also hold out hope that there is an improvement in the GUI concept that
retains the benefits but addresses this problem. We've played with
different icon sets and skins
(see http://www.compendiuminstitute.org/tools/skins.htm) but I think there
is a radical improvement waiting to be born out there somewhere...
>2) Similarly, given what you say above, it seems that folks are happy
>working in a bunch of tools across which IBIS data has been chosen (out of
>circumstances? arbitrarily?) as the interchange format. Should the
>interchange format also be the interface that participants in discussion
>interact with, or is it better to have them work in formats that seem to
>more naturally map to their activities. Discuss.
I'd say that, as long as the (complete set of) metadata is preserved,
people should work in formats that map on to their activities. My
contention is, though, that the QM/Mifflin interface provides a specific
and highly valuable set of benefits when people are working together. The
software infrastructure of whatever tool should support the data and
metadata being brought into and out of that form whenever necessary or
desired.
>As a corollary, is the IBIS data interchange format the right glue
>independently of UI issues.
>Here, I think, a comparison between the properties of NODAL (and similar)
>and the IBIS interchange formats would be useful.
>If NODAL is the ultimate back-end then it seems like a good road for
taking
>care of (2).
Seems like a great area for discussion/exploration. I am not the person to
make any sort of pro or con argument for any particular data interchange
format (don't have the knowledge). The Compendium DTD is offered as an
interchange mechanism so that stuff can get into and out of Compendium
tools, with the assumption that it would coexist with, and be translated to
and from, other formats. It isn't presented as an ultimate or preferred
mechanism (although if we have hit on one by mistake, so much the better :
-) ).
>In the case of (1), what makes me worry are statements to the effect that
>it
>takes 6 months to become a good QuestMap facilitator.
>All the problems with the UI that users couldn't cope with themselves have
>been loaded on to the facilitator. That makes me question the UI. Since
I agree that there is a major skill to learn there. Both IBIS and
Compendium seem pretty straightforward and simple to me, but, strangely,
few people of the many we've taught have stuck with it long enough to
attain mastery -- when mastery is defined as the ability to step into
almost any situation and begin adding value almost immediately (which is
what a Compendium practitioner can nearly always do). However, there are
some out there, so it is learnable.
But, as I've argued, I think it is a skill well worth learning (and I don't
think it reflects badly on the UI :-) ). Better training and trainers will
help.
Another approach to this, and also at the center of Mifflin's software
design, is the ability to add forms, wizards, enhanced templates, and other
mechanisms to the tool that will make it easier to learn for specific
applications. In general, we've learned that it's far easier to learn (and
teach) a specific application of the methodology than it is to teach the
methodology as a whole (which is what we tried, and pretty much failed, to
do for a few years).
For example, for the last two years I've been working with a group at the
Center for Creative Leadership (Chuck Palus, David Horth, et al) to meld
Compendium with their work (in fact, we're doing a workshop for some
Verizon executives tomorrow). Rather than training them in the full breadth
of Compendium, we've concentrated on a few exercises that combine
Compendium with their Visual Explorer toolset. That seems like a good
approach. Over and over we've learned that the absolutely hardest thing to
learn to do well is live unstructured real-time facilitation. It is
certainly possible, but it is difficult for most people, and it is too easy
when learning to fail publicly (and thus give up). So starting with some
predefined structures helps to learn the rest of the UI and methodology.
The point is to be able to do things that you couldn't do otherwise.
>A preliminary analysis:
>In the meetings I've seen, much of the role of moderator/chair is one of
>ensuring folks adhere to certain protocols. These protocols largely
involve
>acting upon the shared data. You submit requests to the chair to pose a
>question, proffer an amendment, proffer an addition. If you don't want the
>chair to have all the power then you might have a chair-mediated voting
>process with respect to changes/additions.
>
>Now, it strikes me that all of these aspects can be controlled with
>request,
>approval, and permissions mechanisms.
....
>Now, it strikes me that all of these aspects can be controlled with
>request,
>approval, and permissions mechanisms.
I agree that this is the dominant model, however it falls far short of what
is possible (and the fact that it is the dominant model is also part of the
reason why most meetings are so unsatisfying, although if practiced well
this model can be somewhat beneficial). I think we need a big upgrade in
the model.
A Compendium facilitator can do much, much more than this. We call the
principle "value now and value later". It's a big subject. But to Peter's
point, I don't think the core of it can be effectively automated. It can be
enhanced and augmented through automation, certainly. Much more to come
there. But the core skills -- listening, paraphrasing, suggesting,
summarizing, representing, writing.... are (I'd say) un-automatable. What
we've tried to do is provide a set of tools that surround and leverage
those skills.
Al
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.0.0 : Wed Nov 07 2001 - 15:17:53 PST