Colloquium at Stanford
The Unfinished Revolution


Memorandum

Date: Mon, 17 Apr 2000 13:12:12 -0700

From:   Eric Armstrong
Reply-To: unrev-II@egroups.com

To:     unrev2 unrev-II@onelist.com,
critters

Subject:   Traction, by Twisted Systems]

Below are Chris Nuzum's excellent responses to the open questions I had in my Traction overview. The only "gaps" in the system appear to be:

  1. Evaluations

    This is something I neglected to mention previously. so Chris might have a response to this, as well. The idea is having the ability to record evaluative comments, along with a rating (e.g. 1..5), that can be averaged, so that entries can be sorted by rating.

  2. Distributed Operation, like email

    I seem to be in a minority on this subject. So maybe it's not as relevant as I think it is. Chris says below that adding "not yet read" flags isn't that much overhead -- the real issue is an interface decision: deciding what constitutes "read". (Went through that same question myself. Decided that the two mail systems I've seen got it right: A configurable number of seconds after you've visited a node counts as "read", plus you can always change it back.

  3. Fast Reduction Mechanism

    Chris points out that you can do individual reductions by changing the tags on a node. So a mechanism does exist that allows for reduction. I'm still seeing an "edit copy of subtree" operation that allows me to reorganize nodes, remove them, and then post the new version of the tree as a replacement -- but that is a fairly document-centric operation. When "documents" are totally virtual, resulting from a query of database nodes, its hard to see exactly what such an operation implies -- what happens to the nodes I deleted with respect to other views?? Still, I expect there is an answer somewhere.

Overall, when you compare this system to my earlier list of OHS requirements, this system meets the large majority of them. So I continue to give it an enthusiastic thumbs up. [Chris: I'll send you that list.]

Sincerely,


Eric Armstrong
eric.armstrong@eng.sun.com


Copy to:

  1. cjn@twisted-systems.com





[Evidently these are extracted remarks by Chris Nuzum...]

Eric Armstrong wrote 14 Apr 2000 15:12:03

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.

Thanks for the compliment. We've worked hard on this, and as we all know from Doug's experience,, getting the message out about this kind of system can be difficult.


Eric Armstrong wrote 14 Apr 2000 15:12:03

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.

Actually, what I meant was that our background was in SGML systems; Greg Lloyd and I met at EBT, where we worked on DynaText. Traction makes extensive use of XML tools, including Pierre Richard's excellent XML parser and XSL transformer -- see

http://www.jaxo.com

...for info on Pierre's current venture, Jaxo.


Eric Armstrong wrote 14 Apr 2000 15:12:03

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.

Geographically speaking, Traction was mostly designed and built in Providence, RI and Washington, DC. The parser and transformer were imported from France. The distributed team uses Traction as its primary coordination vehicle.


Eric Armstrong wrote 14 Apr 2000 15:12:03

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

In our terminology, the Traction "journal" collects "entries" in "projects". Entries may be of various types, corresponding to different XML content models. So far, the main type we have implemented and use is based on an email message with n paragraphs (actually HTML block containers). The first paragraph is rendered as the subject, the rest as body. Each one is addressable.


Eric Armstrong wrote 14 Apr 2000 15:12:03

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.

Allows... but who really wants to write "newspage week today" when they can write "nwt"?


Eric Armstrong wrote 14 Apr 2000 15:12:03

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.

I demonstrated Traction using IE 5 on Windows, but it works just as well with IE 4 and Netscape 4.x. Hit F11 in IE to go to full-screen mode; right-click on the top toolbar and select auto-hide to get rid of it. Right click on the task bar, select properties, and check auto-hide to get rid of it. I wish Netscape had a similar full-screen browsing feature. It's very addictive.


Eric Armstrong wrote 14 Apr 2000 15:12:03

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

You *can* edit the paragraphs. Next to each paragraph we display a marker, e.g. [04]. It's this marker to which the labels (tags) are attached.


Eric Armstrong wrote 14 Apr 2000 15:12:03

Versioning

Chris said they used "simple linear versioning". [By that, I presume he mean chronological versions, with no branching of versions. Need to clarify.]

That's correct. We call the versioning mechanism "update" (used to be "correct"), and we originally intended it to allow you to fix errors or reflect changes in fact.


Eric Armstrong wrote 14 Apr 2000 15:12:03

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

Permissions include read, submit, update, reclassify, create category, administer project, administer server. They are scoped to projects.


Eric Armstrong wrote 14 Apr 2000 15:12:03

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?]

Sure; click any cross-reference to follow it. All URLs are recognized and become active links. Links within the journal are bi-directional.

[TBD: Drag and drop of text is supported. Is it possible to drag and drop a node link, as well?]

Drag and drop depends on the interface you are using; Outlook and IE support it. Other browsers vary.


Eric Armstrong wrote 14 Apr 2000 15:12:03

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.

Right. Until we integrated the XSL transformer, there was a danger of violating the HTML content model when transcluding arbitrary other segments of the journal. We've come so close to "just doing it", because it's such an appealing feature, but we wanted to make sure it wouldn't cause support problems; you might be surprised at how badly browsers can get wedged when you feed them mangled HTML. But now we can hardly wait to turn it on! We do (carefully) already transclude the title when displaying cross-references; when the title is updated, all cross-links will reflect the change.

Other problems with transclusion include interface issues relating to whether you expect to find fulltext search hits in in/transcluded content, how you address into included content... doing this feature right does get a little tricky (when I talked with Doug about this yesterday, he said they had run into the same questions, and that nobody had "funded the research" to answer them :-)


Eric Armstrong wrote 14 Apr 2000 15:12:03

Multi-level hierarchy (?)

[Is it possible to create hierarchies that are more than two levels deep? Is there some reason that *isn't* desirable?]

Our categories *can* be n levels deep. Perhaps the confusion came in when I explained that we have some predefined structure at the root level.

::project:partition:you:can:go:as:deep:as:you:like

Partitions include topic, action, discussion, resource and "response" or "semantic". Topic is the "default" partition, so ::project:topic:news is the same as ::project:news.

We support wildcards in the Rapid Selector to allow you, for example, to look at ::*:*:open.


Eric Armstrong wrote 14 Apr 2000 15:12:03

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

Regarding summary and reduction...

Summary in Tration lets to take some set of entries and post a new entry which "summarizes" the other set. Whenever you look at any entry, you can see what entries summarize it. Summaries are listed in order of most specific to most general; a summary of a specific set of entries would be listed before a summary of the month, which would in turn be listed before a summary of the year.

Summaries of a time period are displayed on the newspage covering the time period. So you can post a status report on Monday morning summarizing last week, and it will appear on last week's newspage.

For the idea of reduction, note that the primary method Traction currently has for threading discussions is by tagging the relevant messages (or paragraphs) with the discussions to which they belong, e.g. this paragraph might be part of :discussion:traction.

If you later want to prune the thread, or post a summary, you can just change what entries (or paragraphs) are labeled ":discussion:traction". The ones not labeled will fade into the background (unless you go looking for them using Traction's perspective control). While not exactly what you are looking for, it is a form of reduction which you might find interesting to work with; we use it extensively.



[In another letter Eric submitted to the Colloquium that is not reported in the record...]

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.

Actually, this isn't too much overhead to add. We've thought a lot about it. Many people have suggested it. Interestingly, we don't really miss it much day-to-day.

We use labels to flag things for each others attention (e.g. someone who wants me to see something tags it :cjn), and we use labels to indicate when we have completed something, (e.g. cjn:done).

We can also use labels to indicate read & understood. The real interface issue for marking something read is "what constitutes read?" Shoud we mark read those entries which have

- been generated in any view,
- in just a single-entry view,
- on a newspage you've looked at,
- only those that you have explicitly checked off.

We have lots of suggestions on how we might incorporate the; it's been more of an interface puzzle than a technical hurdle.