Mimi:
It took me some time to read and digest the whole e mail since I am
not that familiar with all the work you have done with Chandler.
After fully reading it for a second time, and reading all the links
(except the paper from Xerox Parc) I agree with you completely with
your line of thinking.
Still, as you do, one believes that there must be some other ways to
solve this puzzle.
The more I think of the complexity that Chandler and its
infrastructure means the more I see it as a daunting experience, but
still that´s the beauty underneath, to be able to manage this huge
amount of energy into a coherent, manageable form.
While reading the notes and even before, I had other ideas I would
like to share with you (all).
Some are small, some are semantic and some others might go in
straight collision with the work you have done, though they are not
meant to do so.
*Analysis of User Centric Approach to Projects
Step 1 /Cleaning/Classification/
*This has to do with the triage concept together with (if defined
before hand or at the moment) to classify into a Project /Collection
*Step 2 /Work in Progress
/*In this step one should be able to do the work, not classify it or
clean it, just do it, either project centric or task centric (like
make all the phone calls)*/
/**Step 3*/* Archiving of Projects/Collections
*/Obviously after one having done/processed tasks from the work in
progress, one files those items back to their folders and drawers
(disappearing act) so one can continue with the next act.
Because of the nature of Chandler, some of this disappearing act
should be done automatically.
Obviously this 3 steps are not necessary sequential nor take only 1
time in the whole day, but are in fact very different activities that
one, as a person, assumes as a role for an specific amount of time.
I personally and subjectively believe that the UI for those 3 steps
might benefit if they are different but with a very fast switch
between them (so as not to loose time, but show only the necessary
information)
*Project/Collections*
As you mention should have at least (and only I believe) three fields.
One should be a short description
Another should be the positive outcome/goals (GTD)
The last one should be marked as done (GTD)
*
Analysis of current e mail program*
Looking at the left side of my e mail program, trying to clean up my
In box, I realized (and this is not new to you) that the program is e
mail centric and not user centric.
Unsent messages -> should tend to disappear. We are having even more
broadband, always on line, and people have changed the way they use
the Internet, so I think this should tend to disappear (at least as
an Icon or folder)
Drafts -> from the Chandler user experience, you can first make a
note (not sure if this is the right semantic) and then assign a
property like email. Also tends to disappear and should be
Collection/Project instead
Sent -> is it the best place to put things? what would be the correct
metaphor. I know I haven´t digged deep enough in the research you
have made in Chandler but one thing is for sure, it will also tend to
disappear. This is more of an attribute of the email or other things
that are sync to others.
Junk -> Junk does not disappear, it is growing, still I believe that
it shouldn´t be not even near the projects/Collection pane. It takes
valuable space (a lot) for something we occasionally go to. It should
disappear from the pane altogether, or have a different importance.
Trash -> The same as Junk
/* This small, subjective analysis was made for Thunderbird not for
Chandler
/
*Semantic*
Deleting vrs Removing (for me sounds the same)
Delete vrs Hide (is it more whats up to?)
Yours,
Daniel Vareika
PS 1: As always, 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.
PS2: I had some ideas, what I realized was that when I was trying to
put them on paper, some ideas went into collision with others, so I
think is better to put them together in different e mail (not in a
whole interface (a bit daunting) and only afterwards try to make
something coherent out of it.
PS3: Subjectively to me it I have the sensation that from the
original prototype made by Andy and Mitch (together with other
valuable people) we might be sticking with some UI designs/metaphors,
which now might not be the best implementations for Chandler.
I know there has been put an awful lot of work into it coding the
actual interface of Chandler, but not being part of OSAF makes it
easier to start with a blank sheet of paper (only in part), with all
the background research you have already conducted and done.
I am starting to see how difficult is to make the right decisions,
since they take time to implement, and one might not have the truth
about it.
It would be great, from a UI Designer stand point of view, if one
could rapidly prototype different implementations of the UI of
Chandler so as to give them a try, so as to either adopt or discard
ideas quickly.
Yours as always,
Daniel Vareika
Mimi Yin wrote:
Daniel,
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
http://wiki.osafoundation.org/bin/view/Projects/AdhocCollectionsWorkflow
http://wiki.osafoundation.org/bin/view/Projects/SummaryTableViewSpec#ClustersStoryboard
I still need to write up a coherent proposal for Project Clusters,
but here are some incoherent design notes.
http://wiki.osafoundation.org/bin/view/Journal/ProjectsNotTasks
http://wiki.osafoundation.org/bin/view/Journal/QuickItemEntry
========
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.
Our notion of Clusters are based on PARC's Taskmaster project and
their idea of Thrasks. http://www.chi2003.org/docs/takingemail.pdf
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
http://lists.osafoundation.org/mailman/listinfo/design
