The goals for triage keep evolving... this is an attempt to summarize
things, and to figure out what's still to be done.
(Personally, I still believe that conflating personal triage state with
what others think the state is, while trying to use triage status to
announce newly-received items, is really confusing: Is it in the Now
section because I put it there, or because the boss who shared that item
with me wants me to work on it right away, or just because it's an item
that just got here, or because I tried to send it and my mail server
barfed? ... All that said, I'm just trying to understand what's being
requested so I can implement it.)
First, here's how things are right now:
- The user sees triage status in two ways: sectioning and sorting within
the table, and the color of the buttons displayed on each item's row in
the table and in the detail view of that item.
- Every item has a "section triage status"; it always determines the
sectioning and sorting within the table.
- Every item _can_ have an "unpurged triage status", which overrides the
section triage status when determining the color of both buttons. If no
unpurged triage status value is present, the section triage status is
used to determine the color. Clicking either button stores the "next"
color in "unpurged triage status" (even if no previous value existed for
it).
- Each of these two values has a corresponding last-changed timestamp,
which is used for ordering within each triage-status value (so two
items, both with section triage status = Now, will appear ordered by how
recently they became Now). To get the proper sort direction, this value
isn't a datetime - it's a *negated* count of seconds since the epoch in UTC.
- Sharing includes the section triage status and its timestamp only if
the sharer has chosen to "share triage status" in the Publish Collection
dialog. The unpurged triage status is never shared (currently), nor is
its timestamp.
- Purging occurs when the user clicks the "Triage" button in the
toolbar: each item in the displayed collection that has an unpurged
triage status attribute gets the unpurged triage status (and its
last-changed timestamp) copied over the section triage status, then both
unpurged triage status and its timestamp are removed from the item.
- When an item is created, its section triage status is set to Now and
its section triage last changed time is set to the current time.
- An internal reminder is maintained on events with start times in the
future: this reminder fires at an absolute time. When this happens, the
reminder firing mechanism sets the section triage status to Now and the
corresponding last-changed time to that absolute time.
- When a new item is received via sharing (and email?), and the share
isn't sharing triage status, we set its section triage status according
to its displayDate (that is, the value we'd display in the date column),
if it has one: displayDate in the past gets Done, otherwise Later. If we
do this, we set the section triage last-changed timestamp to that
displayDate value as well.
- In a recurring series (specifically, in the code in the recurrence
branch), every modification in a recurring series shows up in the
dashboard, and each modification has its own triage status and unpurged
triage status. Recurrence code goes and creates new modifications (and
deletes Done modifications) as appropriate based on the current date so
that at least one Done and one Later modification exists. (This bullet
point brought to you by Jeffrey :-) ).
OK, so, the future: Mimi's writeup here:
http://wiki.osafoundation.org/bin/view/Journal/WhosTriageStatusIsItAnyway
says:
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'.
(Neither triage status value is more "actual" or "real" than the other,
and both have color effects in the UI, so I'm sticking with the
"unpurged triage status" name I used above.)
It sounds like there are some conditions (error, update received) in
which we want to force the sort order, while leaving the button color
alone (which is slightly different from what we do now: this will
require preserving the old "section triage status" in "unpurged triage
status", thus creating an unpurged condition).
In other conditions (arrival of non-updates? I'm not sure what specific
cases, but they'd better be exclusive of the above conditions!), we want
to leave the sort order alone, but force the button color. This just
means setting "unpurged triage status", except that we probably
shouldn't if there's already a value there (since it's probably the
user's, though it might be left around from an earlier sync if the user
hasn't purged).
In both these cases, clicking Triage would cause the "unpurged triage
status" value to be copied over the "section triage status", then forgotten.
Mimi, does this sound like what you're asking for?
...Bryan
Philippe Bossut wrote:
Grant Baillie wrote:
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".
I'm not that sure. We now have 2 triage status: the focus status
(where it shows in the section) and its real status (its "color"
status). I understand that we do already have that with the new
"suspended triage" feature in the Dashboard but I'm not sure. So the
question is simply: Will a click on the "Triage" toolbar button just
clear up all these distinctions? I suppose it will (so that it will
be indeed "more of the same") but that's not what I'm reading in the
scenarios (or, at least, it's ambiguous).
We need stearns reading for sure...
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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 "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
