Mimi Yin wrote:
Hi Bryan, Apologies for the split thread. At the first opportunity, I
will attempt to re-converge. For now, I think it's easier to reply
in-line and work out details...
On May 9, 2007, at 3:41 PM, Bryan Stearns wrote:
*QUESTIONS FOR BRYAN:*
*1. How does this map to, not map to the way things work today? *
The way I understand it, items are auto-triaged based by evaluating
1) event start and end date/times; and 2) custom alarm dates times
and then ordered in each Triage Section in the order that they were
auto-triaged into each section.
The proposal above would require us to change the way we order items
in each Section. We would order items based on the date that appears
in the Date column, *not* based on the order in which items are
auto-triaged into a particular section.
Autotriaging is triggered by a limited set of events (the item
arrives or is updated by import or sharing; the user changes
start/end times or alarm). The displayDate value (which is not just
displayed in the Date column, but also used to index it, and to
determine the icon displayed in the reminder column) is recalculated
completely whenever any of the dependent attributes change.
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).
*2. If we decide this is a must-have for Dogfooding, is this doable
for Preview? *(Assuming the proposal above is clear.)
It'll get prioritized with everything else, and I don't set those
priorities. It's probably "a week or less", but potentially much more
if anyone (hi, Heikki) files a blocking bug that things have gotten
slower when I check it in (that'll get prioritized too, of course).
Agreed, that doesn't seem worth it.
So you're saying we should punt this discussion to post-Preview? (great!
see below ;-) )
*3. What are some alternatives we should consider given the design
goals outlined in this email?* Namely: Make it easier for users to
hunt through the DONE section as an Archive by ordering items on
date values that are easy for people to remember (ie. Order event
items by event start date.)
I think at the very least, we need to address the import/subscribe
scenario. Items aren't pulled into Chandler chronologically, so the
ordering is especially confusing in these particular scenarios. *4.
Is it easier to address just the import/subscribe issue?
*
Why not just sort by the Date column as it is? Chances are, most of
your DONE items are gonna be grouped together at the bottom anyway
(and alarms in the past aren't used for the displayDate value anyway;
alarms in the future for events in the past are an ignorable edge case).
+ Are you saying that Pieter could solve most of his issues by just
sorting on the Date column; OR
+ Are you suggesting that we order items in the Triage Status column
by what appears in the Date column?
+ Could we do that just for the DONE and LATER sections and leave the
NOW section as it is?
+ If not, I think I'd prefer to keep ordering items by when they were
triaged to a particular section and try the solution where we
auto-triage items into their various sections in *chronological*
order...where chronological order is defined by the whatever value
appears in the Date column.
- If that proves to be not worth the effort as well, we can certainly
have users sort on the Date column, as you may or may not have
suggested above.
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" ;-) )
(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.)
(This has zero cost and zero risk, where your proposal also has the
risk of needing to be readdressed right away anyway.)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
