[Design] What does Chandler mean to me? +

[Mimi Yin]

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  
discussing.

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.

http://wiki.osafoundation.org/bin/view/Journal/ 
ComplexityIsInTheEyeOfTheBeholder

I am putting together some thoughts on your sketches in a separate mail.

On Sep 30, 2005, at 5:59 AM, Daniel Vareika wrote:

> 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
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20050930/903869c3/attachment.htm