[Design] Who's Triage Status is it anyway?

[Mimi Yin]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070116/c27cfc78/attachment.html