[Design] [Proposal] Dashboard - Revisiting sorting by Triage Status

[Mimi Yin]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070509/cc9d712a/attachment.htm