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.
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? 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
