Hi Mimi,
Thanks - inline again...
...Bryan
Mimi Yin wrote:
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.
No, that's not right: as you click each item to DONE, the click handler
copies its button triageStatus *and its button triageStatusChanged* to
its sectionTriageStatus and sectionTriageStatusChanged, respectively,
and then changes buttonTriageStatus to DONE and sets button
triageStatusChanged to the time you clicked each one. After you purge
(causing the sectionTriage and sectionTriageStatusChanged values to be
forgotten, allowing the updated button triageStatus and
buttonTriageStatus to take over), they'll be sorted in order of how
recently each was set to DONE, as the spec calls for.
(Also, since we're paying attention to details: when you purge, I think
the list conversation decided that only the *read* items would be
purged, right? So in your question, you're really asking "So when you
Purge, all the *read* items that are marked as NOW...")
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.
Yup.
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?)
It's in the spec (it says: "Purging: a "Triage" button on the toolbar
scans all the non-"unread" items in the displayed collection [...]"),
but in the line from my response that you quoted, I got it backwards,
oops: I should've said "Purging simply drops any sectionTriageStatus &
sectionTriageStatusChanged attrs on any (*read*!) item that has them:
[...]". The spec has it right, assuming you wanted to adopt Davor's
suggestion.
* 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.
If you're asking for Undo, this should be handled as part of the
long-put-off undo mechanism.
* 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.)
o 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.
No: my description is more accurate and more succinct, and reflects that
the decision isn't based on which attribute the user changed to trigger
this autotriaging. Give me an example where it's wrong, and what it
should have done, and I'll change it.
Also, I think the spec is pretty clear as I wrote it, that this section
applies when the user's doing something "explicitly" (changing a date or
time) that causes an "implicit" triage status change.
+ 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.
oops, right. (Right in my spec, wrong in my explanation - sorry.)
o 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.
o 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:
o (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.
OK, you're saying that we should override the user's temporary placement
(to the item's original location), with new temporary placement
resulting from the update (to the top of NOW). No problem: I've updated
the "update" and "error" sections of the spec to say that. However, you
also wanted the update to mark the updated item "unread," which means
that it won't be purged until the user has read it. Let me know if
that's not what you intended.
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.
Got it.
(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!
o 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
o 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
