Bryan,

Since this is a bit more spec related, I thought I would answer. Some of this is detailed in the calendar spec for 0.5 although, we don't address all the fields that we would like to have for Kibble.

http://wiki.osafoundation.org/bin/view/Chandler/ ZeroPointFiveCalendarWorkflowsSpec

The reminder specifics will be addressed in the 0.6 requirements which exist as planning/design/workflow pages right now and will be evolving into specs over the next few weeks. I have been holding off on these discussions until after 0.5 feature freeze when the dev team has more bandwidth. As I mentioned in the apps meeting today, Mimi and I will be starting to present some of the 0.6 workflows starting next week.

Sheila

On Feb 8, 2005, at 9:26 AM, Bryan Stearns wrote:

Mimi,

Your elaboration is helpful, but I've still got questions about the specifics:

- What new fields does the user see in the detail view when they stamp a Note as a Task?

- What about when they stamp a Task or Event to become a Task-Event?

- What mechanisms are to be provided for specifying reminders on each? (Task, Event, Task+Event)

- After writing it, I got the feeling that you hadn't planned for a pop-up reminder mechanism, and that "reminders" only appear in the dashboard. Is this right?

...Bryan

Mimi Yin wrote:

Jeffrey asked some interesting questions about the user's mental mode of
Stamping in his struggle to make sense of the Chandler content model in
interoperable iCal terms.


The question of the day seems to be: what do we do with our Chandler
notion of Tasks that have been put on the Calendar. Or Task-Events for
short?

What is the semantic difference between a Task, a Task on the calendar and
a Task with a reminder date.


A task is a task. You see them on your taskpad.

A task on the calendar is a task that has been given a scheduled allotment
of time on your calendar. A task with a sense of promise and committment
so to speak.


A task with a reminder date is simply a task that will pop up in the "Now"
section of your Dashboard view (aka David Allen's Inbox) on a given date
at a given time (aka David Allen's tickler file).


Part of the theory is that "due dates" for tasks are hard for people to
set, mostly because discrete, finite tasks with absolute deadlines are
hard to define in the modern "free-flowing information" workplace. More
often than not, due dates are really "need to revisit this thing by next
week" kind of dates OR "will perform this task at this time" kind of
thing.


For example: if you have a task: Write master's thesis. The due date might
be May 5th, 2005. But you're going to want your PIM to ping you to work on
your thesis way before the due date. David Allen would call this a project
not a task. But given that many people conflate the notion of a project
with that of a task, assigning dates to tasks will need to accomodate both
bite-size tasks and project-size tasks.


Therefore, it might be more useful for you to set a reminder date on this
task to plop it into your "Inbox aka Now section" at the end of the week.


Or, if you're really serious about working on this thing, you might
actually block out time on your calendar to work on it every morning from
7-10AM.


Other tasks have appointment-like qualities (ie. Get haircut), but they're
more flexible than meetings and events that might happen whether or not
you show up. As a result, you really want to see these "appointments to
complete tasks" on a tasklist, so you can continue to keep track of them
in case you don't get around to going to the barber's as you had hoped.


See below for full discussion....

On Feb 7, 2005, at 5:35 PM, Mimi Yin wrote:


No, I think it should still add location, end time and
recurrence...the organizer attribute only comes with stamping the item
as an email.

The theory is, that once a user wants to schedule a task for a
specific time slot on their calendar (as oppose to just tickle it so
that it pops up in the Now sections of their Dashboard view at some later date)...it takes on a "promise" aspect that is similar to appointments....

Eventually we may want to locations for all tasks...but locations in
the David Allen sense of contexts: ie. @desk, @computer, @hardware store, @home, @phone

But it's still primarily a task and should appear on the user's task list.

Does that make sense?

Mimi

On Feb 7, 2005, at 5:25 PM, Jeffrey Harris wrote:


Hi Mimi,


I guess I'm not entirely sure I understand the question. From the
user's perspective, a Task that is not a Task-Event is simply a Task that the user doesn't want to see on their calendar.

That's a very helpful perspective. I'm not sure I understand the
ramifications of that. Does this mean that taking a Task and causing it to have Event-ness shouldn't necessarily add location, organizer, and end time attributes, because really it's just a Task that you'd like to have put on your calendar?

Sincerely,
Jeffrey




_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Reply via email to