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.
------------------------------------------------------------------------
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/_/956002355/
------------------------------------------------------------------------
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 : Mon Apr 17 2000 - 13:20:13 PDT