This seems to be the same (or similar to) as my suggestion for effectively having two lists in the same view: a manual list at the top and then a sorted list below (or am I missing something).
I would vote for this over the current setup - and it has the merit of being simple to understand (not sure about the simple to implement) Where you have grouping, there could be a separate manual list within each group. [Aside: this also raise the question with regard to the current approach where you have grouping - what happens in a view that is grouped by due date (say) when the day rolls over. For example: if you ahve a manually sorted list for today, what happens to these items when they move into the 'Yesterday' group (are they treated as new items, do they retain their existing manual sort, etc). Has anybody sussed this out. On Jan 30, 11:08 pm, nschm873 <[email protected]> wrote: > Been thinking about the combination of sorted and manual lists. I > believe the whole reason for the manual list was to let MLO help > facilitate the use of Forster’s autofocus technique. This means that > the manual list needs to be able to allow an alternate completion of > crossing off the current version of the task and re-adding it at the > bottom. This means that the manual list needs to be manual from top > to bottom. > > It does NOT, however, mean that there can’t be two lists, a manual > list of already “selected” items and a “sorted” list for “new” items. > One of the keys in both GTD and Autofocus is the use of a “closed > list”. This is either the tasks selected in the GTD review process to > be worked on for that time period or the tasks on an individual work > page from autofocus. > > In either case “new stuff” doesn’t generally go directly into that > list, at least not without a review. So here is what I propose for a > solution: > > Use the views sort selection to create the list of tasks in the “new > items list.” Then be able to click, ctrl-click and shift click your > selections of tasks that can be moved to the manual list. These tasks > can then be re-ordered any way you want. > > For autofocus you can also select new tasks and then be able to create > (by right clicking) a different (1-4) manual page to group items into > another autofocus page. This would also be useful for Covey types in > that they could differentiate pages based on their ABC priorities. > Autofocus people would need to keep moving all of page 2 to page 1 > when page one completes but I don’t think that that would be much of > an issue. > > Then you can have a column in the outline section to specify a “page” > for each task. Blank means a “new” item. > > Then for those of us that don’t need multiple pages having a manual > and sorted list would allow us to differentiate those tasks we need to > do and those “selected in the manual list” tasks we have already > committed to and are working on… > > 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] - Hide > > quoted text - > > - Show quoted text - -- 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.
