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

[Grant Baillie]

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