Close to convergence! See below...
On May 9, 2007, at 5:02 PM, Bryan Stearns wrote:
This new proposal requires that triage status affect the
displayDate value (since moving an item to DONE could change the
displayDate), and also that triage status (the part that
determines the item's position in the DONE section) be updated
when the displayDate changes. That circular dependency is the
hard part to resolve, but if you don't care that items don't move
within DONE when their dates change, this isn't that hard;
however, performance test cases (especially import and sharing)
will definitely get worse either way, due to increased indexing
work.
So the scenario would be:
1. I triage an event item to DONE.
2. <The Date that is displayed in the Date column changes from a
Custom Alarm Date to the Event Start Date>; which in turn
3. <Places the item in a particular order in the DONE Section.>
4. I come along and change the Event Start Date to something even
further in the past; and
5. The item re-orders to appear lower down in the DONE Section.
I'm not sure where the cyclical part comes in. I see at the
abstract level, but when I go through a specific scenario, I can't
see it.
I think it would be a cycle if:
+ The part of triage status that determines an item's position in
a particular section affects the displayDate value; and conversely
+ The displayDate value affects the part of Triage Status that
determines an item's position in a particular section.
Instead, what we're saying is:
+ Whether or not an item is NOW, LATER or DONE affects the
displayDate value; and
+ The displayDate value affects the part of Triage Status that
determines an item's position in a particular section.
Is that accurate? Or I guess, what am I missing?
That's right, except that our notification mechanisms don't have
that granularity: the displayDate-updating notification will need
to fire if either triageStatus or triageStatusChanged changes, and
the triageStatusChanged-updating notification will need to fire if
any of the date-related attributes change (or maybe if the
displayDate changes - I'm not sure whether chaining the
notifications is a good idea).
Ahh ic. It's not that the values will change in an unending cycle,
but that there will be a lot of extraneous UI notifications firing.
I do think Pieter could solve his goals by just sorting on the Date
column (which is why I suggested it by saying "why not just sort by
the Date column as it is" ;-) )
Oh I wasn't sure if you mean Pieter-the-user could sort by the Date
column or that Chandler-the-app could sort the Triage status column
by the Date column which is one way to phrase Jeffrey's interim
proposal...Anyhoo...
Your point is well-taken and I am swayed by it. Just as a final
check...Pieter, does this satisfy your use cases? Would you be okay
with sorting on the Date column for now?
I would like to keep it a P4 - Basically, an interaction annoyance
that might confuse some users. We're planning on doing a final
evaluation of all the P3s and P4s just to make sure that we don't
have so many of them that the app as a whole feels unruly. But I now
see that it doesn't need to be a blocker.
(Important point that I hope shows that I have the best interests
of our users and the project at heart: I don't mean to discount the
usefulness of the feedback we got from Pieter, that the ordering in
the Done section isn't obvious [or even useful!] -- I'm just saying
that we already have a nearby feature that does the thing he wanted
to do, so this whole issue doesn't rise to the level of "blocking
dogfooding" for Preview. Postponing this would allow us to consider
the feedback with everything else we want to do post-Preview: how
we decide to do things like manual reordering and sectioning of
other columns affects how we choose to resolve this issue.)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
