Something on missed on the first viewing, but got on
the second: There really is no sense of "hierarchical
document" in Traction. So a message like the one below
goes out as one contiguous whole, rather than a collection
of paragraph-sized fragments. The only for your comments
to appear "in context", therefore, is for you to edit
the node directly. Fine for a single comment, but breaks
down quickly in a long discussion, especially given the
lack of hierarchical display-controls in such a setting.
I'm still impressed they managed to integrate version,
categorizing (plus re-categorizing and an audit trail
of changes), and attributions. But the system as it stands
today seems to run more by queries than by browsing, so
maybe it is more of a "journaling" system than an
interactive discussion tool.
Still: Chris assures us that their whole outfit uses it all
the time, for everything, so possibly there is still a lot
of power to be gained from the system after resetting one's
expectations...
Eric Armstrong wrote:
>
> 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:
> a) 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.
>
> b) 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.
>
> c) 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.]
>
> Eric Armstrong wrote:
> >
> > 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.
>
> > 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 www.jaxo.com for info on
> Pierre's current venture, Jaxo.
>
> ...
>
> > 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.
>
> > 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.
>
> > 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"?
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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 :-)
>
> > 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.
>
> > 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.
>
> >
> ----------------------------------------------------------------------
> >
> > 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.
> ----------------------------------------------------------------------
>
> ----------------------------------------------------------------------
> 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
------------------------------------------------------------------------
Good friends, school spirit, hair-dos you'd like to forget.
Classmates.com has them all. And with 4.4 million alumni already
registered, there's a good chance you'll find your friends here:
http://click.egroups.com/1/2885/3/_/444287/_/956261243/
------------------------------------------------------------------------
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 : Thu Apr 20 2000 - 13:15:08 PDT