Hi, Mimi. I agree that forming a syntax that directly generates an item is desirable. In addition, I also think it should be possible to take a pre-written note and generate (linkable) items based on its contents--possibly by selecting a word or phrase and then right-clicking to generate an item. The reason is that a lot of times, one needs to brainstorm very quickly, and then re-assess what one has written. (Although I could argue that such brainstorming might better be done on paper, and then entered into Chandler.)
(I could also argue that by editing the note and entering the right syntax, a user could generate the items after the fact, but a menu option would likely reach more people.) P.S. I agree: Clusters, like hierarchies, have branches. And Ogres, like onions, have layers. :) -- Poojan On Nov 28, 2007 1:37 PM, Mimi Yin <[EMAIL PROTECTED]> wrote: > > http://lists.osafoundation.org/pipermail/chandler-users/2007-November/000961.html > > Hi Poojan, I'm going to re-route this discussion over to the design list > because I think there are people over here that would be interested in > seeing / participating in this discussion. > > Yes, this would be an excellent way to generate 'clusters of items'. Have > you played around with Microsoft One Note much? It's primarily a note-taking > tool, but you can create discreteTasks items while taking notes. > > I think there's great value in the ability to 'contextualize' Chandler Items > (Notes, Tasks, Events, Messages) within the notes we take while in meetings > or just scribbling down ideas for ourselves. > > We could also re-use the syntax we've started to develop in the Quick Entry > field. > /Task, /Event, etc... > > I think the main pieces to get this working would be: > > 1. Visual feedback in the Notes field. It doesn't have to be fancy, but once > you've created a Chandler Item in the Notes field, it should look different > from the text that surrounds it. It could as simple as: /Task xxxxx xxxxxx > xxxxxxx > > A background lozenge (a la Apple Mail) or color highlight would be nicer > because it would be a visual affordance that the user couldn't accidentally > mess up. > > 2. Bi-directional editing. If I create a Task in the Notes field of Item A > and then edit that Task in the Triage Table View, the Task in the Notes > field of Item A should update accordingly and vice versa. > > 3. Visual feedback in the Triage Table. Some way of highlighting items that > belong to the same cluster. And/or better yet, some way to cluster them > together on an as-needed basis. It could be as simple as a right-click > context menu: Show Cluster. > > > On Nov 27, 2007, at 9:54 PM, Poojan Wagh wrote: > > Here's a wild idea: why not allow the creation of these ad-hoc > "clusters" using a wiki-like method? In the notes field, the user > simply enters some designator ([[task1]] for example). This designator > immediately becomes a new item in the collection with some sort of > "link" or "tag" back to the original item. (Alternatively, a new > collection can be made for the master item on the fly, with the newly > created designator being an item in the collection.) > > The way I see it, there are (at least) two methods to implement this > "break down a project into next items" issue: > 1. Hierarchical: where there is a parent-child relationship. > 2. Flat: where new items are created ad-hoc at the same level as the > master. (For this to be useful, some sort of linking facility might be > required). > > I think the model is actually 3: A lattice, or some permutation of 1+2, > depending on how you think about it. > > With Clusters, what we really have are threads of items. Sometimes the same > item will be a part of multiple threads, meaning threads intersect. > Sometimes a single thread will split apart only to merge back together. In > other words, we can think of the clusters information model as a lattice. In > a sense, it's "flat", but it's not simply linear because like hierarchies, > lattices have branches, but unlike hierarchies, the nodes in a lattice > (items) aren't contained within a single branch, but instead can join many > branches together. > > Sorry to be so abstruse. This is a semi-religious topic around here, > especially for me. I can send pointers to past write-ups/discussions for > more context if we want to delve into this topic more. > > > > Now that I think of it, the ad-hoc generation of items through a > deisgnator would probably work with either method. It's just > implemented as a flat database in Wiki systems. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
