[Design] [chandler-users] Re: Triage Sort

[Andrew Tong]

In my view, the hidden lost-toggled-date is unlikely to reflect the user's =
true intention for the priority of the task/event. Speaking from experience=
 of using Chandler day to day for the last few months, the toggle date only=
 reflects when happen to run through a bit of daily housekeeping in Chandle=
r.=0A=0AI would also argue for a consistent treatment of items in the Now a=
nd Later sections. For some users, the now means today. For other it's next=
 few days plus what ever is due much later but should be started shortly. W=
here the boundary line is drawn between Now and Later is personal and arbit=
rary, which I see as an asset of Chandler.=0A=0AI had described the disadva=
ntage of the current sort approach in the bottom of this thread. I would li=
ke to attempt to describe an alternative I have in mind:=0A=0A- Same system=
 for both Now and Later=0A=0A- Visible dates are dates of events and tasks =
with explicitly set date parameters.=0A=0A- Hidden date =3D visible date, f=
or all events=0A=0A- Hidden date =3D visible date, for tasks with dates set=
 explicitly=0A=0A- Hidden date =3D date of entry, for tasks without dates, =
until...=0A=0A- ...dragged by user, then hidden date > date of item below, =
and < date of item above=0A=0A- Whenever date sort is requested, always sor=
t by hidden date=0A=0A- Items without explicitly set dates would have NO vi=
sible date, to remind user that their positions reflect priority only, and =
can be readily changed by drag and drop=0A=0A- If an item with explicitly s=
et date is dragged from one triage group to another, new triage statuses ar=
e assigned=0A=0A- If an item with explicitly set date is dragged among date=
less items, it's own date doesn't change but the adjacent hidden dates for =
items without explicitly set dates are modified to accommodate the user's i=
ntention=0A=0A- If items with explicitly set dates are dragged above or bel=
ow other items also with explicitly set dates, prompt user with confirmatio=
n dialogue box with a suitable suggested new date=0A=0AThink of the hidden =
date field as the smart priority field. Unlike other PIM apps which force u=
sers to make up numbers, this smart field picks up the correct figure eithe=
r be copying from the visible date or from user interaction.=0A=0AI'm begin=
ning to consider how to make use of the concept of start and end dates for =
tasks. Perhaps the start date is used by the hidden date as an indication o=
f priority, and the end date doesn't change since it reflects the calendar =
deadline. This needs to be thought through more.=0A=0AAndrew=0A=0A=0A=0A=0A=
=0AMimi Yin wrote:=0A>Moving this discussion over to the Design List.=0A>=
=0A>Hi Bryan,=0A>=0A>Thinking about it more, I agree that it would be confu=
sing to have  =0A>both explicit ordering in the LATER section alongside aut=
omatic  =0A>ordering based on the Date column.=0A>=0A>So explicit ordering =
would only be something you can do in the NOW  =0A>section, which would rem=
ain ordered by when items became NOW.=0A>=0A>Mimi=0A>=0A>On Oct 16, 2007, a=
t 7:59 AM, Bryan Stearns wrote:=0A>=0A>> We currently sort by a value you c=
an see (the triage status color:  =0A>> now or later or done) as well as a =
value you can't (which, at the  =0A>> moment, is more or less "the time tha=
t the triage status color was  =0A>> last set").=0A>>=0A>> The intention be=
hind this was always to support manual ordering by  =0A>> dragging items (i=
t's bug 6311*, by the way): if you dropped an item  =0A>> between a "now" t=
hat was changed at 10AM yesterday, and one changed  =0A>> at 10:30AM yester=
day, we'd pretend the dropped item was changed at,  =0A>> say, 10:15AM.=0A>=
>=0A>> We currently have a task to change the sort order of the Later and  =
=0A>> Done sections (bug 8939*): the new requirements there complicate  =0A=
>> support for manual dragging (you wanted nuanced? here it is: the  =0A>> =
old ordering only depended on what had happened to the item in the  =0A>> p=
ast, but the new ordering requirement for the Later section  =0A>> depends =
on values that the user can change -- so if the user  =0A>> changes a date =
on an item in Later, it might or might not move  =0A>> relative to other La=
ter items. If the user expects the manual  =0A>> ordering to affect when th=
e item pops to Now, they'll be  =0A>> disappointed and/or confused.)=0A>>=
=0A>> ...Bryan=0A>>=0A>>=0A>> * Manual ordering is this bug:=0A>>   https:/=
/bugzilla.osafoundation.org/show_bug.cgi?id=3D6311=0A>>=0A>>   Changing the=
 sort order in Later & Done is this bug:=0A>>   https://bugzilla.osafoundat=
ion.org/show_bug.cgi?id=3D8939=0A>>=0A>>=0A>> Mimi Yin wrote:=0A>>> On Sep =
25, 2007, at 9:12 PM, Andrew Tong wrote:=0A>>>> I can see the logic of the =
current approach, and I suspect it can  =0A>>>> be used productively IF we =
flip the trange status consciously  =0A>>>> with this in mind. However, I u=
pdate triange status generally  =0A>>>> from top to bottom based on whateve=
r the current sort order  =0A>>>> happens to be. From other discussions, yo=
u would know that since  =0A>>>> the current sort order is unlikely to be i=
deal so further  =0A>>>> flipping triange status is unlikely to result in a=
ny better  =0A>>>> order. e.g.:=0A>>>>=0A>>>>   super important event [toda=
y]    [later]=0A>>>>   important event       [tomorrow] [later]=0A>>> Yes, =
this is along the lines of how I've been thinking about  =0A>>> prioritizin=
g items in the LATER section as well.=0A>>>>=0A>>>> Reviewing the list, I c=
hange the first item to "now", followed by  =0A>>>> changing the second ite=
m to [now] also. Since event dates are  =0A>>>> ignored in the sort orderin=
g, the result:=0A>>>>=0A>>>>=0A>>>>   important event       [tomorrowa] [no=
w]=0A>>>>=0A>>>>=0A>>>>   super important event [today]    [now]=0A>>>>=0A>=
>>> To overcome this, one would have to counter-intuitively flip the  =0A>>=
>> 2nd "tomorrow" item first, then you flip the more important item.=0A>>>>=
=0A>>>> Again, an additional drag-and-move free form sort order would be  =
=0A>>>> ideal!=0A>>> Yes! I've run into this a number of times as well for =
both the NOW  =0A>>> and LATER sections. My understanding is that explicit =
ordering is  =0A>>> that this is quite difficult. But Bryan Stearns would h=
ave a more  =0A>>> nuanced perspective.=0A=0A=0A=0A=0A      Yahoo! =A5=FE=
=B7s=A4=C9=AF=C5=BA=F4=A4W=AC=DB=C3=AF=A1A=C5=FD=A7A=A5=D1=AC=DB=A4=F9=A4=
=A4=A4=C0=A8=C9=A5=CD=AC=A1=C2I=BAw=A1A=BD=D0=ABe=A9=B9http://hk.photos.yah=
oo.com =A4F=B8=D1=A7=F3=A6h!=0A=0A