Lisa, the reason I didn’t suggest an “override” value for combining manual and automatic sorting together in one list isn’t because of the complexity of doing that. Although it is complex since you need to dynamically create an override temp value for each sort criteria for each task for EVERY manual view created. That is hard enough to do but that isn’t the reason.
The real reason is the alternate completion that moves a new copy of the task to the end of the list. Once you cross off an item and put it at the bottom then there really isn’t any order remaining in the rest of your list. Try doing that a few times in a manual list. Randomly pick tasks in your list and alternately complete them. Then you will see that there really isn’t any order in the task list to automatically place anything anywhere but at the end. On Jan 30, 4:11 pm, Lisa Stroyan <[email protected]> wrote: > First of all, let me say that I consider this purely a fun technical > exercise - I think for the next release, cleaning up the usability of > the current solution is probably the right answer.... > > I still think that if we are adding new things into the list in the > right place, that my original idea would work. Let's take Ron's > example. The convention I'll use is that when a task is moved, I'll > put it in bold here. The system has to keep track of which have been > moved in order for this to work. It's a simple data field, per view. > > So his original list of sort-values was: > 1,1,2,2,2,3,3,4,4,5,6,7,7,8,9 > > Then he moved them around: > 1,5,2,2,3,7,4,6,2,3,4,7,1,8,9. > > (notice that the non-bold are in numerical order - they were never moved). > > Now, you want to insert something into the list. You simply ignore > the moved tasks in your calculations. > > So, to insert a 3, you would pass 1 because of sort order, pass 5 > because it's ignored, pass 2, 2, and 3 because of sort order, you > pass 7 because it's ignored, and now you see it goes before 4. Now, > there is a choice - do you put it before or after the moved items - > in this case, 7? I say after - it's easier to implement (slightly) > because you don't have to back up, and it makes more sense to me, but > either way works. Or if you want to get complicated, once you find > the place in the list not using your moved tasks (between 3 and 4), > you could place it within the sublist of moved tasks according to > their values - basically a secondary sort. > > So, you put it between 7 and 4. Because that is where it would go if > the 7 wasn't there. If you were doing the second refinement, you > would first figure out that it goes between the unmodified 3 and 4, > and then since 3 is leass than 7, you would put it ahead of 7. But > if the 7 was a 1 that you had put there earlier, you put the 3 behind the 1. > > When an non-moved item's sort-value is modified, you have to use this > same strategy to place it as if its a new item, or mark it as "moved" > in the list so it will be ignored...otherwise your list gets corrupted. > > The big disadvantage of my strategy is that things you have moved > will tend to drift up over time, as other tasks are completed and new > tasks are added. That's true of manual mode now though. > > As my husband pointed out, a more elegant way to do this is not to > have manual vs. automatic mode at all. You could keep an alternate > value for each sort criteria on items manually moved. So when you > moved the 5 in the first place, you would give it a manual-sort-value > of 1. (I don't know how you would tell where in the "1s" to put it > though). You wouldn't change it's actual sort value, which is > 5. Then, basically you wouldn't have any differentiation between > manual and automatic sort. The UI would have to mark the moved items > (perhaps a "pinned" icon) and alllow you to "unpin" them, to set them > back to normal. It seems pretty tricky to take into account all the > special cases though. > > He then suggested you could take this even further for computed > score. When you manually moved an item with a computed score, you > could set it's "manual-sort-computed-score-offset" to be used as an > offset from it's previous value that would put it into that > particular position. (In the above example, when you are moving that > first 5, you give it an offset of 1 (the value of the spot you put it > in the list) minus 5, or -4. Then, if you changed one of the > parameters that went into the computed score, it would change the > base that the offset is applied to, making even your "pinned" (moved) > items, dynamically update when you modify them, but keep their > relative places in line. For most sort orders, this would be > confusing for users, but since computed-score is such a black box for > most of us anyway, it might just work :) > > Now see, isn't this discussion much more fun than the things at the > top of your task list? :) > > Lisa > > ---------- > Lisa Stroyan, mailto:[email protected] -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
