Your explanation of Traction category capabilities does not address the question
posed in my letter.... why doesn't this capability strengthen the quality of
work product demonstrated by Traction's letter on 011102, for example here is
what what we got in connection with a phone call inquiring about Traction....
Traction work in connection with your letter on 011030.....
....Traction work on meeting with Doug on 000322....
We are not trying to beat up on Traction and its fine team. But it is critical
to work through what it takes to augment intelligence.
So the IBIS question of the day is why doesn't powerful category capability in
Traction enable better intelligence? Or, if it does, why is power not evident
in the work produced using Traction? Is it the Jack Park issue on 010908; might
there be something missing from the impressive list you presented that is needed
for improving the work, which is the only purpose of the exercise, as you
related on 000423? If we can't improve the work, might as well "forget about
it" as they say in New York, and stick with email because it seems fast and
Eric Armstrong wrote:
> Rod Welch wrote:
> > Just curious why do you suppose "awesome category" capability noted in your
> > letter today doesn't show up in Traction work product? Chris sent a lot of
> > stuff, but the quality of everything was like email: cursory analysis, no
> > structure, no alignment, no summary, no audit trail on follow up that
> > demonstrates command of the microcosm explained in NWO....
> > http://www.welchco.com/03/00050/01/09/03/02/03/0309.HTM#MY6H
> > ....and reviewed in depth on 890523....
> > http://www.welchco.com/sd/08/00101/02/89/05/23/065052.HTM#SQ5L
> > Any random sampling of your work the past two years shows far more
> > analysis than anything seen so far in Traction.
> Thanks for that, Rod. It means a lot.
> Unfortunately, I don't think that the demo he did for the group as a whole
> did justice to the real strength of their offering. I really only saw it when
> he gave me another demo a few days later. I'll try to recapture the salient
> features here, in a list, although it's not quite the same as seeing it:
> 1. Categories appear to the right of paragraphs in a "recessed font".
> Like purple numbers, they used a light blue or purple, so they
> weren't too obtrusive. The categories a node (paragraph) belongs
> to was listed in a column to the right of the paragraph.
> 2. Categories were links.
> Clicking a category took you a list of items with that category.
> (At least I think it did. There was also a multi-category search
> 3. Categories were hierarchical.
> So you could have ToDo:Maybe and ToDo:Definitely, where
> Definitely and Maybe were subcategories of ToDo.
> 4. Categories were selectable.
> A tree-widget displayed the possible categories, so you could
> choose which you wanted to apply.
> 5. Effects of re-categorizing visisble to all
> Easy for them, since it was a single-server system. Much harder
> in a distributed system, but it is the right functionality. So
> I recategorize a node, it shows up in your space when you do
> a search for items in that category.
> 6. Categories were changable.
> So you could change "ToDo" to "FeatureRequest:Open" or
> 7. Effect of category-changes were controllable.
> Lets say you had 25 ToDo items, and you decided to change
> "ToDo" to "FeatureRequest:Open". When you change the
> category name, the system shows you a list of all items in that
> category, with a checkbox next to each. By default, all are
> selected. If there were 10 bugs in that list, you would uncheck
> those. The remaining 15 would become "FeatureRequest:Open".
> You would then change "ToDo" again, this time to "Bug:Open".
> The 10 bug items would now be selected, and you click ok to
> put them all into the new category.
> This was the part that really bew me away, because they had
> allowed for intelligent change-management, making it possible
> for categories to evolve over time, instead of being fixed and
> immutable. With a system like that, it would be relatively easy
> to experiment with different structures for IBIS-style
> 8. Category changes produced an audit trail
> Actually, category changes were just a subset of the normal
> audit trail, which also showed who added or changed nodes,
> and who applied which categories to which nodes, and when.
> It, too, was searchable, so that when your favorite ToDo
> category turned up missing, you could find out who did away
> with it.
> Here, I think they were astute. Rather than doing a full
> versioning system, they simply did an audit trail. I suspect
> that is the "right" answer when the issue is not so much
> reconstructing previous versions (as in a software system)
> but rather in producing one "right" version and either (a)
> figuring out how you got there or (b) being able to use
> parts of a previous version, when it makes sense. Full
> version control may well be overkill, in such cases -- the
> simpler audit trail may well be sufficient.
> As I say, it was a uniquely well-thought out interface for dealing
> with categories, for applying them, and handling changes to
> them. It's too bad that the demo to the group didn't focus on
> that area. I believe it would have been useful and instructive to
> do so.
> Yahoo! Groups Sponsor
> [Choose from 1000s of job listings!]
> Choose from 1000s of job listings!
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-IIemail@example.com
> Unsubscribe: unrev-IIfirstname.lastname@example.org
> List owner: unrev-IIemail@example.com
> Shortcut URL to this page:
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
Shortcut URL to this page:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.0.0 : Mon Nov 05 2001 - 13:23:05 PST