omg...I somehow ended up with a 2nd design list IMAP folder and all
my design list emails were getting shuttled into there for the past
week. I was wondering where all those emails I was sending out were
going. So apologies Bryan for not getting back to you right away.
This all looks great. There's only 1 point (see in-line comments)
about which triage status gets shared that wasn't clear to me...
Thanks for writing this up!
On Jan 18, 2007, at 2:39 PM, Bryan Stearns wrote:
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.)
For me, inconsistency isn't necessarily a bad thing for users. People
categorize things 'inconsistently' all the time. People mark messages
as Unread or Flag emails for myriad reasons that they mostly keep in
their heads. However, usually there is some underlying logic that
governs people's seemingly incoherent organizational systems.
In Chandler, things show up in the NOW section because they require
the users attention. Some of those things are placed into NOW by the
user themselves (either explicitly or automagically because of an
alarm or start-time rolling around). Other things are placed in their
by other people. This is how our Email Inboxes work. Sometimes I
email messages to myself. Most of the time, others email messages to
me. In all cases, email that goes into my Inbox is a way to focus my
attention on information.
This idea of 'focus' is what the 'section triage status' is useful
for. The 'real' or 'unpurged' triage status is the actual state of
the item itself. Is the Task actually DONE? Sometimes, these two
statuses are in sync. A Task is DONE and it's in the DONE section,
out of my focus area. Other times, the two statuses are not in sync.
A Task is DONE...but the person who did it wants me to see that its
done.
But this is neither here nor there, so let's get into the substance
of your write-up.
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.
Yes
- Every item has a "section triage status"; it always determines
the sectioning and sorting within the table.
Yes
- 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).
Yup
- 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.
Cool
- 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.
?? Shouldn't it be the reverse? The Section triage status isn't
shared, but the color or real triage status is. This allows 2 sharees
to see that a Task is DONE, but 1 sharee sees it in their NOW section
and another sees it in their DONE section.
- 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.
Yes
- 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.
Yes...except for events.
- 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.
Yes
- 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.
This is specific to events, correct? Non-event items would come in as
NOW if Triage status is not shared.
- 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 :-) ).
Yes, this could / should be it's own write-up :o)
OK, so, the future: Mimi's writeup here: http://
wiki.osafoundation.org/bin/view/Journal/WhosTriageStatusIsItAnyway
says:
So the proposal for Preview is to:
Use the 'Section Triage status' (which we already have today
Triage and Purge workflow) as the user's Focus status.
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.)
Sure.
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).
Yes, correct.
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).
Arrival of non-updates, meaning edits to existing items? Edits change
neither the unpurged triage status nor section triage status of an
item. In other words, when items are edited, they stay put. Newly
created non-event items in shares however, show up in NOW. This is
all assuming that triage status is NOT shared.
In both these cases, clicking Triage would cause the "unpurged
triage status" value to be copied over the "section triage status",
then forgotten.
Okay.
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
