Eric,
I've come to the conclusion that this is not the URL you meant.
Google found this post as the first hit when looking and the following URLs
came up, some papers which appear to say precisely what you discuss. The
primary author here seems to be Jim Hewitt.
http://csile.oise.utoronto.ca/abstracts/distributed/ this paper has some
good graphics that show view selection. I really like the knowledge map
diagrams.
http://csile.oise.utoronto.ca/abstracts/ThreadedDiscourse.html this paper
looks like the one reviewed below.
finally, a page of papers basically listed under the theme of
constructivist learning, which, I think, is what dialog mapping is all about.
http://csile.oise.utoronto.ca/csile_biblio.html
Cheers
Jack
At 02:40 PM 7/27/2001 -0700, you wrote:
>Tim Bray. BEYOND HTML: XML AND AUTOMATED WEB PROCESSING
>http://developer.netscape.com/viewsource/bray_xml.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