Re: [chandler-users] Chandler + GTD

Thank you for the summary Poojan. (Again, moving discussion over to  
design.)

I agree with all of the things Philippe proposed. I do think though  
that we need both the functionality on his list *and* a way to link  
items together in the Triage Table. My sense is that there are just  
that many levels of granularity (3) in the way people organize  
information. It's when you start wandering deeper and deeper into  
4-5-6-7-8-12 levels of hierarchy that the human brain exceeds it's  
capacity to keep things straight.

Something we haven't talked about for a *long* time is the idea of  
'Spheres', essentially a way to group collections in the sidebar. You  
can think of it as having multiple sidebars, stacked in a single  
sidebar because you would have an all-encompassing 'Dashboard'  
collection for each sphere. So my spheres might look like:

Dashboard
In
Out
Trash
-----
Home (Dashboard)
+ Holmes
+ Family
+ NYC Events
+ SF Activities

Work (Dashboard)
+ Peepeedee
+ Strategy
+ Evangelism
+ Office Cal

Extra-Curriculars (Dashboard)
+ Blog Notes
+ MPITC

===
1. Like the Dashboard we have today, each sphere's dashboard would  
contain all the collections in that sphere, unless you chose to  
exclude it. For example, I might exclude the Office Calendar from my  
'Work' sphere Dashboard.

2. I could imagine that it'd be useful to have a single collection in  
multiple spheres

3. Items can certainly continue to belong to multiple collections  
*and* multiple spheres

I think this behavior maps pretty well to how some people are already  
organizing their email and calendar data today.

How might you map your spheres?

Mimi

On Nov 30, 2007, at 10:37 AM, Poojan Wagh wrote:

> Hi, Philippe.
>
> I have been independently toying with the idea of having
> collections/tags show up as tabs. This is essentially what is done for
> the Calendar interface. Why not apply it to the other items (Mail,
> Tasks) as well?
>
> The way I envision it, all (or a user-definable subset) of the
> collections can appear horizontally as a tab-bar near the top. Each of
> these tabs have a check button. Clicking the check button makes the
> elements within the tab appear on the item list (or calendar). This
> tabulation would provide a more cohesive experience between the
> Calendar view and the item list view.* Of course, the same
> functionality could be offered with the interface the currently
> exists: make the filtering that occurs with the Calendar also apply to
> item lists. I just like the poetry of having tags appear as tabs.
>
> More to follow...
>
> Footnotes
> * I find it non-intuitive that when I hit the "All" button, only items
> in the selected collection appear. However, when I select "Events",
> the overlay of the checked collection appears in the Calendar.
>
> --
> Poojan
>
> On Nov 30, 2007 12:43 AM, Philippe Bossut  
> <[email protected]> wrote:
>> Hi,
>>
>> I'm of a different point of view on the use of collections. I  
>> decided to
>> totally embrace the fact that collections are not disjoint sets (one
>> element can be in several) and I therefore use them more as  
>> "tags" (or
>> "play lists") and create them very liberally. Currently, I'm using 17
>> collections and I'm refraining to create more only because of some UI
>> oddities, chiefly among them, the fact I can't reorder them at  
>> will. But
>> that aside...
>>
>> *Theory*
>> I think there is a very strong incentive to use one single vanilla
>> mechanism to group elements instead of creating a bunch of categories
>> (clusters, collections, tags, labels, etc...) with similar but  
>> different
>> properties. For the same reason we believed there shouldn't be  
>> different
>> kind of items ("no silo"), one shouldn't invent different kind of  
>> sets.
>> So, humor me a little here and make that claim: the collection is the
>> only single grouping mechanism we really need.
>>
>> *UI*
>> Of course, we need a *better* UI than the one we have today so  
>> that we
>> can indeed make use of gazillions of collections (or call them  
>> tags, or
>> labels, or clusters...). So here's a short list a incremental UI
>> improvements that'd go a long way (in order of priority):
>> - allow collection to be "hidden" from the sidebar: one should have a
>> list of all user defined collections in the collection menu (or,  
>> better,
>> a specialized view if we have gazillions of them...) and be able to
>> check them or not to make them viewable in the side bar. If I had  
>> that
>> feature today, I could reduce my list of 17 collections to 5 (the  
>> one I
>> consult everyday) and pop into view the one I need only rarely when I
>> need them. Also, in the mind of the user, this create a neat  
>> equivalence
>> between tag (hidden collection) and folder (viewed collection),
>> although, internally, there's no real difference and one can  
>> become the
>> other at will.
>> - allow the "Appears in" widget to be editable: that's one of my pet
>> peeve but, really, it's frustrating to have that list there and not
>> being able to edit it, particularly when you want simply to  
>> "remove" the
>> item from a collection. This would make tagging easier also:  
>> simply add
>> the tag there.
>> - allow collections/tags to be created "on the fly" in the quick  
>> entry
>> field: additionally to editing the appears in, one should be able to
>> type "/tag foo" and have all the selected items dropped into said foo
>> collection. If that collection/tag doesn't exist, just create it.
>> Infinitely faster than drag and drop (the only way we have today  
>> to move
>> items). Also, imagine the power of that scenario: type "/find foo",
>> select all the results, type "/tag foo" and you created a  
>> collection of
>> all your foo items reusable any time.
>> - allow computed collections to be defined in the quick entry:  
>> cheery on
>> the cake, one should be able to create a computed collection using
>> logic. e.g. type "/collection stuff = foo AND bar" and you create a
>> collection that's the union of those 2 sets. Note that we have that
>> logic in the repo today. It's a very geeky feature (so last in my  
>> prio
>> order :) ) but incredibly powerful.
>>
>> Well, ok, that last point is may be too much. But I think the first 3
>> ones would go a long way to address the clustering items issue  
>> pointed
>> to by Poojan initially.
>>
>> Cheers,
>> - Philippe
>>
>>
>>
>>
>> Mimi Yin wrote:
>>> Hi Poojan,
>>>
>>> This is a good, but hard question to answer. I know there are other
>>> GTD practitioners on the list, so please pipe up with your own
>>> experiences!
>>>
>>> In my experience, Chandler Collections are too heavyweight for GTD
>>> projects, which are intended to be bite-size and are therefore too
>>> numerous to really fit in the sidebar.
>>>
>>> The short answer is that Chandler's version of GTD 'projects' is:
>>> 1. Create an item for the project and mark it as a Task.
>>> 2. Jot down next actions and related thoughts in the Notes field of
>>> the Task item.
>>> 3. Cycle the Task item between NOW and LATER as your make  
>>> progress on
>>> the project.
>>>
>>> I even go so far as to track Done and Un-Done 'sub-tasks' in the  
>>> Notes
>>> field.
>>>
>>> This is clearly a hack. But one thing to note is that David Allen
>>> himself advises people *against* spelling out the list of sub-tasks.
>>> Just write down the Next Action.
>>>
>>> Nevertheless, as sub-tasks emerge from projects, there's no question
>>> that there's a real need to be able to group and order items  
>>> together
>>> into "something more than an item, but less than a collection". In
>>> past design discussions, we've called this grouping a *cluster*.  
>>> It's
>>> something akin to an email thread, but more flexible in that  
>>> clusters
>>> are *not* limited to just email, members of the cluster can be  
>>> members
>>> of multiple clusters, and users should be able to add/remove items
>>> from a cluster.
>>>
>>> You can read more about clusters under "Lightweight Organization,  
>>> aka
>>> Project Management, aka Clusters" on this page:
>>> http://chandlerproject.org/Product/ 
>>> ProcessingInformationTriageDashboardClusters
>>>
>>>
>>> Re:
>>>> Once I do item #1 I want item #2 to appear on my "Now" list. Is  
>>>> this
>>>> function possible?
>>>
>>>
>>> I'm not sure there is a 1:1 mapping between Triage Status (NOW,  
>>> LATER,
>>> DONE) and whether a task is blocked versus not blocked. Meaning,  
>>> just
>>> because #1 is DONE and #2 is up-next, doesn't necessarily mean  
>>> NOW is
>>> a good time to address #2.
>>>
>>> For example, if I have a GTD project around attending a wedding
>>> scheduled for 6 months from Today. I may need to send in the RSVP  
>>> for
>>> the wedding next week, but don't really need to or want to worry  
>>> about
>>> the wedding gift for another 4-5 months. (Actually, isn't the
>>> acceptable timeframe for wedding gifts, up-to-1 year after the  
>>> wedding?)
>>>
>>> Another thought is that sub-tasks aren't always linear. In fact,  
>>> more
>>> often than not, they aren't. If you're at the bank, but haven't made
>>> the call to schedule a time with the mechanic, you might go ahead  
>>> and
>>> transfer the money anyway, just because then it'd be done and you
>>> wouldn't have to worry about it. Arrange drop-off and pick-up  
>>> might or
>>> might not be the same person, depending on the kindness and
>>> availability of your friends ;)
>>>
>>> Anyhow, the long and short of it is, Today, there is a way to model
>>> GTD projects as individual Task items in Chandler today. Longer  
>>> term,
>>> we're looking at Clusters as a way to flesh out the project tracking
>>> workflows you're describing.
>>>
>>> Anybody else have personal experiences that might lend some  
>>> insight on
>>> this topic?
>>>
>>> Mimi
>>>
>>> On Nov 17, 2007, at 1:36 PM, Poojan Wagh wrote:
>>>
>>>> Hi, Users.
>>>>
>>>> I was wondering how things in GTD map to Chandler, and I was  
>>>> wondering
>>>> if any of the other users have a workflow in Chandler that seems  
>>>> to work
>>>> well. I have a few specific questions about how Chandler works  
>>>> with the
>>>> typical GTD scheme.
>>>>
>>>> For example, let's suppose I create a project "Get car fixed" in
>>>> Chandler (as a collection). I then have the following actions:  
>>>> 1. Call
>>>> mechanic for an estimate & appointment 2. Transfer cash to checking
>>>> account 3. Arrange for a drop-off ride 4. Arrange for a pick up  
>>>> ride
>>>>
>>>> Is there an easy way in Chandler to designate one of these  
>>>> actionable,
>>>> and defer the others? Once I do item #1 I want item #2 to appear  
>>>> on my
>>>> "Now" list. Is this function possible? Is this capability  
>>>> planned? Can I
>>>> do it without looking through all my deferred actions and re- 
>>>> assigning
>>>> an order?
>>>>
>>>> I have more questions, but I will save them for later.
>>>>
>>>> --
>>>> Poojan
>>>> _______________________________________________
>>>> chandler-users mailing list
>>>> [email protected]
>>>> http://lists.osafoundation.org/mailman/listinfo/chandler-users
>>>
>>> _______________________________________________
>>> chandler-users mailing list
>>> [email protected]
>>> http://lists.osafoundation.org/mailman/listinfo/chandler-users
>> _______________________________________________
>> chandler-users mailing list
>> [email protected]
>> http://lists.osafoundation.org/mailman/listinfo/chandler-users
>>
> _______________________________________________
> chandler-users mailing list
> [email protected]
> http://lists.osafoundation.org/mailman/listinfo/chandler-users

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design