[unrev-II] Re: Traction Work Product on Categories

From: Eric Armstrong (eric.armstrong@sun.com)
Date: Mon Nov 05 2001 - 12:15:46 PST

  • Next message: Rod Welch: "[unrev-II] Traction Work Product on Categories"

    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
    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 ---------------------~-->
    Clever Cam is a pen sized digital camera, webcam, and mini-camcorder. Just $79.95 at Youcansave.com.

    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:

    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 - 12:03:35 PST