Chris Nuzum gave a demo of the Traction system at Doug
Englebart's SRI meeting, today. I must admit to being
considerably impressed. In fact, I think we should begin
using this system as soon as possible to carry our own
work forward. Although it was not exactly the same as
what I would have envisioned, it is the closest thing
I have seen to a complete "Open HyperDocument System",
with hints of "DKR-ness" (Dynamic Knowledge Repository).
[Note to Chris: Open questions are in square brackets,
like this. Any info you can add will be appreciated.]
Before I get to the details, a word on marketing:
The system was presented as a "hypertext journaling
system". The web site calls it a "web journal". That
synopsis does a serious injustice, in my opinion. To
me, that doesn't really sound like much -- and I didn't
look very deeply at it when I visited the site. But the
demo convinced me that I had missed a diamond.
Traction lets remote correspondents investigate, explore,
and collaborate on ideas -- tracking them as they are
gathered and saving them in a queryable database running
on a Java-based server that is accessed through a Web browser.
At the moment, the system is SGML-based, but they are
investigating and XML-ization of it.
(Traction was built with Doug's concepts (and his papers)
in mind, which might help to explain how close it is to
an ideal system. They've also drawn heavily from Ted Nelson's
ideas, which hasn't hurt.)
The system is currently being used by its designers in
France, developers scattered across the U.S., and various
other folks in the Twisted Systems (bad name!) organization.
Every spec and document they produce is developed in that
system, according to Chris.
The good points...
The system seems to function with a two-level hierarchy,
at least from the demo I saw. There are headers and
paragraphs. Paragraphs are added when people add comments.
[I'm not sure where the headers came from. A depth-two
hierarchy may be limiting for some purposes, but there may
also be a fair amount that can be accomplished within that
structure, and there may be deeper structuring we just
Paragraphs are automatically tagged with time and author.
Traction has solved several of the problems I've been
concerned about -- including the ability to categorize
(and *re*categorize) paragraphs. A paragraph can have
multiple category tags. Tags like "for" and "against"
were defined in the demo system we saw, so IBIS-style
discussions can be carried out. Perhaps more importantly,
the tags can be added or changed later -- so the user
doesn't have to "pre categorize" what they intend to say.
The list of categories a paragraph belongs to is shown to
the right of the paragraph, in light blue text.
The available tags are defined by the current context,
producing a hierarchy of tags. Subtags were also allowed
as, for example, "Argument:for" and "Argument:against".
Although those tags were displayed linearly, rather than
in a tree, that is a fairly small defect (and may even be
preferable for fast access and use.)
Traction lets you choose the paragraphs to display,
depending on their tags. Their "rapid selector" box
allows abbreviations [or requires them?] so you can
change the view rapidly.
(When it came to categorizing nodes, I couldn't decide
whether a category was a property (attribute) of a
node or an external heading that the node "belonged"
to. Catagory-based queries gave me the answer. In
essence, there is a category header that contains a
list of nodes. Each node also has a list of categories
to which it belongs. Searches then follow category
lists to get nodes. The node's list of categories is
then inspected to fill in the display.)
In addition to making it possible to change a node's
category, Traction makes it possible to change the
categories themselves. That feature was motivated by
Ted Nelson, who pointed out that our sense of organization
changes over time. So what is marked "ToDo" today,
can rather easily be modified to be one of "Feature:Open"
or "Bug:Open" in the future. When you decide to make a
change, the affected nodes are listed. You can then
select which ones are affected.
An "audit trail" is maintained for all changes to categories
and node-categorization. Going back to the a previous date
in history will therefore show a node marked as "ToDo",
rather than "Feature:Open" (if that's what it was changed to).
They use Internet Explorer [4? 5?] and used the
"whole-screen expansion" function which had the
interesting effect of pushing the URL and toolbar
buttons off screen. The interface they provided to the
Traction DB then "takes over", so you pretty much forget
you are in a browser -- it looks like an app.
Editing looked a lot like using a normal editor. When the
editor came up, it showed a serious of paragraphs, and you
could then add new paragraphs between them. The editing
therefore took place "in context", rather than being in
a blank window.
[Q: I saw that new paragraphs could be added. But I didn't
see whether a paragraph could be edited. I suspect it
should be possible, but don't know for sure.]
Chris said they used "simple linear versioning". [By that,
I presume he mean chronological versions, with no branching
of versions. Need to clarify.]
Editing capabilities were restricted by access controls. So
it seemed to be possible to limit changes to the designated
author(s). [I seem to recall that it was possible to add
someone to the author list, but I'm not sure if I really heard
It was possible to refer to other nodes in the database, the
demo did that using a name and number, like "Traction348".
Although normal hypertext links weren't shown, they are almost
certainly usable. [Yes?]
[TBD: Drag and drop of text is supported. Is it possible to
drag and drop a node link, as well?]
All in all, the system seemed to be good deal closer to a
usable DKR than anything I have seen to date. If nothing else,
we should probably use it to help carry on our discussions of
where to go next -- both for the advantages it offers over
email and for the opportunity of "springboarding" to define
the next level of desirable features.
The major limitations observed so far are:
They use Ted Nelson's term "transclusion" for this. At the
moment, you can link to other items in the database, but you
can't include them inline. They are carrying on discussions
now on how to go about that.
Multi-level hierarchy (?)
[Is it possible to create hierarchies that are more than two
levels deep? Is there some reason that *isn't* desirable?]
[There is a versioning system, but does it apply to replacing
one hierarchy with an edited copy that has nodes deleted? That
would allow a discussion to be replaced with a reformulated,
reorganized version. I seem to recall Chris saying something
about selecting multiple nodes when creating a new one, but I'm
unclear about what happened after that.]
There is a "summary" capability, but it is intended for high
level abstractions, rather than the kind of "reformulation"
I have been envisioning. (I've been calling that process
"summary" but Rod's questions pretty convinced me I had the
wrong name for it, and this demo pounds in the final nail.
(Chris mentioned that the "summary" capability hasn't seen much
use so far. I suspect that is because summaries appear outside
the normal stream of access, rather than as an integral part of
the information stream.
This *might* be the one major gap in the system -- the ability
to replace an entire hierarchy (or chain of discussion) with an
edited version of same. That capability is necessary to convert
a great "journaling" system in an even greater "knowledge
Avoid the lines and visit avis.com for quick and easy online
reservations. Enjoy a compact car nationwide for only $29 a day!
Click here for more details.
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIemail@example.com
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Fri Apr 14 2000 - 15:19:41 PDT