"This paper" is about why you should use xml. I did a search on "threaded"
and got no hits. Wrong url?
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