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