Hi, Mimi
The proposed behaviour makes sense to me. I can't speak Mr Stearns,
but it looks to me as if this would be a case of "more of the same".
In Scenario 2, are you saying that events automatically have their
(colour) triage status changed to DONE once they're over?
--Grant
PS: I think you lost the end of a sentence before the '======' below.
On 16 Jan, 2007, at 13:22, Mimi Yin wrote:
This write-up is also on the wiki at: http://wiki.osafoundation.org/
bin/view/Journal/WhosTriageStatusIsItAnyway
Related bug: http://bugzilla.osafoundation.org/show_bug.cgi?id=7726
We've been struggling for a long, long, long time with not having a
robust way to reflect the differences between:
+ Focus status (e.g. Have I seen this item? Have I processed this
item? Have I put it away in the right places?); and
+ The actual status of an item.
This dilemma of course, usually presents itself when sketching out
Sharing use cases:
+ Ivan the Individual Contributor shares his persona task list with
Helen the Hub.
+ Ivan has been struggling with a Task for months. It's been
cycling between NOW and LATER with no end in sight. Ivan finally
finishes the Task and with an enormous sense of satisfaction, marks
the Task as D-O-N-E.
+ On such a momentous occasion, Ivan decides he must send out an
UPDATE about his accomplishment to Helen and clicks the Update
button in the Toolbar.
+ Helen 'receives' the Update and in her Chandler, Ivan's task
jumps to the top of the NOW section in the Dashboard view of Ivan's
personal task list collection.
+ IF we don't special-case Ivan's Update, the Task would be
automatically marked as Triage status = NOW, which would undermine
Ivan and confuse Helen.
+ I think what we actually want to happen is to keep the Triage
status = DONE and
======
However, there are equally pesky non-Sharing use cases as well:
Scenario 1: Error
+ Ivan finishes a Task and marks it DONE
+ Ivan wants to send an Update to an outside vendor that the Task
is DONE
+ There is an error sending the message
+ The Task jumps to the top of the NOW section and is marked as
Unread in hopes of flagging down Ivan's attention so that he can
address the Error.
+ Again, IF we don't special-case errors, the Task would be
automatically re-triaged to NOW, which would change the status of
the Task.
Scenario 2: Meeting over
+ Helen's weekly working group meeting jumps into the top of the
NOW section every week at the start of the meeting.
+ Once the meeting is over however, Helen would like the meeting to
be automatically marked DONE. However, she would like it to remain
in her NOW section, just in case she needs to write-up meeting
notes and/or send out follow-up emails about the meeting. [This use
case has come up a number of times.]
Scenario 3: Scheduling next week's meeting
+ Helen is trying to schedule a meeting. It's something she needs
to pin down right now. She enters a tentative date to get it on the
calendar. The date is some time next week, and the event is
accordingly auto-triaged LATER, but she doesn't want it to
disappear from her NOW section just yet.
===
So the proposal for Preview is to:
1. Use the 'Section Triage status' (which we already have today
Triage and Purge workflow) as the user's Focus status.
2. The 'Real' or 'Color Triage status' is the actual status of the
item.
Given this mental model, we can revisit our use cases above and say
that when Updates and Errors happen, items are moved to the top of
the NOW section and have a 'Section Triage status' = NOW, without
affect their 'Real' or 'Color Triage status'.
Similarly events that come and go can have their 'Real' or 'Color
Triage status' changed to DONE without disqualifying them from
remaining in the user's focus, or NOW section.
Events scheduled for the future can have their 'Real' or 'Color
Triage status' automatically set to LATER without disqualifying
them from remaining in the user's focus, or NOW section.
Only when the user clicks the Triage button does 'Section Triage
status' rationalize with 'Color Triage status'.
Questions:
1. Do the use cases sketched out here make sense?
2. Is this doable for Preview. I know Bryan Stearns hadn't started
the event-auto-triage functionality as of last week. Is adding the
behavior described above in Scenarios 2 and 3 adding a lot more
work to the event-auto-triage functionality? Or is it just more of
the same? I believe that we will already get Scenario 3 for free:
According to the spec, when users create new events in the
Dashboard and then changed date/time to some time in the future,
the item should be auto-triaged to LATER, but because of the Purge
workflow, it won't get filed into the LATER section until the user
hits Triage in the toolbar. It's really more a matter of adding
functionality to support auto-triaging past events to DONE.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
