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
