You bring up an issue we've been struggling with for a while, so I'm going to take this opportunity to talk about it, even though it's tangential to the proposal you sent out.
We've basically come to some of the same conclusions you have (about the nature of Projects) but with a slightly different take on how to model Projects in the app...
======
HOW PROJECTS ARE LIKE ITEMS
You're right in suggesting that Projects need to be "Triaged" just like items do.
It would also be nice to be able to review your Projects wrt Triage status, the same way you do items: Active Projects, Done/Referenced Projects, Deferred Projects...etc (Not quite the 10,000 foot view of your data, but a little higher up than the runway, say 5,280 feet.)
You may also have dozens of projects, David Allen estimates that most people have between 30-100 Active projects, so this doesn't include Archived and Someday Maybe projects. (Feels like too many to fit in the sidebar as collections.)
======
HOW PROJECTS ARE MORE THAN JUST ITEMS
But Projects are clearly more than just Items as well, they have tasks and sometimes sub-projects.
So the conclusion we've come to is that Projects are really a hyrbid thing, somewhere in between a Collection* in the sidebar and an Item in the Summary View.
======
PROJECTS ARE CLUSTERS OF TASKS AND SUB-PROJECTS
What this means is that Projects are a lot like our notion of Clusters**: Lightweight, ad-hoc "threads" of items that live in the summary view and can be found inside Collections or Areas of Responsibility in the sidebar.
So we can now think of Projects (or at least David Allen's notion of a project) as the "head" item of any Cluster. And the Project Plan (aka Tasks and Sub-projects) are just members of the cluster.
Project: Clean out Garage
Task: Go to hardware store
Task: Galvanize cleaning crew
Task: Provide beer and snacks
Sub-project: Organize shelves of crap...etc...
======
ITERATIVE WORKFLOW: PEELING THE ONION
Modeling Projects as Items that can grow to become the head item of a cluster of tasks is also in-line with our belief that users need to be able to process information iteratively and only add structure and complexity to it when they're ready to.
A recurring GTD warning is that most things people conceive of as Tasks are really lower-case "p" projects (ie. Clean garage). Which means it's important for Chandler to allow users to start out with a Task and then realize later that there's more than one task to be done.
So the more intuitive, straightforward workflow is to allow people to:
1. Create or Stamp an existing item as a Task
2. Later come back and flesh out that Task by spawning a Cluster of Sub-tasks
As opposed to:
1. Create or Stamp an existing item as a Task
2. Come back later and create a Collection in the sidebar and add the Task item to the new Project collection in the sidebar.
======
This is the long way of saying that we hope to Triage Projects the same way we Triage Items.
======
ADDITIONAL READING
I still need to write up a coherent proposal for Project Clusters, but here are some incoherent design notes.
========
FOOTNOTES:
*Collections in our model are more like David Allen's "Areas of Responsibility". Things that persist for long periods of time. ie. HR, Grant writing, Status reports. Lisa had a good way of thinking about it which was that the Areas of the Responsibility you have in the Work Sphere of your sidebar should really map to your job description.
**We've talked about clusters on the list before, primarily as a way to model email threads, but they've always been conceived of as user-definable groupings that can contain items of any kind.
On Sep 29, 2005, at 8:05 AM, Daniel Vareika wrote:
I really like the idea of a software that is more of an active assistant than from a passive one. It goes with the lines of the knowledge of a secretary. Someone who is able and capable of simplifying our work/tasks so that we can do what really is important/good at.
Before posting any other opinions/ideas I went through ChandlerInANutshell.ppt and downloaded the latest build to give it a try.
I really like the notion of the Clean up/ Triage => Now Later Done (Junk)
I was thinking while in the Dashboard maybe one as a user, could also assign other properties like to which project it belongs to.
This way we could quickly clean but also organize to where it belongs (GTD)
On the other hand It was not clear to me as there are still many instances of the interface (the latest build to what appears in ppt) if the instance of Cleaning is within the same interface / window or is it a separate one. Personally I believe it should be clear and a separate one so as to get in the mind that we are dealing with the cleaning and organization so as to later do the tasks.
The idea of a proactive assistant (ruled base or other form) together with GTD method triggered me with another idea of UI.
What if Chandler all by itself could archive projects that were finished or inactive for a certain period of time. If we haven´t accessed a project for a certain period of time, or we manually marked a whole project as done. This way we could have a cleaner, less cluttered interface of projects in the left hand of the interface.
<UI - Reference.jpg>
In number 1 we have only the active projects and the ones that are pending.
In number 2 the system/assistant files the projects that are done (by us) or that have been inactive for a certain period of time.
Number 3 is for reviewing a project thats been in our past but that we recall in our mind.
The idea of a reference filing system, that is within hand but is different from the one that is active is really not mine.
Simply I have interpreted David´s concept.
But this way (or some other) we might have the necessary visual clues to separate:
a) Clean Classification (that takes place with the triage in the Dashboard) (clearly with the inbox)
b) A workspace for working
c) A place for filling (like a filling cabinet)
It is good to have a look at what he recalls should be a good office (physical) and even look at his office.
<myoffice.jpg>
As you see the reference filling cabinet is within reach but far away from the "to do workspace"
Yours,
Daniel Vareika
PS sorry before hand if I repeat something that you might have already done or noticed.
I haven´t gone through all the documentation that you have produced over the course of these years.
I sincerely would appreciate your comments.
Philippe Bossut wrote:
In that case, it's a smart tickler, not something you set ("remind me about Vietnam in x months") as described in GTD but something in Chandler that is able to 1) analyse the context of what you're doing and 2) provide automatically references to your personal archive that could be relevant to this context.
It's a very interesting idea. I personally think that software should be more proactive at doing things for you (in this case, fetching relevant infos you forgot you had) rather than simply reacting to user's orders. We'll be moving toward an active assistant away from a passive one.
Mimi Yin wrote:
One thought is that we often files things as "Read someday maybe" primarily because they came to us at the wrong time. As in, one day, I know I will want to visit Vietnam, so I want to archive this article on Pho cafes in Saigon for that "One-day in the future" trip.
The problem is that when we finally get around to planning that trip, will we even remember the resources we filed away in some huge "Travel" folder years ago? And even if we remembered that we had it, would Google find it faster than hunting for it in our PIM?
So the key is, "Someday maybe" items need to reappear on their own later on the "time is ripe" to receive such information. (ie. If you later on finally get around to planning your Vietname trip, rather than having to go dig in your Travel folder to find those articles which you may or may not remember anything about...can the system present you with a: Hey, remember this stuff about Vietnam you tagged 2 years ago? tickler)
<UI - Reference.jpg>
<myoffice.jpg>
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
