Wow, I think we're closing in...more in-line, but hopefully less
material :o) Thx for your patience Bryan.
On Feb 14, 2007, at 1:16 PM, Bryan Stearns wrote:
Hi Mimi,
Normally, this same "button" triage status is used for sorting in
the dashboard; however, because we occasionally want to pin an
item in place when changing its button color, or move an item to
a sort position other than what its button triage status would
call for (see specifics below), a secondary "section" triage
status overrides the button triage status if it's present. All
items have button triageStatus (and triageStatusChanged); section
triageStatus and sectionTriageStatusChanged are optional.
What do we use sectionTriageStatusChanged for?
In the same way that sectionTriageStatus overrides (button)
triageStatus if sectionTriageStatus exists,
sectionTriageStatusChanged overrides triageStatusChanged.
So when you Purge, all the items that are marked as NOW will have
their triageStatusChanged overwritten by the
sectionTriageStatusChanged...which means they will all have the same
change time. That seems fine.
So: Imagine that a one-time event for a meeting yesterday afternoon
at 2PM got set to NOW at that time; its triageStatusChanged is 2/13
2PM. Since then, though, other items have popped up at the top of
your NOW section, so that meeting is now the third item down, below
two other NOW items, of course; this is because its
triageStatusChanged is earlier than the triageStatusChanged of
those other two items.
You click the meeting's triage widget, which we know is supposed to
change the button triage status to NONE - however, it's also not
supposed to move until you purge. So, the click handler copies its
buttonTriageStatus *and its buttonTriageStatusChanged* to its
sectionTriageStatus and sectionTriageStatusChanged,
respectively ... which means that, since the section stuff
overrides the button stuff, the item won't move if we then change
the button stuff --
Ah ic. So the NOW button stuff is copied over the section stuff...so
that you can change the button status without affecting the placement
of the item in the view.
which we then do: we set the button triageStatus to DONE, and
buttonTriageStatusChanged to the current time, because after
purging, we'll want this item to appear at the top of the DONE
section, because we know items are sub-sorted by how recently their
triage status was changed. (If you now mark other items in the NOW
section as DONE, they'll appear *above* this meeting in DONE after
you purge, because you changed their triage status more recently
than that meeting's.)
Yup.
Purging simply drops any sectionTriageStatus &
sectionTriageStatusChanged attrs on any (unread!) item that has
them: that causes the item to be repositioned using its button
triageStatus & button triageStatusChanged values.
Yup. (What about Davor's suggestion that we never Purge Unread items
out of the NOW section? rather than warning users with a pop-up?)
If that item were already NOW, simply changing its button
triageStatusChanged time to the current time causes it to move to
the top of the section.
Does that mean that if I have an item thats buttonTriageStatus is
NOW and sectionTriageStatus is NOW and I click on it 3 times and
make its buttonTriageStatus NOW again, it will automatically jump
to the top of the NOW section when I finish doing that? Or is this
just for tickling.
Yes.
Hmm, I think in that case the user made a mistake (clicked on the
wrong item) and/or changed their mind mid-workflow.
We can certainly punt this to Preview, but we should log it and keep
track of it in bugzilla for Future.
The reverse of this also works: if we want to change the button
color (say, from NOW to DONE) without moving the item from its
current sort position, we copy button triageStatus to
sectionTriageStatus, and button triageStatusChanged to
sectionTriageStatusChanged, before changing the button color.
What is the item's starting sectionTriageStatus value? Is it in
the NOW section? If the item was in the LATER section then you
*wouldn't* copy over the buttonTriageStatus and
sectionTriageStatus, correct?
An item doesn't have sectionTriageStatus or
sectionTriageStatusChanged unless we're trying to do something
different about its position in the list (either move it to the top
without changing the button color, or keep it in place while we
change the button color).
Ok
If an item doesn't have sectionTriageStatus, then button
triageStatus & button triageStatusChanged are used for ordering (as
well as button color, of course).
Ic
So, new items - I think you wanted this: all new items appear at
the top of NOW - normally, that means button triageStatus = NOW and
button triageStatusChanged = creation time. Events that are created
with a time (say, by clicking on the calendar) are supposed to have
their button triageStatus set based on that time: if it's last
Tuesday, button triageStatus should be DONE -- however, I think you
still wanted the new event to appear at the top of the NOW section
until purging, so sectionTriageStatus will be set to NOW to
override the button triageStatus until purging.
Yes
(I know that's a slightly weird case: you'd have to have clicked on
the calendar to create that event, then switched to the dashboard
to see it. However, all the same rules apply for a last-Tuesday
event email that arrives: it shows up at the top of NOW, with a
DONE button color.)
Yup, Great.
Purging: a "Triage" button on the toolbar scans all the
non-"unread" items in the displayed collection:
sectionTriageStatus (on any items that have it) is discarded,
causing those items to re-sort to the positions determined by the
button triage status. (This would cause those items to be
reordered in other collections as well, since none of the triage
status attributes are per-collection.)
Will the sort order of the NOW section be calculated in terms of
buttonTriageStatusChanged or sectionTriageStatusChanged?
If sectionTriageStatus exists, it and sectionTriageStatusChanged
will be used for ordering; button triageStatusChanged will be
ignored. (The examples above should make clearer why that is: we
need button triageStatusChanged to be ignored so we can pre-set it
to the right value that we'll want used after purging.)
Okay, I think I understand this.
(Note that items newly stamped as events are "anytime today", and
will thus be NOW.)
Otherwise, if the item has an alarm time in the future
LATER
Shouldn't alarm date override the event date if the alarm date is
in the future?
OK - I've changed the spec to read:
* Changing the user alarm time on an item, or the event start or
end time on an event, or stamping an item as an event
* If it's an event:
* LATER if the start date is in the future *or* if there's
an alarm in the future
* else DONE if the end date is in the past
* else NOW otherwise.
* (Note that items newly stamped as events are "anytime
today", and will thus be NOW.)
* Otherwise, if the item has an alarm time in the future
* LATER
* Otherwise, the triage status is left alone.
Sorry to keep nit-picking on this phrase. I'm not sure the above
captures all the scenarios. Here's another pass at it. Should we be
clear in the language that this is all trigger off the user doing
explicitly changing dates and times? as opposed to time passing.
* If it's an event:
* NOW if the start date is moved to now, or the start date
is before now and the end date is after now *or* if an alarm is set
to now
* else LATER if the start date is moved to the future *or*
if an alarm is set to the future
* else DONE if the end date is moved to the past
* (Note that items newly stamped as events are "anytime
today", and will thus be NOW.)
* Otherwise, the triage status is left alone.
+ I have an event in the past with an alarm for Next Monday:
buttonTriageStatus = LATER
+ I have an event in the future, but the alarm has past:
buttonTriageStatus = NOW
+ I have an event in the past, and the alarm is in the past:
buttonTriageStatus = DONE
+ I have an event in the future with an alarm for right now:
buttonTriageStatus = NOW
Seems like we need to figure out the next important date? And work
fro there?
Note that autotriage does *not* use the same "Important Date" that
we talk about for the Date column: The Date column needs to
consider dates in the past other than start and alarm, but I'm
pretty sure you'd never want a date other than start or alarm to be
used for determining NOW, LATER, or DONE.
Yes, except in the case of the end-date being in the past to
determine DONE.
Otherwise, the triage status is left alone.
Automatic operations affecting triage status:
When a user reminder goes off, or when an event's start time is
reached.
The item's triage status gets set to NOW, and the item moves to
(near) the top of the NOW section. (Its position is actually
determined by the reminder or event start time that caused the
move -- items will appear in reverse order that their alarms went
off or times were reached. This is true even if Chandler wasn't
running at the appointed times: the automatic operations will
produce results in the right order when Chandler is restarted.)
? reverse order? As in the later alarms will appear closer to the
top?
Yes. (Our date encoding gives later dates a higher numeric value
than earlier ones... and we're supposed to sort by how recently
triage status was changed. That's essentially reverse order,
*internally* - sorry if mentioning that was confusing).
Nope, makes sense to me.
I think this is what you want, though: whether Chandler is running
or not, your item with a Monday alarm will pop into Now before your
item with a Tuesday alarm, so Tuesday's will appear higher in the
list. (If it doesn't confuse the issue: recall that we're sub-
sorting each triage status by the triageStatusChanged time: Your
Monday-alarmed item's triageStatusChanged time is the time it
popped to the top of NOW (Monday), and Tuesday's popped on Tuesday
(so that's what its triageStatusChanged is) -- Tuesday's appears
higher in the list, so as you said: later alarms will appear closer
to the top.
Yes, great.
When items are newly received or updated via sharing or mail, if
this user's "Share triage status" choice is off in all
collections this item belongs to:
(These changes only affect item sort order, not button color, and
only if the item didn't already have a pending section triage
status change pinning it in place: the button color doesn't
change. When the next "Triage" purge happens, the item will move
back to the position determined by its original triage status)
? Does this change the buttonTriageStatusChanged time? so if an
item was button=NOW, section=NOW, but at the bottom of NOW section
and then the item is Updated, the item will move to the top of the
NOW section and stay there event after the user clicks 'Triage' to
purge.
Your first question asks "In a situation where an update to an
existing item is received, and it's not a share where we're sharing
triage status, does buttonTriageStatus change?" - that answer is No
- I got that from the "N" in the "Assign Now Color?" column in
your spec's tables. There's a "Y" in the "Move to NOW Section?"
column, which is why I said (just below that) that the item is
moved to the top of the NOW section *if it didn't already have a
pending sectionTriageStatus that was pinning it in place* (because
we didn't want to move items around if the user was already
interacting with them - was "willy nilly" your term?).
Ah yes, I found the willy-nilly phrase, I think I meant it in a
different context. If I sync with the server and pull down changes
from you and there are changes to items that have 'pending
sectionTriageStatus', then your changes should only affect my
buttonTriageStatus, not my sectionTriageStatus. I think the way you
have it set up makes this happen for free? so this paragraph is
largely redundant from an implementation standpoint. I just wanted to
call it out as a behavior we should check was working correctly.
However, Updates and Errors *should* override any pre-existing
pending sectionTriageStatus to move items to the top of the NOW
section. And once they are there, their buttonTriageStatusChanged
should be reset so that when the user clicks 'Triage' to purge, the
item is 'put back into place' as if it was just recently triaged.
Sorry, that's not very clear. It basically means that if an item was
button=NOW and became section=NOW as a result of an Update or Error,
then when the user purges, the item stays at the top of the NOW
section. Similarly if an item is button=DONE and section=NOW as a
result of an Update or Error, then when the user purges, the item
gets 'purged' to the top of the DONE section.
If it was moved to NOW by setting sectionTriageStatus while
preserving its button triageStatus in this way, then purging would
pop it back to its original location.
I think we want to 'pop it back' to the section that matches the
button triage status, but as a freshly, just triaged item. (As per
above.) My best guess is that, that is how users will remember the item.
(I wouldn't be surprised if this isn't what you intended, so please
clarify the goal - this is why I wanted to invert the descriptions
in the spec: when you order by the results, different related
effects from the same action are described in different places in
the spec!)
Yes, I can see how that's confusing. It's hard for me to come up with
the rules governing the behavior, but it's easy for me to know how it
is I want it to behave :o) So thank you for writing this up!
Additionally, the item will move to the top of the NOW section
(unless it already has a pending section triage status pinning it
in place).
When an error occurs syncing an item
The item is moved to the top of the NOW section, without changing
its button color. This occurs even if automatic changes were
disabled on the item, but only if the item didn't already have a
pending section triage status change pinning it in place.
Not sure I understand the last part of the sentence. As in, An
item is button=LATER, section=DONE. An error is detected on the
item, the item *doesn't* get moved to the top of the NOW section
with it's button=LATER intact? I think we *do* want it to move.
I thought we might, but your spec didn't say anything about that.
I've updated my page to reflect that: it now says: "The item is
moved to the top of the NOW section, without changing its button
color. This occurs even if automatic changes were disabled on the
item, and also even if the item had a pending sectionTriageStatus
pinning it in place (because we really want the user's attention on
the error item)."
Great.
[Note: also, the important date spec isn't clear - it should be
this:]
The Date Column
[...] The date column displays the "important date" for an item:
if the item is an event and has both alarm and start time in the
future, it's the earlier of those times.
Yup.
Otherwise, if it has one or the other of those, it's that.
Otherwise, if it has one or the other of those dates in the
future, it's that.
Otherwise, if it's an event that has a start time (in the past),
it's that.
Otherwise, if it's an event that has both alarm and start time in
the past, it's the latest of those times.
Otherwise, if it has one of those two dates and it's in the past,
it's that.
Otherwise, if it's a sent or received email, it's the sent/
received time.
Otherwise, if another kind-specific date is provided, it's that
(Flickr photo-taken time, RSS posting time)
Otherwise, it's the last-modified time for the item.
Otherwise, it's the date the item was created.
Yup
OK, I've updated my spec to include alarms in the past (though I
don't think that's too useful...):
* if the item is an event and has both alarm and start time in
the future, it's the earlier of those times.
* Otherwise, if it has one or the other of those in the future,
it's that.
* Otherwise, if the item is an event and has both alarm and
start time in the past, it's the later of those times.
* Otherwise, if it has one or the other of those in the past,
it's that.
* Otherwise, if it's a sent or received email, it's the sent/
received time.
* Otherwise, if another kind-specific date is provided, it's
that (Flickr photo-taken time, RSS posting time)
* Otherwise, it's the last-modified time for the item.
* Otherwise, it's the date the item was created.
Great.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
