Mimi Yin wrote:
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..
OK - I'm getting rid of all the "fine" stuff - the rest is below.
...Bryan
[...]
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?
I did discover a flaw in the spec: when I added the "*or* if an alarm is
set to the future" clause to the LATER case, I should've also added a
clause to the DONE case too: it really should be this:
* 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 *or if there's an
alarm in the past.*
* else NOW otherwise.
The troublesome part is that it's ridiculously hard to set an alarm for
"right now"; even if your timing is microsecond-perfect once, you'll
never be able to reproduce those conditions. We need to specify behavior
that's repeatably verifiable, so instead, I specify "in the future" or
"not in the future", so that it's possible to implement, and to come up
with tests that set alarms for a little bit in the future, or a little
bit in the past, to see if they behave the way we want.
(It's also confusing because our time references have sub-minute
resolution: Back to your examples in a moment, but imagine you have an
event at 11:00 AM. It's actually at 11:00:00.000 AM: eleven hours, zero
minutes, zero seconds, zero milliseconds. If you wait until the clock in
your toolbar says "11:00" (pretend it's digital, and not your fancypants
Macintosh shiny sweep-secondy dashboard widget :-) ), it's after the
event time, so you're setting an alarm in the past (and it'll never go
off). If you set it even a tiny bit in the future (that is, if you wait
until 58 sections after your clock reads 10:59, so you're pretty close
to the actual precise internal event time), you'll set up an alarm in
the future, and it'll fire normally without us having to have any
special cases for "now" in the auto-triage stuff. Those special cases
would essentially *never* matter in real life, since no one sets alarms
for "right now" unless they're testing, so why bother?)
OK, so back to your examples: they're both cases of changing an alarm on
an item, so the relevant part of the spec is the "Changing the user
alarm time on an item... " section, and we're dealing with events in
both cases, so we're in the right place -- the rule I just tweaked is
the one that'll be used.
Your first question asks "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?" --
Since we can't set an alarm for "right NOW", I'll be more specific: the
time you entered for the alarm is "11:00 AM", and you wait for the clock
to read "11:00" before you hit "enter" to commit the alarm time. If you
say you want an alarm at "11:00 AM", the time it's setting is
11:00:00.000 AM, but in the time it took your eyes to see that your
clock read "11:00" and got your muscles to hit the enter button, the
actual time moved past 11:00 exactly, to, say, 11:00:00.345 AM, which is
later than the alarm you just set. Therefore, you're setting an alarm in
the past, so the event will be marked DONE, just as if you'd waited
until 11:00 to set an alarm for 10:30 the same morning.
(I still think autotriaging based on expired alarms is wrong, which is
partly why I forgot to add that extra clause. If you agree, I can take
it back out.)
OK, so if I interpret your first question another way: the time you
entered for the alarm is still "11:00 AM", but you hit "enter" to apply
it after waiting for your clock to change to "10:59AM", then carefully
counting "1-mississippi, 2-mississippi" ... "56-mississippi,
57-mississippi, 58-mississippi, <enter>!" The "LATER if the start date
is in the future or if there's an alarm in the future" case applies: the
event's button triageStatus will be set to LATER, button
triageStatusChanged will be set to "11:00 AM", but it's sort order won't
change (because its previous button triageStatus and button
triageStatusChanged will be copied to sectionTriageStatus &
sectionTriageStatusChanged first).
Right away, though, probably imperceptibly later, the alarm will fire,
which triggers a different autotriage rule: the item will get its button
triageStatus set to NOW. (The code will also set button
triageStatusChanged to the alarm time, 11:00AM, but it already has that
value.) Because we don't move unpurged items willy-nilly, though, the
item won't move to the top of Now until the user purges...
(...Unless you tell me now that this is another case where we want to
override unpurged state, and toss sectionTriageStatus &
sectionTriageStatusChanged, so that the item *does* immediately pop to
the top of the Now section in this case. Note that this is distinct from
the similar case of an alarm firing on an event just after the user had
clicked on a triage widget: that case would never pop to the top when
the alarm fires because we turn off auto triaging when the user creates
an unpurged state by clicking on the widget, remember?)
The next question asked "[...] An event has a start-date in the future
and an Alarm is set to NOW, will the item get auto-triaged to LATER?" --
This also has two answers (whether your alarm is a teensy bit in the
past vs. a teensy bit in the future): If in the past, it'll work just
like the first case described above (DONE); if in the future, like the
second (LATER, but when the alarm immediately fires, it'll be set to NOW).
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
