Mimi:
To this e mail I will answer you between lines.
Thanks,
Daniel
I like the overall
structure of design sketches you put forth. I
have a personal bias in favor of what I call "push-button" UIs,
where
the user is given a few levers with which to control what they see or
don't see in the UI. This can apply to both the data you see (by using
Filter buttons) and/or chrome elements (ie. Apple does this with iCal
with buttons for Mini-cal, Detail view, List view, Task list)
Sorry Mimi, although I have looked it up on the dictionary, I am not
completely sure what you mean by "personal bias" if its either positive
or negative and in what extent.
I would appreciate you clarify me on that matter.
This is as opposed to
relying on the user to formulate their own
filters either in the Search box or by defining their own rule-based
search folder (ie. Smart playlists, Outlook search folders.)
The one thing to
clarify though is that all Collections in
Chandler are in effect Filters. Because of bi-directionality, a
collection is simply an attribute on the items that are members of that
collection.
Now I understand it as a consequence of reading "Complex in what way"
(Sidebar collections
are also handy as filters because they both
filter the view and are also office drop targets as a way to assign the
filter value to items.)
So if the user creates
a collection called Home or Work or
Soccer, just by creating and naming the collection, they've created
filters for Home, Work and Soccer.
The default attribute
name for such collections will probably be
something like Tag. So items that are placed into Home, Work or Soccer
will automatically be Tagged as Home, Work or Soccer.
But users can also be
more specific about their collections.
This is not just some Tag collection, this is a Project=Home repairs
collection.
You can also think of
it as: Collections are single-attribute
rules. They are always defined as some attribute: attribute value pair
that is imprinted on all of their member items.
Understood.
I really like the idea of defining filters as a consequence, not to
have to think as an user how to define a filter so as to make it.
I agree on the fact that users rarely end up doing this.
The second issue is
whether or not David Allen projects should
be modeled as Items with clusters or as Collections in the sidebar.
I think you're idea to
have semantically meaningful schema (set
of attributes) for different kinds of collections is great. (ie.
Project: collections might have due dates, milestones (that show up on
the calendar) and Goals. Scrapbook Album: collections might have a
narrative area, year-range, etc)
>From this explanation I will put forward another email with a little
idea on the Scrapbook Album
However, I think we
may be using the word Project in different
ways. It seems like the type of project you're describing (and please
let me know if I'm completely off) is what we've been calling a capital
"P" project. One that relatively long term. Big. Might involve multiple
people. Chandler's 0.6 release might be such a project.
These definitely
belong in the sidebar.
The lower-case "p"
projects I was talking about last time are
often mistaken as tasks by a lot of people. In fact a lot of people
don't really keep task lists, they only bother to write down their
tasks at the lower-case "p" project-granularity.
"p"rojects don't last
very long. There are literally dozens and
dozens of them and people tend to think of them as items.
On this matter I have a bit of mixed feelings on the subject.
To DA GTD there are no things as lower case "p" projects and capital
"P" projects.
He says more or less that anything that takes more than one step is in
fact a project no matter the simplicity or how complicated it might be.
I think he just might be right.
That is why I made a distinction between work from home or work from
personal.
Maybe this way you wont mix "go to the vet for the dog and do..." with
Chandlers 0.6 release.
We all understand that they have different importance in the user but I
would say none is more important than the other, they might be more
important depending on the hat you are wearing.
So I believe a filter like personal/private to work is almost a must.
From our research on
the kinds of things people put in their
sidebar, I think it would be hard to convince people to use such a
heavyweight affordance to manage "p"rojects, which is primarily why we
want them to be able to start out with a task and then expand that task
to become a project with sub-tasks.
As you put in the paper "Complex in What Way?" I believe that task will
remain tasks. The thing is more like if you do it faster and more
efficient in which way.
It´s more about efficiency than complexity. Maybe what we need is only
a mind trigger.
The types of items
that people DO bother to put in their
sidebars are more long-term areas of responsibility (which maps nicely
to David Allen's areas of responsibility as well).
They tend to be things
that don't go away, but more or less
define the scope of your life. The rate at which they are born and die
is relatively low. (This is not to say there aren't significant
exceptions to this. But I think the heavyweight-ness of sidebar
collections shapes what kinds of things people use it for.)
Examples are things
like: HR issues, Travel, Amazon receipts,
OSAF, design list, bugs, status reports, etc...
This paragraphs were enlightening to me, because it described what I
did in the past with the sidebar and what should I have done.
What people use it most (the sidebar) is really for reference material
that for projects.
I will expand on this matter in another e mail, since I believe it
deserves it.
Yours,
Daniel Vareika
