One more limitation, at the end. (Not distributed.)
Eric Armstrong wrote:
>
> URL: http://www.twisted-systems.com/
>
> 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.
>
> Overview
> ========
> 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.
>
> Features
> ========
> The good points...
>
> Hierarchy
> ---------
> 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
> didn't see.]
>
> Attribution
> -----------
> Paragraphs are automatically tagged with time and author.
>
> Categories
> ----------
> 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.)
>
> Queries
> -------
> 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.)
>
> Flexible
> --------
> 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.
>
> Historical
> ----------
> 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).
>
> Interface
> ---------
> 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
> -------
> 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.]
>
> Versioning
> ----------
> Chris said they used "simple linear versioning". [By that,
> I presume he mean chronological versions, with no branching
> of versions. Need to clarify.]
>
> Permissions
> -----------
> 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
> that.]
>
> Linking
> -------
> 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?]
>
> Limitations
> ===========
> 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:
>
> Inclusion
> ---------
> 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?]
>
> Reduction (?)
> -------------
> [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
> repository".
> ----------------------------------------------------------------------
>
Not Distributed
---------------
Since the system isn't distributed, there is no way to identify
new and changed nodes that *you* haven't read. (Or maybe there is,
but it is going to be a ton of extra work for the server.)
With a distributed system (like email) it becomes possible to
more easily identify changes and new material, as well as keep
track of material that has not been visited.
------------------------------------------------------------------------
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.
http://click.egroups.com/1/3011/3/_/444287/_/955762958/
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Fri Apr 14 2000 - 18:50:04 PDT