Re: Re： [Design] Re: Triage Sort

Mon Nov 5 15:19:02 PST 2007

On Oct 19, 2007, at 10:25 AM, Andrew Tong wrote:

> I was exactly suggesting a possible approach to mixing drag&drop =20
> ordering with date ordering. Do you mean it's technically difficult =20=

> or do you see flaws or otherwise disagree with the logic. Please =20
> comment.
>

Technically difficult. Although Bryan will be able to respond this =20
better than I.

> Elsewhere people have been discussion auto-change triage status to =20
> "done" for past events. I strongly disagree. I would prefer a bit =20
> of hassle over any false positives (past due date but not actually =20
> done). Besides, isn't click-changing an item to "done" a rather =20
> satisfying experience?

I think we've now limited this to just be items that are only events =20
with duration and all-day events. (As in, not tasks.) Ultimately =20
though, I see this as something users could manipulate in a =20
Preferences panel.

>
> Andrew
>
>
> ----- =B6l=A5=F3=AD=EC=A5=F3 ----
> =B1H=A5=F3=A4H=A1R Mimi Yin <mimi at osafoundation.org>
> =A6=AC=A5=F3=A4H Design Discussions <design at osafoundation.org>
> =B0=C6=A5=BB(CC) Andrew Tong <amwt at yahoo.com>
> =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
> =A5D=C3D=A1G Re: [Design] Re: Triage Sort
>
> Hi Andrew,
>
> I think what Bryan Stearns (who is keeper of all things Triage Table)
> was saying is that it's very difficult to merge drag and drop,
> explicit ordering with a notion of auto-sorting based on alarm
> dates / event start dates. Is that correct Bryan?
>
> I think the LATER section *needs* some form of auto-sorting based on
> alarm dates / event dates because it grows over time to contain too
> many items for manual sorting.
>
> Conversely, I think explicit ordering is *most* useful in the NOW
> section, because theoretically, this should be the smallest section,
> the section users are most carefully monitoring.
>
> OR We *could* auto-sort the NOW section in the same way we're
> proposing to sort the LATER section with the caveat that 'newly
> arrived items' stay at the top until the user has read them and
> clicked the Triage button in the toolbar. Does that make sense? My
> concern is that if we move to an auto-sort paradigm in the NOW
> section, new items that arrive in the NOW section will never catch
> your attention because they get 'auto-sorted' down the list of NOW
> items.
>
> Mimi
>
> On Oct 17, 2007, at 4:25 PM, Andrew Tong wrote:
>
>> 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 Chandler.
>>
>> I would also argue for a consistent treatment of items in the Now
>> and 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. Where the boundary line is drawn between Now and
>> Later is personal and arbitrary, which I see as an asset of Chandler.
>>
>> I had described the disadvantage of the current sort approach in
>> the bottom of this thread. I would like to attempt to describe an
>> alternative I have in mind:
>>
>> - Same system for both Now and Later
>>
>> - Visible dates are dates of events and tasks with explicitly set
>> date parameters.
>>
>> - Hidden date =3D visible date, for all events
>>
>> - Hidden date =3D visible date, for tasks with dates set explicitly
>>
>> - Hidden date =3D date of entry, for tasks without dates, until...
>>
>> - ...dragged by user, then hidden date > date of item below, and <
>> date of item above
>>
>> - Whenever date sort is requested, always sort by hidden date
>>
>> - Items without explicitly set dates would have NO visible date, to
>> remind user that their positions reflect priority only, and can be
>> readily changed by drag and drop
>>
>> - If an item with explicitly set date is dragged from one triage
>> group to another, new triage statuses are assigned
>>
>> - If an item with explicitly set date is dragged among dateless
>> 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 intention
>>
>> - If items with explicitly set dates are dragged above or below
>> other items also with explicitly set dates, prompt user with
>> confirmation dialogue box with a suitable suggested new date
>>
>> Think of the hidden date field as the smart priority field. Unlike
>> other PIM apps which force users to make up numbers, this smart
>> field picks up the correct figure either be copying from the
>> visible date or from user interaction.
>>
>> I'm beginning 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 of priority, and the end date doesn't
>> change since it reflects the calendar deadline. This needs to be
>> thought through more.
>>
>> Andrew
>>
>>
>>
>>
>>
>> Mimi Yin wrote:
>>> Moving this discussion over to the Design List.
>>>
>>> Hi Bryan,
>>>
>>> Thinking about it more, I agree that it would be confusing to have
>>> both explicit ordering in the LATER section alongside automatic
>>> ordering based on the Date column.
>>>
>>> So explicit ordering would only be something you can do in the NOW
>>> section, which would remain ordered by when items became NOW.
>>>
>>> Mimi
>>>
>>> On Oct 16, 2007, at 7:59 AM, Bryan Stearns wrote:
>>>
>>>> We currently sort by a value you can see (the triage status color:
>>>> now or later or done) as well as a value you can't (which, at the
>>>> moment, is more or less "the time that the triage status color was
>>>> last set").
>>>>
>>>> The intention behind this was always to support manual ordering by
>>>> dragging items (it's bug 6311*, by the way): if you dropped an item
>>>> between a "now" that was changed at 10AM yesterday, and one changed
>>>> at 10:30AM yesterday, we'd pretend the dropped item was changed at,
>>>> say, 10:15AM.
>>>>
>>>> We currently have a task to change the sort order of the Later and
>>>> Done sections (bug 8939*): the new requirements there complicate
>>>> support for manual dragging (you wanted nuanced? here it is: the
>>>> old ordering only depended on what had happened to the item in the
>>>> past, but the new ordering requirement for the Later section
>>>> depends on values that the user can change -- so if the user
>>>> changes a date on an item in Later, it might or might not move
>>>> relative to other Later items. If the user expects the manual
>>>> ordering to affect when the item pops to Now, they'll be
>>>> disappointed and/or confused.)
>>>>
>>>> ...Bryan
>>>>
>>>>
>>>> * Manual ordering is this bug:
>>>>   https://bugzilla.osafoundation.org/show_bug.cgi?id=3D6311
>>>>
>>>>   Changing the sort order in Later & Done is this bug:
>>>>   https://bugzilla.osafoundation.org/show_bug.cgi?id=3D8939
>>>>
>>>>
>>>> Mimi Yin wrote:
>>>>> On Sep 25, 2007, at 9:12 PM, Andrew Tong wrote:
>>>>>> I can see the logic of the current approach, and I suspect it can
>>>>>> be used productively IF we flip the trange status consciously
>>>>>> with this in mind. However, I update triange status generally
>>>>>> from top to bottom based on whatever the current sort order
>>>>>> happens to be. =46rom other discussions, you would know that =
since
>>>>>> the current sort order is unlikely to be ideal so further
>>>>>> flipping triange status is unlikely to result in any better
>>>>>> order. e.g.:
>>>>>>
>>>>>>   super important event [today]    [later]
>>>>>>   important event       [tomorrow] [later]
>>>>> Yes, this is along the lines of how I've been thinking about
>>>>> prioritizing items in the LATER section as well.
>>>>>>
>>>>>> Reviewing the list, I change the first item to "now", followed by
>>>>>> changing the second item to [now] also. Since event dates are
>>>>>> ignored in the sort ordering, the result:
>>>>>>
>>>>>>
>>>>>>   important event       [tomorrowa] [now]
>>>>>>
>>>>>>
>>>>>>   super important event [today]    [now]
>>>>>>
>>>>>> To overcome this, one would have to counter-intuitively flip the
>>>>>> 2nd "tomorrow" item first, then you flip the more important item.
>>>>>>
>>>>>> Again, an additional drag-and-move free form sort order would be
>>>>>> ideal!
>>>>> Yes! I've run into this a number of times as well for both the NOW
>>>>> and LATER sections. My understanding is that explicit ordering is
>>>>> that this is quite difficult. But Bryan Stearns would have a more
>>>>> nuanced perspective.
>>
>>
>>
>>
>>       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=B9
>> http://hk.photos.yahoo.com =A4F=B8=D1=A7=F3=A6h!
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
>
>
>
>
>
>       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=B9=20=

> http://hk.photos.yahoo.com =A4F=B8=D1=A7=F3=A6h!
>
>