Okay, there are a couple of doozies in here...see in-line Mimi
On Feb 15, 2007, at 5:10 PM, Bryan Stearns wrote:
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.
Yup, I see that.
(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?)
Got it. So the only failure point is if you set it to 5:58PM and the
internal clock is at 5:58:58PM. And that will basically never happen.
Why would you do that anyway?
Ic, so basically you're checking for a future date. If there's a
future date, then its LATER. If there isn't one and there's a past
date, it's DONE. If there isn't even that, its NOW. Brilliant, okay I
finally get it.
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.)
So if you set an alarm to the past and there are no future dates? The
item would just stay whatever Triage status it was to begin with?
That's fine with me.
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...
Aack, I think this was another miscommunication. Can't believe we
didn't catch it until now. Tickling in my own Chandler should move
items willy-nilly. Just like Updates and Errors.
(...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.
Haha. You anticipated my reaction above. Yes the will-nilly comment
was ONLY intended for sharing and is discussed in the context of sync
in the spec.
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?)
Doh!? We turn off auto-triaging based on the user assigning and/or
changing date/time information on the item. We never turn off auto-
triaging based on time passing, aka tickling. So if I explicitly
triage something to LATER, I still want the item to pop-back into NOW
automatically when the alarm fires.
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).
Kewl.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
