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?
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.
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.
(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
