Hi Al,
Based on my limited knowledge so far I agree with all of that (see Al
Selvin's previous mail in this thread).
But then I pick up on
>I've started to think that an IBIS-like form is most useful when thought of
>as a "meeting interface" -- something of especial use precisely when groups
>of people are working through issues together. What Compendium tries to do
>is to provide a set of tools and methods that allow this form to be
>interwoven with other forms (D3E, MS-Office documents, etc.) when and as
>appropriate -- preserving the both the raw data and the metadata both 'in'
>and 'out' of those other forms.
...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. 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. :-)
----- Original Message -----
From: <albert.m.selvin@verizon.com>
To: <unrev-II@yahoogroups.com>
Sent: Tuesday, November 06, 2001 11:39 PM
Subject: Can IBIS be useful for individual/asynchronous collaboration? (was
Re: [unrev-II] Visual stimuli & IBIS methodology)
>
> Much of what Compendium started from was a set of attempts to add many of
> the features Eric advocates to the basic IBIS/QuestMap set of tools, in
> part for many of the same reasons he writes about below.
>
>
> Some definitions: "Compendium" is a methodology that incorporates, but
> extends, IBIS; "Mifflin" is a Java-based software tool that implements the
> Compendium methodology. The "we" of the below is mostly the core group
that
> has been working with Compendium for the last few years; a list of names
> can be found at http://www.compendiuminstitute.org/community/people.htm.
>
> To add retroactive categorization (a/k/a "incremental formalization" a la
> Shipman), we developed a (manual in QuestMap, later automated in Mifflin)
> method of adding categories to nodes.
>
> To aid ease of use in adding structured information to unstructured
> conversations, we developed templates and other structuring tools. These
> were done semi-manually when we used QuestMap, and are being automated in
> Mifflin.
>
> To address the relative ease of entering text in an email, word
processing,
> outliner, or spreadsheet format, we developed conversion tools that
> automatically converted text (in paragraph or cell chunks) into typed
nodes
> and links for import into QuestMap (and later Mifflin). The text could
> either be free-form or semi-formalized. We also developed tools in Word or
> Excel that allowed users to add metadata (tags/categories) within those
> tools if they preferred. Both tools were also adapted to specialized
> contexts (i.e. performing particular kinds of conversions based on
> particular requirements).
>
> To further 'glue' and leverage the IBIS-format discussions and other
> material in a Compendium database, we developed export tools that created
> formatted output in Word, Excel, HTML, and Visio formats. Each of these
> could either be 'generic' or specialized. For example, a five team, ~60
> person Compendium analysis of Bell Atlantic's Y2K contingency planning was
> output in both a set of tabular "reports" and in dataflow diagrams in
> Visio. These exports took advantage of many different combinations of
> metadata (node types, link types, tags, transclusions, annotations, ...).
>
> One of QuestMap's limitations as software was that its database was
> inaccessible except through the tool's GUI. Mifflin's database is open,
> allowing for much more sophisticated and flexible conversions of data into
> and out of an IBIS or IBIS-like format. We're just beginning to explore
the
> possibilities there. We've also developed a draft DTD for this data model,
> which can be found at
> http://d3e.open.ac.uk/compendium/01/comp-dtd-v1/comp-dtd-v1-t.html
> (comments enthusiastically welcomed!). For example, Maarten Sierhuis'
group
> at NASA Ames is investigating interweaving Compendium models built
> collaboratively in Mifflin with the Brahms agent-based simulation
> environment.
>
> There are more such features that at least partially address the
> requirements Eric outlines.
>
> However, all of the above leave open the question of whether any of this
> directly addresses the issue of individuals working alone, asynchronously.
> Some thoughts on this follow.
>
> Mifflin outputs maps as linked HTML maps, optionally preserving much of
the
> metadata (transclusions, tags and categories, node types, etc.) We've
> experimented with exporting these maps into D3E, allowing asynchronous
> discussion in a more web-friendly (and individual user-friendly?) format.
> The D3E team is looking into re-importing such discussion back into
Mifflin
> when desired.
>
> I'm pretty sure I agree that an IBIS form, like Compendium, is not the
> right form for unstructured individual/asynchronous collaboration (I'm
only
> 'pretty sure' because it's always possible that someone will come up with
> better ways to do it). We have never had much success with it in that form
> per se. However, we have had a fair amount of success using Compendium
> asynchronously on highly focused project teams, such as software
> development teams, especially when such use is interwoven with
> public/synchronous use in meetings (whether face to face or virtual). Most
> of the success, though, is not as a "discussion" per se, but rather adding
> metadata, annotations, or other information to targeted portions of the
> database in the service of relatively structured tasks (which are then
> reviewed, discussed, and further edited in group meetings). An example
> would be individuals adding updates to open issues or action items;
> changing tags/categories on "bug" nodes to denote that the status has
> changed (e.g. from "open bug" to "ready to test"), and so on. A lot of the
> material that ends up in these databases, by the way, started life as
> unstructured text in emails or other documents -- with formalization and
> reuse added in all along the way.
>
> I've started to think that an IBIS-like form is most useful when thought
of
> as a "meeting interface" -- something of especial use precisely when
groups
> of people are working through issues together. What Compendium tries to do
> is to provide a set of tools and methods that allow this form to be
> interwoven with other forms (D3E, MS-Office documents, etc.) when and as
> appropriate -- preserving the both the raw data and the metadata both 'in'
> and 'out' of those other forms. Structure and metadata can be brought to
> unstructured material; informal and exploratory conversation can be
brought
> to structured material. The idea is to provide the right form for the
right
> use, the right structures at the right time, without limiting the user
> community to one modality. So it's not a question of either meetings or
> individual work, but bringing the two together in a continuum or cycle.
>
> Al
>
>
>
>
> ====
>
>
>
>
>
> Eric wrote:
>
> That is one reason I favor systems that let you add categories and tags
> later in the process. That way, you can stream out your thoughts,
and
> then go back later to tag
> them, or someone else can do so.
>
> As you say, people typically find it hard to maintain a logical thread
> of reasoning
> while at the same time endeavoring to:
> * chop up discourse into nodes
> * give those nodes types
> * determine what types the links should be
> * determine where the semantics go
>
> Each of those areas constitutes a "weakness of the system" to precicesly
> the degree
> that people find it hard to do. I think there are answers to many of
> them:
> 1) Education.
> People find many things hard to do that they eventually learn to
> do with ease.
> Human adaptability being what it is, we can get used to most
> anything. But we
> need a standard playing field for that to happen.
>
> 2) Software Technology
> In an outliner for example, "chopping into nodes" is automatic.
> You don't
> even think about it. So that hurdle can be minimized with the
> right
> software.
>
> 3) Retractive Cateorizing
> Applying types to nodes and to links in a later step makes it
> possible for
> a moderator to have a significant impact on the proceedings. Once
> you
> know the system, you can apply types proactively. But that choice
> should
> not be forced on you at the outset. (That is the kind of system
> that was
> under discussion. The requirement to choose types at the outset
> constitues
> a true "weakness" of the system.)
>
>
>
>
>
> 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/ltH6zA/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 - 06:55:05 PST