Jack Park wrote:
>
> Damn good post, Eric.
>
Thank you, sir.
> From: Eric Armstrong <eric.armstrong@eng.sun.com>
> > --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.
> >
>
> Of course, the notion of *inverting* a hierarchy will need much more
> elaboration, complete, IMHO, with examples.
>
Yeah. That's the part I still have a lot of trouble with. How
does it work, exactly? When is it applicable? There is a vague
glimmer of intuition there, but the details are still very
hazy. When you add a comment that attaches to several nodes (notes),
there are at least three reasonable "locations::
* above (supercede with a summary)
* below (tie together with an observation)
* orthogonal (a parallel track)
> > * 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.
> >
> Isn't this somewhat akin to turning the Titanic?
>
I suspect it may be. The question is, are we focused on problem,
and designing the best means for solving that problem, or are
we focused on an architecture?
> > * "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.
> >
> Yup.
>
I knew you would like it. :_)
But can you tell me what he means by "reconceptualize CC from a
knowledge-centered...perspective"?
> > * Each note includes a list of "Notes that refer to this note"
> > --ie. backlinks. Doug will like that.
> >
> Open question: are these links put in by the author while creating the post?
> or are they added later, which implies the next question: do we add stuff to
> a post after receipt, or do we do all referencing *above* the post space
> (ala Topic Maps)?
>
I know they're added later. But I'm unclear on the two design options
you describe.
> > --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.
>
> Overly what?
>
overly complex.
The big weakness with graphical systems is that they represent
small amounts of complexity well, but really don't do a good
job with a lot of complexity. I recall a tool that showed
class-library connections, I think it was. Small libaries --
fine. Great stuff. With very large libraries, though, you
would see miles and miles of lines, with the destinations
nowhere in sight. Moving the browser around, you might even
see a screen full of lines going in all directions, with
no nodes anywhere. Or when centered on a node, you might
see so many lines radiating from it that it was impossible
to isolate one -- assuming you could tell which one was going
somewhere interesting. Lattices of connections in a conceptual
map are interesting, but there needs to be some way of
limiting the displayed network to nodes that are somehow
"germane", rather than all possible connections. Which
introduces the problem of defining *that* concept.
> I love to stand back 10 feet or more from a huge graph and try to see the
> patterns or clusters in all the *dots*. I am also in favor of the notion of
> *drilling down*, in which key topics are first exposed. Double-click any
> node and you get a new plane with more detail surrounding that node.
> Double-click again...
>
This is the usual mechanism for displaying nested graphic hierarchies.
That mechanism is forced on us by limited screen real estate. But
if we had a screen the size of a whiteboard -- or a wall -- and the
text size automatically adjusted itself depending on the amount of
information to display, then expanding a node *without* drilling down
is a better option, imo.
In the sort of view, the outer circle remains -- and possibly grows,
while it's contents remain within it. The lines going to the node
remain, but become bigger, fatter "pipes" that break off into
thinner lines when the reach the node wall. The inner lines then go
to the subnodes they connect to.
That sort of expand/collapse capability is the same kind of thing you
see in a directory tree, where you expand/collapse a directory. The
"drill down" proposal is equivalent to visiting the directory and
showing its contents without any of the surrounding context. (Sometimes
that's useful. But more frequently it's helpful to keep as much of the
big picture around as you can. For one thing, it makes easy to move
subnodes to a new location.
> Text nodes can generally be transformed into a named topic, assuming, of
> course, that the text node does, indeed, represent a well-constructed
> thought.
>
Granted. And if the number of named topics is small, that might be
useful. Or would it? Does it help to know there are 5 paragraphs
that discuss "turkey". Or do you really want to know whether the
paragraphs are about Thanksgiving dinner, a sports team, a car,
or the latest movie? To distinguish them, you need more topics,
don't you. Eventually, you get a paragraph that has a whole lot of
labels attached to it. That will be useful, but will graphics be
really valuable, here? Show me a graphic illustration of the
bootstrap mail archive, for example. (Seriously. Help me "see" it.)
Labeled or not, how would I be better able to cope with it
graphically than I can with straight text processing.
> > --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.
>
> So we get to do an IBIS on this?
>
If your asking "can we do a structured evaluation of graphic
alternatives", I think we certainly should. My experience has
so far led me to conclude that it's not a great path. But you
may have a vision of what could be that would change my
experience, and lead me to a different conclusion. To my mind,
it should certainly be part of the discussion. (When you
invoke IBIS, the basic ground rule is to allow *every*
alternative to be proposed, and then evaluated.)
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:53 PDT