[unrev-II] GOOD: Traction, by Twisted Systems

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Fri Apr 14 2000 - 15:12:03 PDT

  • Next message: Eric Armstrong: "Re: [unrev-II] GOOD: Traction, by Twisted Systems"

    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".

    ------------------------------------------------------------------------
    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/_/955750329/
    ------------------------------------------------------------------------

    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 - 15:19:41 PDT