[Design] Re: Triage Sort

[Mimi Yin]

Hi Andrew,

I think what Bryan Stearns (who is keeper of all things Triage Table) =20=

was saying is that it's very difficult to merge drag and drop, =20
explicit ordering with a notion of auto-sorting based on alarm =20
dates / event start dates. Is that correct Bryan?

I think the LATER section *needs* some form of auto-sorting based on =20
alarm dates / event dates because it grows over time to contain too =20
many items for manual sorting.

Conversely, I think explicit ordering is *most* useful in the NOW =20
section, because theoretically, this should be the smallest section, =20
the section users are most carefully monitoring.

OR We *could* auto-sort the NOW section in the same way we're =20
proposing to sort the LATER section with the caveat that 'newly =20
arrived items' stay at the top until the user has read them and =20
clicked the Triage button in the toolbar. Does that make sense? My =20
concern is that if we move to an auto-sort paradigm in the NOW =20
section, new items that arrive in the NOW section will never catch =20
your attention because they get 'auto-sorted' down the list of NOW =20
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 =20=

> user's true intention for the priority of the task/event. Speaking =20
> from experience of using Chandler day to day for the last few =20
> months, the toggle date only reflects when happen to run through a =20
> bit of daily housekeeping in Chandler.
>
> I would also argue for a consistent treatment of items in the Now =20
> and Later sections. For some users, the now means today. For other =20
> it's next few days plus what ever is due much later but should be =20
> started shortly. Where the boundary line is drawn between Now and =20
> Later is personal and arbitrary, which I see as an asset of Chandler.
>
> I had described the disadvantage of the current sort approach in =20
> the bottom of this thread. I would like to attempt to describe an =20
> alternative I have in mind:
>
> - Same system for both Now and Later
>
> - Visible dates are dates of events and tasks with explicitly set =20
> 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 < =20
> 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 =20=

> remind user that their positions reflect priority only, and can be =20
> readily changed by drag and drop
>
> - If an item with explicitly set date is dragged from one triage =20
> group to another, new triage statuses are assigned
>
> - If an item with explicitly set date is dragged among dateless =20
> items, it's own date doesn't change but the adjacent hidden dates =20
> for items without explicitly set dates are modified to accommodate =20
> the user's intention
>
> - If items with explicitly set dates are dragged above or below =20
> other items also with explicitly set dates, prompt user with =20
> confirmation dialogue box with a suitable suggested new date
>
> Think of the hidden date field as the smart priority field. Unlike =20
> other PIM apps which force users to make up numbers, this smart =20
> field picks up the correct figure either be copying from the =20
> visible date or from user interaction.
>
> I'm beginning to consider how to make use of the concept of start =20
> and end dates for tasks. Perhaps the start date is used by the =20
> hidden date as an indication of priority, and the end date doesn't =20
> change since it reflects the calendar deadline. This needs to be =20
> 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=20=

> 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