On Oct 19, 2007, at 10:25 AM, Andrew Tong wrote:
I was exactly suggesting a possible approach to mixing drag&drop
ordering with date ordering. Do you mean it's technically difficult
or do you see flaws or otherwise disagree with the logic. Please
comment.
Technically difficult. Although Bryan will be able to respond this
better than I.
Elsewhere people have been discussion auto-change triage status to
"done" for past events. I strongly disagree. I would prefer a bit
of hassle over any false positives (past due date but not actually
done). Besides, isn't click-changing an item to "done" a rather
satisfying experience?
I think we've now limited this to just be items that are only events
with duration and all-day events. (As in, not tasks.) Ultimately
though, I see this as something users could manipulate in a
Preferences panel.
Andrew
----- 郵件原件 ----
寄件人﹕ Mimi Yin <[EMAIL PROTECTED]>
收件人 Design Discussions <[email protected]>
副本(CC) Andrew Tong <[EMAIL PROTECTED]>
傳送日期﹕ 2007 年 10月 19 日 星期五 下午 5:43:15
主題： 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 = visible date, for all events
- Hidden date = visible date, for tasks with dates set explicitly
- Hidden date = 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=6311
Changing the sort order in Later & Done is this bug:
https://bugzilla.osafoundation.org/show_bug.cgi?id=8939
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. From 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!
全新升級網上相簿，讓你由相片中分享生活點滴，請前往
http://hk.photos.yahoo.com 了解更多!
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
Yahoo! 全新升級網上相簿，讓你由相片中分享生活點滴，請前往
http://hk.photos.yahoo.com 了解更多!
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
