=?big5?B?UmWhRyBbRGVzaWduXSBSZTogVHJpYWdlIFNvcnQ=?=

[Andrew Tong]

I was exactly suggesting a possible approach to mixing drag&drop ordering w=
ith date ordering. Do you mean it's technically difficult or do you see fla=
ws or otherwise disagree with the logic. Please comment.=0A=0AElsewhere peo=
ple have been discussion auto-change triage status to "done" for past event=
s. I strongly disagree. I would prefer a bit of hassle over any false posit=
ives (past due date but not actually done). Besides, isn't click-changing a=
n item to "done" a rather satisfying experience?=0A=0AAndrew=0A=0A=0A----- =
=B6l=A5=F3=AD=EC=A5=F3 ----=0A=B1H=A5=F3=A4H=A1R Mimi Yin <mimi at osafoundati=
on.org>=0A=A6=AC=A5=F3=A4H Design Discussions <design at osafoundation.org>=0A=
=B0=C6=A5=BB(CC) Andrew Tong <amwt at yahoo.com>=0A=B6=C7=B0e=A4=E9=B4=C1=A1R =
2007 =A6~ 10=A4=EB 19 =A4=E9 =ACP=B4=C1=A4=AD =A4U=A4=C8 5:43:15=0A=A5D=C3D=
=A1G Re: [Design] Re: Triage Sort=0A=0AHi Andrew,=0A=0AI think what Bryan S=
tearns (who is keeper of all things Triage Table)  =0Awas saying is that it=
's very difficult to merge drag and drop,  =0Aexplicit ordering with a noti=
on of auto-sorting based on alarm  =0Adates / event start dates. Is that co=
rrect Bryan?=0A=0AI think the LATER section *needs* some form of auto-sorti=
ng based on  =0Aalarm dates / event dates because it grows over time to con=
tain too  =0Amany items for manual sorting.=0A=0AConversely, I think explic=
it ordering is *most* useful in the NOW  =0Asection, because theoretically,=
 this should be the smallest section,  =0Athe section users are most carefu=
lly monitoring.=0A=0AOR We *could* auto-sort the NOW section in the same wa=
y we're  =0Aproposing to sort the LATER section with the caveat that 'newly=
  =0Aarrived items' stay at the top until the user has read them and  =0Acl=
icked the Triage button in the toolbar. Does that make sense? My  =0Aconcer=
n is that if we move to an auto-sort paradigm in the NOW  =0Asection, new i=
tems that arrive in the NOW section will never catch  =0Ayour attention bec=
ause they get 'auto-sorted' down the list of NOW  =0Aitems.=0A=0AMimi=0A=0A=
On Oct 17, 2007, at 4:25 PM, Andrew Tong wrote:=0A=0A> In my view, the hidd=
en lost-toggled-date is unlikely to reflect the  =0A> user's true intention=
 for the priority of the task/event. Speaking  =0A> from experience of usin=
g Chandler day to day for the last few  =0A> months, the toggle date only r=
eflects when happen to run through a  =0A> bit of daily housekeeping in Cha=
ndler.=0A>=0A> I would also argue for a consistent treatment of items in th=
e Now  =0A> and Later sections. For some users, the now means today. For ot=
her  =0A> it's next few days plus what ever is due much later but should be=
  =0A> started shortly. Where the boundary line is drawn between Now and  =
=0A> Later is personal and arbitrary, which I see as an asset of Chandler.=
=0A>=0A> I had described the disadvantage of the current sort approach in  =
=0A> the bottom of this thread. I would like to attempt to describe an  =0A=
> 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 =
 =0A> date parameters.=0A>=0A> - Hidden date =3D visible date, for all even=
ts=0A>=0A> - Hidden date =3D visible date, for tasks with dates set explici=
tly=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, an=
d <  =0A> date of item above=0A>=0A> - Whenever date sort is requested, alw=
ays sort by hidden date=0A>=0A> - Items without explicitly set dates would =
have NO visible date, to  =0A> remind user that their positions reflect pri=
ority only, and can be  =0A> readily changed by drag and drop=0A>=0A> - If =
an item with explicitly set date is dragged from one triage  =0A> group to =
another, new triage statuses are assigned=0A>=0A> - If an item with explici=
tly set date is dragged among dateless  =0A> items, it's own date doesn't c=
hange but the adjacent hidden dates  =0A> for items without explicitly set =
dates are modified to accommodate  =0A> the user's intention=0A>=0A> - If i=
tems with explicitly set dates are dragged above or below  =0A> other items=
 also with explicitly set dates, prompt user with  =0A> confirmation dialog=
ue box with a suitable suggested new date=0A>=0A> Think of the hidden date =
field as the smart priority field. Unlike  =0A> other PIM apps which force =
users to make up numbers, this smart  =0A> field picks up the correct figur=
e either be copying from the  =0A> visible date or from user interaction.=
=0A>=0A> I'm beginning to consider how to make use of the concept of start =
 =0A> and end dates for tasks. Perhaps the start date is used by the  =0A> =
hidden date as an indication of priority, and the end date doesn't  =0A> ch=
ange since it reflects the calendar deadline. This needs to be  =0A> though=
t through more.=0A>=0A> Andrew=0A>=0A>=0A>=0A>=0A>=0A> Mimi 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 confusing to have=0A=
>> both explicit ordering in the LATER section alongside automatic=0A>> ord=
ering based on the Date column.=0A>>=0A>> So explicit ordering would only b=
e something you can do in the NOW=0A>> section, which would remain ordered =
by when items became NOW.=0A>>=0A>> Mimi=0A>>=0A>> On Oct 16, 2007, at 7:59=
 AM, Bryan Stearns wrote:=0A>>=0A>>> We currently sort by a value you can s=
ee (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 that the =
triage status color was=0A>>> last set").=0A>>>=0A>>> The intention behind =
this was always to support manual ordering by=0A>>> dragging items (it's bu=
g 6311*, by the way): if you dropped an item=0A>>> between a "now" that was=
 changed at 10AM yesterday, and one changed=0A>>> at 10:30AM yesterday, 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>>> Do=
ne sections (bug 8939*): the new requirements there complicate=0A>>> suppor=
t for manual dragging (you wanted nuanced? here it is: the=0A>>> old orderi=
ng only depended on what had happened to the item in the=0A>>> past, but th=
e new ordering requirement for the Later section=0A>>> depends on values th=
at 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 Later items. If =
the user expects the manual=0A>>> ordering to affect when the 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 or=
der in Later & Done is this bug:=0A>>>   https://bugzilla.osafoundation.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 cu=
rrent approach, and I suspect it can=0A>>>>> be used productively IF we fli=
p the trange status consciously=0A>>>>> with this in mind. However, I updat=
e triange status generally=0A>>>>> from top to bottom based on whatever the=
 current sort order=0A>>>>> happens to be. From other discussions, you woul=
d know that since=0A>>>>> the current sort order is unlikely to be ideal so=
 further=0A>>>>> flipping triange status is unlikely to result in any bette=
r=0A>>>>> order. e.g.:=0A>>>>>=0A>>>>>   super important event [today]    [=
later]=0A>>>>>   important event       [tomorrow] [later]=0A>>>> Yes, this =
is along the lines of how I've been thinking about=0A>>>> prioritizing item=
s in the LATER section as well.=0A>>>>>=0A>>>>> Reviewing the list, I chang=
e the first item to "now", followed by=0A>>>>> changing the second item to =
[now] also. Since event dates are=0A>>>>> ignored in the sort ordering, the=
 result:=0A>>>>>=0A>>>>>=0A>>>>>   important event       [tomorrowa] [now]=
=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 wo=
uld be=0A>>>>> ideal!=0A>>>> Yes! I've run into this a number of times as w=
ell for both the NOW=0A>>>> and LATER sections. My understanding is that ex=
plicit ordering is=0A>>>> that this is quite difficult. But Bryan Stearns w=
ould have a more=0A>>>> nuanced perspective.=0A>=0A>=0A>=0A>=0A>       Yaho=
o!=0A =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=B9 =0A> ht=
tp://hk.photos.yahoo.com =A4F=B8=D1=A7=F3=A6h!=0A>=0A>=0A> _ _ _ _ _ _ _ _ =
_ _ _ _ _ _ _ _ _ _=0A>=0A> Open Source Applications Foundation "Design" ma=
iling list=0A> http://lists.osafoundation.org/mailman/listinfo/design=0A=0A=
=0A=0A=0A=0A=0A      Yahoo! =A5=FE=B7s=A4=C9=AF=C5=BA=F4=A4W=AC=DB=C3=AF=A1=
A=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.yahoo.com =A4F=B8=D1=A7=F3=A6h!=0A=0A