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

Date: Wed Nov 07 2001 - 15:30:10 PST

  • Next message: Alex Shapiro: "[unrev-II] problems with data retrieval by keyword"

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

    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",

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

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

    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
    >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
    >approval, and permissions mechanisms.
    >Now, it strikes me that all of these aspects can be controlled with
    >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.


    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    Your use of Yahoo! Groups is subject to

    This archive was generated by hypermail 2.0.0 : Wed Nov 07 2001 - 15:17:53 PST