[Design] What does Chandler mean to me? +
mimi at osafoundation.org
Fri Sep 30 13:24:16 PDT 2005
Daniel, first of all I want to thank you for reading over the
material so carefully. I absolutely agree that there are many ways to
solve a problem and the wiki pages I posted last time were simply
some ideas to help illustrate the data modeling issues we were
Your design ideas provide rich fodder for more discussion but first,
I want to address this issue of complexity or it's converse:
simplicity in design and my personal take on how to evaluate the
complexity of Chandler's design.
I am putting together some thoughts on your sketches in a separate mail.
On Sep 30, 2005, at 5:59 AM, Daniel Vareika wrote:
> 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
> 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
> 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
> Trash -> The same as Junk
> * This small, subjective analysis was made for Thunderbird not for
> Deleting vrs Removing (for me sounds the same)
> Delete vrs Hide (is it more whats up to?)
> 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
> 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:
>> 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
>> 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.
>> *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
>> **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
>>> 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
>>> <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.
>>> As you see the reference filling cabinet is within reach but far
>>> away from the "to do workspace"
>>> 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>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>> Open Source Applications Foundation "Design" mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Design