(Yes, that's what I was saying. ...Bryan) Mimi Yin wrote: > 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 > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Open Source Applications Foundation "Design" mailing list > http://lists.osafoundation.org/mailman/listinfo/design _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
