Okay, I think there may only be 1 minor thing at the very bottom I
forgot to mention earlier...everything else seems fine...see comments
in-line..
On Feb 15, 2007, at 8:29 AM, 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.
Ah, ic, great.
(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...")
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.
Yes. Great.
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.
Well you can think of it as Undo, or you can think of it as an
exception where buttonTriageStatusChanged doesn't actually change if
the user cycles all the way to the original button status without
Purging in the middle.
(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.
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.
Okay, I'm wondering if the rules you had would work for the
following: An event has an end-date in the past and then sets an
Alarm to right NOW, will the item get auto-triaged to DONE? Or An
event has a start-date in the future and an Alarm is set to NOW, will
the item get auto-triaged to LATER?
I guess, mostly I'm worried about alarms getting set to NOW and auto-
triaging not working properly, but I'm guessing that the 'Tickling'
takes over to make things NOW at the appropriate time?
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.
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.
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.
Yes, that is correct. Move it to the top no matter what and mark the
Updated and Error item as Unread. (I don't think I said Error before,
apologies, that was an oversight by me.)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
