Gack. Wrong URL entirely. (Thanks, Jack. It was your post
of Jim Hewitt's paper that I meant to refer to!)
Note:
This thread is a perfect self-referencing example of
why discussions need to be revised and edited! My post
with the wrong URL and Jack's post pointing out the
error have no long-value to the discussion. They simply
obfuscate the informatioon-content of the thread.
"Beyond Threaded Discourse" by Jim Hewitt
http://csile.oise.utoronto.ca/abstracts/ThreadedDiscourse.html
NOTES
=====
This paper contains an incisive and thought-provoking
analysis of the limitations of threaded discourse systems
-- but it starts by accurately evaluating their benefits.
I'm not totally enthralled with the proposed solution,
but the analysis deserves careful study by everyone
involved in the ohs-dev effort.
Comments/Highlights
-------------------
* "online environments support electronic conversations that
expand and branch, but provide few supports for drawing
together discourse in meaningful ways."
* they "lack support for convergent thinking processes"
(I addressed this issue as a need for "reduction" in the
original requirements paper. In some ways, I think that
is a better solution -- but I've yet to identify a
practical way to implement it! More in a moment.)
* the single-note reply option "reduces the liklihood that
an individual will consider the option of simultaneously
replying to one or more note"
* Even if they do, the note can only "live" in one hierarchy.
--That's the issue that was address by the notion of a
hierarchical document as a "view" on a network of nodes
in the requirements paper.
* "discussions can easily go off track and individuals often
experience a sense of 'information overload' as discourse
structures grow and communal interest begins to fragment."
--One reason: "A" is a statement. "B" is a reply that is
relevant to "A". "C" is a reply to "B" that is relevant
to "B", but pretty far afield with respect to "A". He
calls this the "tunnel vision effect".
* "this contributes to...confusion about the intellectual
focus of the community"
* "Hierarchical structures provide no means of visually
displaying a sense of convergence."
--Here, we will someday part company, if I can *ever*
figure out how "reduction" should occur. What I have
so far is that a simultaneous reply needs to *supercede*
the nodes it replies to, in some significant way.
--The issue, of course, is that not all such replies
are summaries! So that kind of reduction is not always
the right tack to take for a multi-node response.
--By the same token, it should be easy for someone
else to provide a competing summary. And there needs
to be a mechanism for "adopting" a summary -- i.e.
selecting, in the same way that an alternative is
selected from an IBIS discussion (another mechanism
yet TBD).
--If, however, these issues (essentially interface issues)
can be resolved, then a hierarchy can conceivably
introduce a very *nice* mechanism for convergence, by
*inverting* the hierarchy when the occasion demands it.
* The document focuses on "learners" in Computer Conferencing
(CC) environments. However, researchers and designers are
essentially learners. The processes are pretty much isomorphic.
So all the comments he makes about learners in an educational
setting are down=the-line applicable to an online design/
discussion tool.
* Although he usually calls them "CC" environments, at one
point he describes them as "asynchronous conferincing
environments". Talk about an acronym! ACE has legs. It
could go places. Plus spinoffs: TRACE, PACE, GRACE -- you
name it.
* I suspect we should be basing our initial efforts around
the analysis presented in this paper -- if not its
proposed solution. If email is just a way to put information
in the system, let's dispense with the concept of capuring
email messages and go here, instead.
* "How a next-generation computer confercing system be
designed? One appoach is to reconceptualize CC from a
knowledge-centered, rather than conversation-based
perspective."
--I know Jack liked that. I find it scary, but interesting.
Unfortunately, I wasn't able to intuit from the rest of
the paper exactly what that meant in practice.
* "WEBCSILE represents one of several ongoing CSILE team efforts
to support these sorts of processes across distributed
communities".
--sounds great. What are those efforts?
--CSILE = "Computer-Supported Intentional Learning Environment"
(somebody is not too hot at thinking up acronyms)
* He also mentions "an APA-style reference list". What's that?
* Each note includes a list of "Notes that refer to this note"
--ie. backlinks. Doug will like that.
* "a 'Show Entire Thread' button displays all the notes in a
thread in chronological order (rather than limiting you to
a single note at a time?)
--A really good outline display does this without thinking.
This "one pane to select an item and another pane to
display it" nonsense is so much GUI B.S. brought on by
inadequate GUI tools.
(See http://www.treelight.com/software/XmlEditor.html)
--However, the concept of being able to see multiple
notes at one time is absolutely, totally valid. The
solution presented in the paper may not be the best (or
may be the only one practical for the system he has
devised) but it represents a very real need.
* I think the author has the view that showing the nodes
graphically will indicate where convergence has occurred,
and that somehow that will suffice for confergence to
happen.
--I'm not sure that's true, but there may be more
utility to graphical node-representations than I think.
--I tend to distrust that they will do the job as
intended, without becoming overly. I'm still inclined
to pursue the concept of "superceding" nodes in the
hierarchy.
--Doug gave me an example of a sitution where graphic
networks *do* make sense -- it was an app for Bell
Atlantic that helps people identify their clusters
and collect them into sub-networks, or something like
that.
--It occurred to me then that graphic soluions
work when there are only a few elements in the system.
(Let's say 5-7, using that famous limitation of the
human mind.) A person can then look at an arbitrarily
complex collection of nodes, see patterns, and see ways
to group and rearrange things.
--For text nodes, though, where each node is fundamentally
different from every other node, the utility of graphics
is a lot less clear.
--There is one area where good use of graphics makes sense,
though -- prioritizing with respect to evaluations.
Simply ordering isn't enough. A list of 5 options ordered
from best to worst could represent 4 great ideas with
marginal ideas and one bad one, or 4 lousy ideas and one
good one. The system can use graphics to identify the
rating of each node at a glance.
--Beyond that, though, I'm not sure I see a lot of value.
Even with categories, there are so many potential
categories that the system easily expands beyond the
5-7 types that will allow human pattern-recognition to
function well.
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:58:07 PDT