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
