[Chandler-dev] [Sum][Proposal] Triage Sort in the Re-architecture

After chatting briefly with both Jeffrey and Grant about what we can  
do to improve Triage Sort in the re-architecture, I thought it would  
be good to try and summarize what our options are on the list.

We've had numerous discussions about Triage Sort, on the design list,  
users list and in bugzilla. Before Jeffrey's more recent improvements  
to the LATER section: https://bugzilla.osafoundation.org/show_bug.cgi? 
id=8939, it was one of the most common user topics on the list.

There remains room for improvement, so I wanted to take this  
opportunity to summarize what users have requested and make a  
proposal for how we can address these requests, with the  
understanding that we will need to work on Triage Sort in phases to  
get things right.

For those with a short attention span, here is a summary of what's  
proposed below:

NOW
- Continue to sort NOW by triageStatusChanged (aka when an item  
becomes NOW)
- Allow NOW items to be manually re-ordered.

LATER
- Continue to sort LATER items that have custom-date tickler alarms  
and/or events to the top of the LATER section, leaving date-less  
Someday Maybe items at the bottom.
- Change the way Someday Maybe items are sorted by sorting on the  
"Edited on" date, aka the date that appears in the Date column.

DONE
- Sort the DONE section by whatever appears in the Date column:  
Custom-date tickler alarm, Event date, Edited on date.
- Fix the import code so that events are triaged to DONE "in the  
order in which they occurred."

*****
For background on what went into the proposal summarized above, keep  
reading...

So, what kind of feedback have we gotten on Triage Sort?

1. I want to be able to explicitly re-order items! This is  
particularly true of the NOW and LATER sections. Less so of the DONE  
section.

2. I want to see my calendar by when events occur in time.

3. I want to see the most recent stuff I've DONE.

4. I'm just plain confused about how items are sorted.

Clearly we can't satisfy all of these requests, as many of them are  
directly contradictory. However, I think we can address some of the  
most serious issues and leave the rest to user preferences ;)

#4 is particularly worrisome, so I'm going to start there. I think  
the root cause of the confusion is that the attribute that governs  
Triage sort order is invisible, namely - the moment in time an item  
was triaged into a particular triage section, or triageStatusChanged.

LATER and DONE
Bug 8939, which Jeffrey fixed, improved matters drastically for the  
LATER section because instead of the LATER section existing as a big  
jumble of items ordered by when they were triaged to LATER, items are  
now sorted first, by whether or not they have been "scheduled",  
either on the calendar as an event or with a tickler alarm,  
effectively turning the LATER section in a view of "what's coming up  
over the horizon".

As a result, "Someday Maybe" items (items that don't have a date  
assigned to them) automatically drop to the bottom of the pile.

However for a lot of people the list of "Someday Maybes" can be quite  
long. Currently, we still sort "Someday Maybe" items by the  
triageStatusChanged attribute, meaning the sort order of "Someday  
Maybes" is still based on an invisible attribute.

[Proposal] I think it would make more sense to sort "Someday Maybes"  
by when they were last edited, which is the date that appears in the  
Date column when there are not tickler alarm or event dates to display.

I think the same goes for the DONE section as well. It's extremely  
useful to see #3: "The stuff I've done most recently". However, the  
DONE pile hopefully grows to be really big for most users, so having  
some "tangible" way to predict how items are sorted would really help  
users find individual DONE items in the section.

Also, sorting items by when they were last changed will effectively  
mean that for the most part, recently DONE items will appear at the  
top of the section. [End of Proposal]

NOW
Notice that I've yet to say anything about the NOW section. This is  
because I still believe that the NOW section needs to be treated  
differently. For most users, the NOW section is smaller than LATER  
and DONE. LATER and DONE are largely "storage" areas for the vast  
majority of your data, most of which you may never touch again.

NOW on the other hand, is the center of the fish-eye lens. It's what  
people should be focused on. Every item matters in NOW.

So, whereas the LATER and DONE sections should be all about making it  
easy for users to get a high-level overview of what's coming up,  
what's been done and in some cases, scan and locate individual items,  
the NOW section should be all about giving people fine-grain control  
over every individual item.

What does that mean? First, I think it's important to continue to use  
the NOW section as a way to bring people's attention to "new" stuff  
or "new" old stuff, meaning items that have been tickled or scheduled  
on the calendar to return into focus at a later date.

[Proposal] This means that *by default*, the NOW section should  
continue to sort stuff by "when they become NOW" or triageStatusChanged.

However, I think we all agree that it's also important that users be  
allowed to manually re-order items in NOW. Bug 11775 Explicitly  
reorder items in NOW section. [End of Proposal]

(Users have requested the ability to manually re-order in the LATER  
section, but I have some concerns about that which I will save for a  
different email.)

SORTING BY EVENT DATE
The use case for this is pretty clear I think. It makes the most  
sense for collections that are purely calendar collections. However,  
sorting everything by event-date doesn't explain how non-events  
should be sorted in collections that are not "purely calendar" nor  
does it provide clear guidelines for how events should be sorted if  
they have a custom-date tickler alarm as well. (Aside you can ignore  
for now: Perhaps event items that have tickler alarms should actually  
show up twice in the list.)

I think the best way to address this use case is to provide user  
preferences for changing the Date column to always display the event  
date, even if there is a custom-date tickler alarm set on the event,  
which would allow users to sort by Event Date if they wanted to see  
their Calendar in a list view.

Also, one place where "not sorting the Triage List by event date" is  
most jarring is when users first import a calendar. The DONE section  
in particular appears to be a jumble of nonsense because the events  
are "triaged to DONE" arbitrarily, rather than "in the order in which  
they occured". I think if we can change, users will be less confused  
right off the bat.

[Proposal] Bug 9065 Make DONE section triage status sort order more  
comprehensible for imports and subscribes

IN SUM
I think I've addressed the key user issues with regard to triage  
sort. I imagine that this will be a continuous process of  
experimentation and refinement.

Just to be clear, what I am proposing here is the "ideal" case for  
"desired behavior". I expect that we will have a fair amount of back  
and forth to figure out how best to phase this work so that in phase  
1, we get the "most usable" triage sort behavior possible.

Okay, that's it for now.

Mimi

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev