As I promised Bryan on IRC, I have attempted a more detailed write-up
of the proposal I alluded to in my [Last call] summary of the 'triage
list view - sorting' thread: http://lists.osafoundation.org/pipermail/
design/2007-May/007165.html
===
Dashboard DONE Section
Currently logged as: https://bugzilla.osafoundation.org/show_bug.cgi?
id=9065
When the Dashboard is sorted by Triage Status, sort the DONE section
by the Date that appears in the Date column. In other words, change
the way we order items in the DONE section when sorting by Triage
status.
Date column addendum:
+ In the Done section, always display the Event start date, if there
is one. Custom alarm dates don't override Event start dates in the
Done section.
**Please scroll down to the bottom for the use cases driving this
proposal.
Note:
+ We will continue to use event start and end date/times *and* custom
alarm dates to figure out how to auto-triage items.
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.
2. If we decide this is a must-have for Dogfooding, is this doable
for Preview? (Assuming the proposal above is clear.)
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?
===
Dashboard LATER Section
The LATER Section will be sorted in the order that items will be auto-
triaged (aka Tickled) to the NOW Section. Items that have no tickler
dates, meaning neither custom alarm dates nor event dates are
considered 'Someday Maybe' items and are sorted to the bottom of the
LATER Section by whatever date appears in the Date column: dateSent,
dateLastModified, dateCreated.
The Date column in the LATER Section will continue to display the
next important date, which could be either a custom alarm date or an
even date, depending on which comes first. If there is neither date
on an item, than the Date column displays dateSent. If there is no
date sent, then the item displays dateLastModified.
https://bugzilla.osafoundation.org/show_bug.cgi?id=8939
===
Dashboard NOW Section
+ We will continue to sort in the way it sorts Today, that is, in the
order that items enter the NOW Section.
===
What's up with all the exceptions. Why can't all 3 Sections sort the
same way?
The behavior is quite variable across the 3 different Triage
Sections, but I think that's simply a reflection of just how
different the 3 sections are wrt 1) the user needs they satisfy...
NOW - What am I doing now? What new stuff is there to process?
LATER - What's coming up?
DONE - Archive of what I've done.
...2) their size and shape...
+ NOW - Relatively small, hopefully. High churn rate. The section
users are most likely to sit-in and focus on.
+ LATER - Mostly important stuff. Smaller than DONE, but likely to
grow to be much larger than NOW.
+ DONE - Large, lots of unimportant stuff inter-mingled with items
that represent large tasks and projects. Relatively static content.
Items don't really leave DONE, they just get added to DONE.
...and 3) OOTB and subsequent ramp-up experience
+ NOW is small to non-existent at first. Users need to manually build
it up.
+ LATER is relatively small. Users need to manually build it up.
+ DONE is huge as soon as users set up their Chandlers, import
existing calendars, subscribe to shared calendars.
===
Dependencies on other bugs: In order for any of the above scenarios
to play out correctly, we need to fix [Bug 9023] New items are not
displaying Date Created in the Date column: http://
bugzilla.osafoundation.org/show_bug.cgi?id=9023.
Mimi
===
**Use Cases driving the LATER Section Sort order Proposal : I
realized that by doing the above, we satisfy both Pieter's use cases
and my use cases.
As per Pieter's proposal, items will be sub-sorted in the DONE
section in a tangible way that the user can see. Items will also be
ordered in an 'Archival' manner, providing in some sense a history or
chronology of what you've DONE.
However, for the most part, items will also be ordered in the order
you triaged them to DONE because when you triage an item to DONE,
that action changes the dateLastModified. (So Pieter, you sort of do
have a timestamp for when an item was triaged to DONE.)
This basically satisfies my use cases around allowing users to see
what they've accomplished in the recent past. However, there will be
times when 'what you've accomplished in the recent past' won't line
up so neatly with sorting by the date that appears in the Date column:
+ Events that get triaged to DONE way after they happen;
+ Non-events with custom alarms that get triaged to DONE way after
the alarms fire
+ Messages with a date sent.
That is because according to this proposal, the 3 categories of items
listed above won't be sorted on dateLastModified. Instead, they will
be sorted on their event dates, custom alarm dates and dates sent
respectively, which may be drastically different from their
dateTriageToDone. But both Pieter and I agree that's okay because
users are more likely to remember events by event dates, tickled
items by custom alarm dates and messages by dates sent than they are
liable to remember such items by dateTriagedToDone. (Is that correct
Pieter?)
The use cases that suffer in this new paradigm are:
+ Oops, I didn't mean to Triage that item to DONE yet. Let me
retrieve it.
+ What did I accomplish Today?
+ I know I triaged it to DONE in the last hour...
But I now agree with Pieter that the DONE section as an Archive is
more important than the use cases listed above.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
