Re: Re: [chandler-users] Chandler + GTD

Hi,

Fwding messages from Users List...

Not to be a stickler about process, but methinks we should be having  
this discussion on the Design List...unless there's a target list of  
questions we want to ask of people on the Users List.

Mimi :)

Begin forwarded message:
> From: Philippe Bossut <[email protected]>
> Date: November 29, 2007 10:43:43 PM PST
> To: Chandler users <[email protected]>
> Subject: Re: [chandler-users] Chandler + GTD
> Reply-To: [email protected], Chandler users <chandler- 
> [email protected]>
>
> 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


Begin forwarded message:
> From: "Poojan Wagh" <[email protected]>
> Date: November 30, 2007 10:37:42 AM PST
> To: [email protected], "Chandler users" <chandler- 
> [email protected]>
> Subject: Re: [chandler-users] Chandler + GTD
> Reply-To: Chandler users <[email protected]>
>
> 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

Begin forwarded message:
> From: "Poojan Wagh" <[email protected]>
> Date: November 30, 2007 11:24:29 AM PST
> To: [email protected], "Chandler users" <chandler- 
> [email protected]>, [email protected]
> Subject: [chandler-users] Clusters vs. Hidden Collections/Tags  
> [Was: Chandler + GTD]
> Reply-To: Chandler users <[email protected]>
>
> Note: for those of you watching only chandler-users, some posts have
> been made to chandler-design.
>
> I think that both Phillipe and Mimi would agree that we want a
> lightweight facility for creating collections/tags/clusters on the
> fly.
>
> Functionally, the following are gaps between what Mimi has described
> and what Phillipe has described.:
>
> 1. In Mimi's cluster system, clusters can be created on-the-fly using
> a lightweight system. Collections (which have a more heavyweight UI)
> still exist. Phillipe wants a lightweight creation of collections in
> general.
> Q: Does Chandler need to distinguish between something lightweight and
> heavyweight? What's the difference?
> Observation: It seems that the syncing mechanism is tied to
> collections, and that might be a reason to keep the separate.
>
> 2. In Mimi's cluster system, clusters appear within another
> collection. Using the tagging mechanism, this means that a cluster is
> tagged with another collection.
> Q: Does Chandler support collections (not discrete items) that appear
> in other collections? Is this the reason to separate heavyweight
> collections from lighweight clusters?
> Observation: Note that if Chandler allowed any collection (not just
> clusters)to be
>
> 3. Phillipe interprets the collections as projects in the GTD system.
> Mimi interprets items as projects in the GTD system.
> Q: Is there an architecture that allows either interpretation (at the
> user's discretion)?
>
> I am purposefully paraphrasing Mimi & Phillipe so that we can isolate
> the differences (and any misunderstanding on my part) and yield a
> better solution
>
> My opinion:
> I strongly like the idea of filling out the notes section of an Task
> item (interpreted as a project) and having it automatically generate
> additional Task items (discrete actions/mails/events) related to that
> project. Personally, I think that whether we call these lightweight
> collections as clusters or collections is irrelevant. The only
> important thing for me is that I can look at my projects and define an
> next action. Or, I can look at an open loop and decide that I need a
> project to manage it.

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

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