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

From: albert.m.selvin@verizon.com
Date: Wed Nov 07 2001 - 13:05:47 PST

  • Next message: albert.m.selvin@verizon.com: "Re: Can IBIS be useful for individual/asynchronous collaboration? (was Re: [unrev-II] Visualstimuli & IBIS methodology)"

    Peter Jones wrote:
    "...and that leads me to two fundamental questions.
    1) We are dealing mostly with HCI issues here, in that here human discourse
    is deliberately mediated through the system. So, it seems necessary to pose
    the question now (given all that has passed in the research of this area
    with IBIS and other tools) as to whether IBIS is really the present best
    GUI
    formalism for enabling this sort of interaction. Discuss."

    Well, "best" is a big word :-)

    I can say why I have found it to be best for our work -- what my criteria
    are. It's really about finding the right balance among many different (and
    in some cases divergent) priorities. That's a work in progress, for sure.

    (BTW, these are really great questions, and my answers here are
    insufficient to get across what I'd really like to answer, but they're a
    start)

    All of the below are predicated on the idea that collaborative sensemaking
    involves people learning to communicate effectively when confronted with
    discontinuities, barriers, problems (cf Dervin, Weick). The strategies they
    employ vary on the nature of the "gap" they need to bridge as well as their
    own skills, constraints, situation, etc.

    To me, the best GUI formalism addresses:

    Representational breadth/depth vs ease of manipulation, especially on the
    fly
    - Pictures almost always help, but they are hard to create and reuse, the
    elements of pictures rarely have anything to do with the same elements that
    appear in other views, and they are difficult to move around quickly

    Generic representation vs ad hoc/specific representations
    - It helps to have a representational strategy that is always consistent,
    based on external, objective rules, rather than representations that are
    single purpose. We have used the phrase "limited representational pallette"
    in this context -- it is not 'as good' as a rich representation, however
    used properly it is very powerful and goes very far (I always think of
    Mondrian's paintings in this regard)

    Providing vs preserving focus
    - Used properly, the GUI should enable clear, precise focus on how elements
    of a group's discourse relate to each other, in multiple contexts, as well
    as support for the big picture

    Sufficient formalization to allow/encourage granular reuse of nodes in
    multiple contexts
    - i.e. transclusions. These seem to me to be at the heart and soul of why
    we have stuck with this form for the last 7 years, leveraging off a sort of
    afterthought feature of QuestMap that we have pushed on and pushed on, and
    made a much more central feature of Mifflin

    Sufficient formalization to allow/encourage reuse of information in
    multiple tools
    - enabling the 'knowledge cycle' means being able to use the right tools
    for the right function, but preserving all the right metadata. The
    QuestMap-style GUI has indeed served us as a good glue because we have
    centered around what is the richest possible (and most flexible possible)
    support for collaborative, real-time sensemaking, done in such a way that
    it both draws from and contributes to asynchronous and document forms

    Encouraging a questioning/exploratory attitude (a rhetorical goal;
    encouraging multiple perspectives, "possible" answers instead of "the"
    answer)
    - This is also at the heart from a sensemaking point of view. In 1992 Jeff
    Conklin and company (Corporate Memory Systems) walked into our offices in
    White Plains, NY (we were then NYNEX Science & Technology) and gave us a
    demo of QuestMap (then called CM/1). This was one of the points they made
    in that initial demo, which was expanded on in a 3-day workshop that they
    held for us soon after. It was a revelation that software could help do
    this. The form is ideally suited to that attitude (as opposed to the
    mindset that we are always just gathering data in order to make decisions).
    I could go on and on on this point.... and why it has been so important for
    organizations like the phone company

    Ease of moving from informal/exploratory/unstructured to
    formal/convergent/structured modes of discourse, and of interweaving
    elements between these modes on a granular level
    - Similarly, this movement back and forth is at the core of what Compendium
    is about, and the QuestMap-style GUI seems uniquely suited to supporting
    it. My background is in communication (film/video originally, later UI
    design, human factors, requirements analysis, tech writing, etc.) and group
    process; the original co-developer of Compendium, Maarten Sierhuis, is a
    knowledge engineer and computer scientist. Compendium was born out of a
    fusion of these disciplines.

    Will address the below in subsequent posts...

    Al

    Peter 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.
    Similarly, template first, fill it in later.
    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.
    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).

    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
    there doesn't seem to be much difference between GUI implementations then
    I'm led to question the IBIS formalism, and especially its driving the
    visual representation.

    As I see it there are two types of meeting:
    1) asynchronous free-for-all. e.g. brainstorming.
    2) moderated or chaired discussion.

    For 3,000 plus years mankind has needed a moderator/chair/facilitator of
    some sort for meetings, and we may be about the change the world but let's
    just leave that in place for those that want it for the time being. But the
    properties of the role should be scrutinized.

    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.
    So, imagine you could take the basic free-for-all, decide upon the protocol
    for the meeting type you want, and impose it upon that structure at the
    click of a button. Call me a raging optimist but I think this can be done.
    Should the chair have to control the construction of the representational
    elements for the discussion? No, I think not. The GUI should come as close
    to instant universal understanding of the representation as you can get.
    That way, apart from the permissions granting, all other actions can be
    delegated to the participants concerned.

    I'll see if I can put together a better presentation of my GUI ideas...

    Cheers,
    Peter

    P.S. Thanks for the expansion. :-)

    ------------------------ 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 : Wed Nov 07 2001 - 13:06:14 PST