Hi Phillip,
Hi Philippe, My goal for this email was to set some context for
design values and approach. Even I'm not foolish enough to try and
revisit all of reasoning behind these complicated design issues in a
single message ;)
My understanding of the question was: Why use a complicated new
widget to do what everybody else uses a simple checkbox for? My reply
was that the functionality in Chandler isn't the same as the
functionality everybody else uses a simple checkbox for. So it's
possible our problem has more to do with providing better visual
feedback to more effectively communicate what's different about
Chandler overlays.
On Dec 10, 2007, at 7:12 PM, Phillip J. Eby wrote:
At 01:40 PM 12/10/2007 -0800, Mimi Yin wrote:
+ Overlays are called overlays and have special widgets because
they don't behave the same as checkbox, multi-selection.
That seems like a circular argument: they're different because
they're different. How is it *helpful* that they're different?
I think your write-up below highlights our dilemma. Chandler isn't
really trying to encourage / enforce a proscribed workflow: Review
stuff here, then process stuff over there. (In reality, people do all
the steps of the GTD workflow, all the time, at the same time.)
Instead, Chandler is more of a mindset or approach. I see our biggest
challenge as articulating what that mindset is to users in a way they
can understand at a gut-level. I have a feeling that it's not in any
of the ways we've tried to articulate it thus far.
It's like a doctor explaining a disease to a patient. The patient
understands it as the symptoms they feel. The doctor understands it
as the underlying causes of those symptoms. We've been trying to
pitch Chandler by describing our diagnosis, not by identifying the
symptoms.
(This is neither here nor there, but what the hay.) For the record, I
don't think of Collections and Triage as GTD terms. Again, I think
they're general, common English language words that pretty much
capture what the features are intended for.
Triage and Stamping are examples of ways in which I feel we've up-
ended existing models.
How so? I don't really see how stamping is especially different
from what, say, Outlook or Ecco can do.
Meanwhile, automatic assignment of triage status based on date
information is a nice feature, but it doesn't seem to up-end
anything compared to manually setting a status, or just sorting by
date with an option to exclude "done" items, or any of the other
ways that other tools have handled the problem.
Perhaps there's something I don't understand?
Sometimes it seems to me that Chandler is a difficult application
to understand because it's too timid to be an "opinionated"
application (one that tells you how to work), but too opinionated
to be a "tool" application (one that simply gives you a uniformly-
constructed model and expects you to shape it to your own opinions).
For example, calling it the "dashboard" instead of something like
"current work" or "for review", hides the opinion that this is
where your stuff is supposed to go. It's almost like the program
is ashamed of telling you what to do... but does it anyway. You
just have to understand the code words. :)
For an example in the other direction, look at Hank Williams'
comments, which are trying to drag the application to the "tool"
end of the spectrum, where the user is given a uniform model and
allowed to make their own decisions about how things should work.
I think either approach can work and be easy to learn *and* useful
for a chosen audience, but the middle ground doesn't appear to work
without a lot of hand-holding, explanations, and "huh?" moments.
I've been doing OSAF work for years and the application itself
still baffles me at times.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
