Re: Can IBIS be useful for individual/asynchronous collaboration? (was Re: [unrev-II] Visual stimuli & IBIS methodology)

From: Peter Jones (ppj@concept67.fsnet.co.uk)
Date: Thu Nov 08 2001 - 04:34:30 PST

  • Next message: Ihsan Ali Al Darhi: "Re: [unrev-II] VPN"

    Wow! Thanks Al, great responses!

    Al Selvin wrote:
    > 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.

    Though it's _juuuust_ possible that the GUI ideas I have in mind might
    sidestep these problems.

    > Not sure I understand what you mean by back-to-front here. Can you
    amplify?

    I'm just wondering whether _for me_ the pattern of thought is much more
    Question-Argument-Idea...etc.? And that that proceeds left-to-right visually
    and logically.
    Secondly the move from unstructured to structured information in real-time
    would be fine if it weren't so hard to tell the difference between the two
    in the QuestMap GUI. The idea is that by the facilitator has finished it
    should all be formally structured. I think that misses great opportunities
    in the use of GUI technology to actually facilitate the move in concrete
    visual terms (Dang! I have to get those GUI ideas typed up soon!)

    As for the rest of your responses, well spoken.

    One point I will speak to here is ergonomics and the issue of training.
    During WWII, the British originally designed the Hurricane fighter plane
    with a joystick that you had to push forward to go up, and back to go down.
    Test pilots and early adopters were put through many hours of simulatory
    training. However, in the real plane, the statistics for crashes on or
    shortly after take-off were appalling. Folks just kept flying them into the
    ground. Problem: in the excitement of flying it was discovered that pilots
    reflexes just weren't wired the way that the controls designers believed was
    best, no matter how much training they'd had. The design team reversed the
    controls, and a great aeroplane was born.
    So, you can train all you like, but you might have to wait a couple of
    millions years for evolution to catch up.
    Or maybe it's best not to give the monkey too much to change all at once,
    and to play to its natural strengths.

    Ah, I've just read Simon remarks on this last point...

    Cheers,
    Peter

    ----- Original Message -----
    From: <albert.m.selvin@verizon.com>
    To: <unrev-II@yahoogroups.com>
    Sent: Wednesday, November 07, 2001 11:30 PM
    Subject: Re: Can IBIS be useful for individual/asynchronous collaboration?
    (was Re: [unrev-II] Visual stimuli & IBIS methodology)

    >
    > 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/
    >
    >
    >

    ------------------------ Yahoo! Groups Sponsor ---------------------~-->
    Universal Inkjet Refill Kit $29.95
    Refill any ink cartridge for less!
    Includes black and color ink.
    http://us.click.yahoo.com/bAmslD/MkNDAA/ySSFAA/IHFolB/TM
    ---------------------------------------------------------------------~->

    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 : Thu Nov 08 2001 - 04:23:37 PST