Colloquium at Stanford
The Unfinished Revolution


Date: Sat, 19 Feb 2000 16:21:35 -0800

From: Eric Armstrong Reply-To:

To: ""

Subject:   DKR/OHS: 5 Authoring Requirements

Five fundamental operations the system must have...

  1. Segment Collection

    It should be possible to specify a document you are working on as the "current target", and then roam through out the Document Repository, select text, a node, or a subtree and invoke one of the following operations:

    1. make reference
    2. copy

    The reference or copied text then appears in the target document. For the copy operation, both the copied text and the reference to where it came from are instantiated.

    After the reference/copy operation, the context does *not* switch to the target document. You stay where you are, so you can keep browsing and selecting additional items.

    As a side effect, setting the target document should mark that page so you can easily get back to it.

  2. Context-Sensitive, Multi-Level Pagemarks

    The PageMark list should be context-sensitive and multi-leveled. When you access a document, the pagemarks in that document should be readily available. They may have been accessible in a hierarchy before, but they should now be readily available, and possibly displayed.

    There should also be a working list" of pagemarks. At a minimum, that list would typically consist of the target document for reference/copy operations and the document being read ("mined") for references.

    An easily-selected operation should allow cycling among entries in the working list, so you can rapidly change context between multiple documents you are working on.

  3. Automatic Destinations

    When you are in a functional specification, and you create a design note, that "target" document for that note should be automatically determined by the current context.

    The implementation may use pre-specified target locations for nodes of a given type. For example, "design notes" for a given functional spec might go into a predefined "design document" hierarchy. Alternatively, the system might allow building preliminary document-versions using queries, like: "Give me all design notes that correspond to functional requirements in this version of the design doc"

  4. Automatic Linking of Typed Nodes

    When nodes are created, they are necessarily typed. The default for a new node is the type of it's parent. It then lives under that parent. For example, creating a new node under a functional specification heading produces a functional specification node.

    It should also be possible to create a node with a different type -- for example, when creating a design note. Links are then automatically created between the new node and the origin node, unless you specify "unrelated". (That lets you track random thoughts that occur to you and have them go the right place without a meaningless link.)

    It must be possible to easily see and select node types from the current context. Node-relations must be defined as well. For example, if you create a design note from a functional-spec node, the need for a link is defined by that relationship (unless you specify otherwise). On the other hand, if you create a personal-calendar node after receiving a phone call, the system should understand that the default in that case is "no link", unless you specify otherwise.

    TBD: Should node types be pre-defined? If they are, it prevents one person from specifying "Design Idea" while another specifies "Design Note" or "Design Topic". Without that regularity, it becomes impossible to ensure that a query has accessed all the relevant information. On the other hand, on-going investigations into "wicked problems" may need to organize as they go. So it may be best to allow node-type creation on the fly.

    [If specified-targets are used to define "destinations", the system can ensure that a second type does not point to the same target. That is not a complete solution, since competing targets could be created. In that case, a merge operation might be a solution. It would need to a) put the two documents together and b) change all links of one type to the other type. On the other hand, if the query system is used exclusively to find related nodes, then there would be no checks at all on dynamically created node types.]

  5. Drag and Drop Produces a LINK

    With a node-typing system comes the need to change a node's type. As the problem is better understood, thoughts originally captured in one venue will need to be retargeted for a different purpose.

    XML's entity references leap to the rescue here. (Unfortuantely, the term "reference" is a misnomer. Syntactically, there is a "reference" to another information node, but semantically that node is "copied" inline into the current document. So it's not a "reference" the way you think of a book reference. Instead, it's a "reuse" of the specified entity. So "Entity Reuse" would be more descriptive. Possible terms based on that might be "entity reuse reference", "entity reuse link", "entity reuse specification", or "entity reuser".

    Given the existence of "entity reusers", it becomes clear that the result of a drag and drop gesture should be the production of either an entity-reuse-link or a reference-link to the original document segment. Doing that lets you recategorize information without changing the original. A "move" operation thus consists of a) Linking to the original from a new location and b) "Deleting" the original from the new version of the document. (It still exists in the old version.)


Eric Armstrong>