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
