You assign importance relative to the parent goal in MyLifeOrganized. I assume--could someone correct me if I'm wrong--that the calculation of importance as used to prioritize tasks, is multiplicative based on the fractional values of the goals.
For instance, if we use the pointer to denote fractions between 0 and 1, then if you have this hierarchy: Project:Task: Subtask: Sub-sub task, then if sub sub task contributes half the value of subtask and subtask contributes one-quarter the value of task, then sub sub task would end up with a value of 1/2 X 1/4 = 1/8. The value of 1/8 would be used to prioritize sub-sub task within Project.
BUT sub sub task must have a value absolutely, because its prioritization is being compared to tasks that do NOT belong to Project. Since the machinery is present to assign a value to Project, I assume you can give Project an absolute value. It can't be relative to anything else, because it has no parent.
If I'm right about how it works, all that matters in rating the various end goals is their relative importance. If you have three end goals, each *equal* in absolute importance, then it doesn't matter if you give each a value of 1/2 or 1/4, just so long as you apply the same scale to each ultimate Project.
In a private communication from the developer, I learned that given identical time frames (week, month, year), the importance assigned to the Project determines the priority. (Additional factors serve as tie breakers.)
This isn't logical. It is a BLUNDER plain and simple for an individual to assign a higher priority to a task with very low importance for a project a higher priority than a task of critical importance to another project, merely because the first project has a slightly higher priority.
I think if you did it multiplicatively as I suggested in my first comment, the you would have a simply brilliant application that uses the outline hierarchy fully to assign priorities that might not be immediately apparent from inspection.
Frankly I'm not sure if I understand your idea of "multiplicative" priority completely. Could you please explain it in some kind of example? I can assume that the current model in MyLife is not ideal and would love to improve it.
Thank you for your interest. Here's an example. Assume I have three root level "Projects": Work, Duties, and Fun. Under work I have a "Task": Draft demurrer. Under that Task I have the Sub-Task: Legal research.
Under Duties I have the Task "Pay Bills" and the Subtask: "Deposit money in checking account."
Under Fun I have the Task "Play tennis match" and the Subtask "Reserve tennis court"
I assign an importance to each of the Projects. The importance of work is .5; the importance of Fun is .3; the importance of Duties is .2. This is a purely subjective appraisal--importance to me.
Then I estimate the relative importance of each task for its Project. Draft demurrer has a .1 importance for Work, meaning that I estimate that the demurrer should be weighted .1 in estimating my success at the Project, Work. Then I estimate the importance of legal research for the demurrer. It gets a relative importance of .6.
Let's jump to Duties. Paying the bills get a .3 relative to the sum total of my Duties. Putting money in the bank gets .6 relative to paying bills.
Let's look at what determines the order in the to do list of the subtasks Legal Research and Put Money in Bank. Which is more important to do; if there were hypothetically a time squeeze to do one or the other, which should I sacrifice.
Legal research = Work x Demurrer x Legal Research (the first an absolute importance and the second and third relative to their parents) = .5 x .1 x .6 = .030
Put money in the bank = .2 x .3 x .6 = .036
Putting money in the bank is more important than drafting the demurrer, with these assignments. The present method would make drafting the demurrer higher priority, simply because the Project Work has more importance. Is there any question which approach is the logical one: the approach that uses all the information available, or the approach that using most of the information only to break ties.
I'm not concerned about tie breakers. With careful estimation of importance, ties will be very rare.
Intuitively, the idea is that you assign an importance to each project and for any particular task that's part of the Project, you assign a priority based on the portion of the project the task represents. A subtask is a portion of a task that in turn is a portion of a Project.
An interesting complication is where the task serves two Projects. This, I would think, could be left for future development.
In the meantime could you please comment on this situation which is based on your example. We have the following outline:
1. Complete very important project (0.8) 1.1 Send project report (0.6) 2. Organize party with friends (0.4) 2.2 Call friends (0.5)
Basing on your idea here is the importance of the tasks: "Send project report" 0.8*0.6 = 0.48 "Call friends" 0.4*0.5 = 0.20
"Send project report" is more important - everything is OK so far.
Now I need to add details for "Send project report" (expand the outline by adding more subtasks to this task) 1.1 Send project report (0.6) 1.1.1. Get the info from the team (0.5) 1.1.1.1 Organize meeting with the team (0.6) 1.1.2. Analyze information and prepare report (0.8) 1.1.3. Get approval on the report from my manager (0.9)
Now to complete "very important project" I need more subtasks. Here is the importance of the first step for this project:
"Organize meeting with the team": 0.8*0.6*0.5*0.6 = 0.144 "Call friends" is still 0.20.
It means that "Call friends" is now more important then first step to "Complete very important project". I've just added more subtasks for a projects and the importance of these subtasks is now lower then subtask of the project with initially lower importance ("Organize party with friends"). This happens just because "Complete very important project" has more subtasks. Even if these subtasks have high importance themselves, each of them would decrease the "Multiplicative" importance.
In "My Life Organized" however implemented a method of calculation the priority of the tasks which does NOT depend on the number of subtasks. In "My Life Organized" any subtask under project "Complete very important project" will be more important then any subtask under "Organize party with friends" because "Complete very important project" is more important.
Could you explain me how we could solve this problem using your method of calculation priorities?
1. It *is* appropriate that when you add levels, the importance of a talk at the deepest level, being the smallest detail, will be less important than higher level tasks. 2. I should point out that the importance of tasks at the same level should sum to 1. Otherwise the importance of the sum of the parts will be greater than the importance of the whole. 3. I think the reason this result doesn't seem intutive to you is that "Importance" is ambiguous between two connotations. A subtask can be important in that performing it is an indispensable part of the Project. Or it can be important in that how well it is done affects how well the Project succeeds. Or to say basically the same thing differently, it can be vitally important to do something on a task, where the quality of work done, the amount of effort done beyond the bare minimum, doesn't matter much.
In the example, it isn't clear which kind of importance is involved. Let's assume you mean the second. Then if you failed to call the team meeting, there would have to be a different way to get the information, such as informal conversation.
If you mean the first, the amount of effort, it might indeed be more important to put effort into calling friends, because, being the boss, you can count on people coming to the meeting, and you don't have to build the meeting like you might want to build a party.
I'd suggest that the last is the correct use of importance. Things that simply have to get done some way or another and the amount of effort doesn't matter except to do the bare minimum should be flagged in some other way. With the second concept of importance, it must follow that subdividividing a task decreases the importance of each part.
I've got a fairly long track record working with multiplicative importance in such a tool.
Multiplicative importance has long been the foundation of another program in this space called Life Balance. The multiplicative approach works well as evidenced by the success of that program. The key when going with a multiplicative approach is that you much Set the priority of each Task RELATIVE to ONLY the parent , and not in context of anything else.
The above example for your post represent the pit fall with such a powerful but flexible approach, it assumes the user "gets it".
When looking at your test case a couple of things jump out. First your sample seems to imply an ordered set of tasks. Are 1.1.1, 1.1.2, and 1.1.3 in-order tasks or parallel tasks?
If they are parrallel tasks then most everything is entered correctly. But what you missed; is that 1.1.1.1 would have an importance of (1.0) to task 1.1.1 because it's the only subtask; and therefore in a multiplicative approach it MUST by definition be the most important thing related to 1.1.1. and by that logic it would be (.21) = 0.8*0.6*0.5*1.0 This is a basic tenant of the multiplicative approach. I've long believed that life balance is slightly flawed because it doesn't force "single branches" to be importance (1.0).
Now if it's an ordered set of tasks the problem gets a bit different. 1.1.1, 1.1.2, and 1.1.3 would all by definition have a priority of (1.0) since they must be done in order and when each one is up to bat it will be the most important item to the project 1.1. Therefore in ordered occurance you would have, at any time in the process, the current up to bat task sitting at priority (0.6) as detailed in the outline below.
1.1 Send project report (0.6) 1.1.1. Get the info from the team (1.0) 1.1.1.1 Organize meeting with the team (1.0) 1.1.2. Analyze information and prepare report (1.0) 1.1.3. Get approval on the report from my manager (1.0)
Ok now in the general sense, this example was a bad example of a Parrallel set of tasks but you get the idea I hope.
Multiplicative is by far the best approach I've seen in 9 years to solving prioritizing based on importance. However, you must either build the tool to enforce certain logical adjustments -OR- assume smart users who can grasp how to set it up. In my experience Life Balance often times loses new users because the tool lets you setup up non-sensical importances that result is strangely ordered to do list; just as you did in your example case. Remember that this about modeling the real world and not all possible combinations are going to occur in nature just as the priorities in you sample wouldn't really occur; but could very easily be miss entered into the tool.
All that said there is more to consider. Importance is just one piece of the puzzle, you must also factor in due dates; and how long the task will take to complete. When calculating priority based on importance and urgency. In general:
where calcPriority needs to be crafted to produce predictable results.
Ok enough said. If you decide to tackle the multiplicative approach you'll have a winner of a tool and I'd be more than willing to engage in discussions on how to make it work. This "software" space could use some fresh tools working on these principles.
> I've got a fairly long track record working with multiplicative > importance in such a tool.
> Multiplicative importance has long been the foundation of another > program in this space called Life Balance. The multiplicative approach > works well as evidenced by the success of that program. The key when > going with a multiplicative approach is that you much Set the priority > of each Task RELATIVE to ONLY the parent , and not in context of > anything else.
> The above example for your post represent the pit fall with such a > powerful but flexible approach, it assumes the user "gets it".
> When looking at your test case a couple of things jump out. First your > sample seems to imply an ordered set of tasks. Are 1.1.1, 1.1.2, and > 1.1.3 in-order tasks or parallel tasks?
> If they are parrallel tasks then most everything is entered correctly. > But what you missed; is that 1.1.1.1 would have an importance of (1.0) > to task 1.1.1 because it's the only subtask; and therefore in a > multiplicative approach it MUST by definition be the most important > thing related to 1.1.1. and by that logic it would be (.21) = > 0.8*0.6*0.5*1.0 This is a basic tenant of the multiplicative > approach. I've long believed that life balance is slightly flawed > because it doesn't force "single branches" to be importance (1.0).
> Now if it's an ordered set of tasks the problem gets a bit different. > 1.1.1, 1.1.2, and 1.1.3 would all by definition have a priority of > (1.0) since they must be done in order and when each one is up to bat > it will be the most important item to the project 1.1. Therefore in > ordered occurance you would have, at any time in the process, the > current up to bat task sitting at priority (0.6) as detailed in the > outline below.
> 1.1 Send project report (0.6) > 1.1.1. Get the info from the team (1.0) > 1.1.1.1 Organize meeting with the team (1.0) > 1.1.2. Analyze information and prepare report (1.0) > 1.1.3. Get approval on the report from my manager (1.0)
> Ok now in the general sense, this example was a bad example of a > Parrallel set of tasks but you get the idea I hope.
> Multiplicative is by far the best approach I've seen in 9 years to > solving prioritizing based on importance. However, you must either > build the tool to enforce certain logical adjustments -OR- assume smart > users who can grasp how to set it up. In my experience Life Balance > often times loses new users because the tool lets you setup up > non-sensical importances that result is strangely ordered to do list; > just as you did in your example case. Remember that this about modeling > the real world and not all possible combinations are going to occur in > nature just as the priorities in you sample wouldn't really occur; but > could very easily be miss entered into the tool.
> All that said there is more to consider. Importance is just one piece > of the puzzle, you must also factor in due dates; and how long the task > will take to complete. When calculating priority based on importance > and urgency. In general:
> where calcPriority needs to be crafted to produce predictable results.
> Ok enough said. If you decide to tackle the multiplicative approach > you'll have a winner of a tool and I'd be more than willing to engage > in discussions on how to make it work. This "software" space could use > some fresh tools working on these principles.
I've also used LifeBalance for awhile now and while I "get it", I still find the order of some tasks frustrating in LB. You'll often hear LB users talking about tweaking the importance until they get, what they feel, is a reasonable order of tasks. I actually like myLifeOrganized (MLO?) approach of being able to set certain tasks as Weekly, Monthly or Yearly goals in order to bring them to the top. Even if you go with a multiplicative approach, which I agree is very powerful, you still need some way of overriding that to bring the focus around to particular tasks.
Sticking with the multiplicative approach..... The way to account for this is to factor in urgency as a "booster" value; After all urgency is what separates 5 equally important items in the "real world"
if importance is a scale of "0-1" then there are a couple of approaches to this:
1) Add an "urgency" slider with the range "1-2" or "1-10".
2) In the Life Balance implementation you can get that effect by setting a due date in the past or in the very near future with a large lead time.
3) Simply allow "once" tasks to have a "lead time" and reference that from Today.
I would prefer to have both option 1, and 3. They both factor into the algorithm differently and that would be the most powerful.
>I've also used LifeBalance for awhile now and while I "get it", I still
>find the order of some tasks frustrating in LB. You'll often hear LB
>users talking about tweaking the importance until they get, what they
>feel, is a reasonable order of tasks. I actually like myLifeOrganized
>(MLO?) approach of being able to set certain tasks as Weekly, Monthly
>or Yearly goals in order to bring them to the top. Even if you go with
>a multiplicative approach, which I agree is very powerful, you still
>need some way of overriding that to bring the focus around to
>particular tasks.
Hello: Stephen R. Diamond, jamezzz, ratz and Bob Pankratz
So let's define the names of the algorithms we are talking about:
1) "LB algorithm" - the way Life Balance calculates priority of the tasks (sort them in the to-so) right now 2) "MLO algorithm" the way MyLife Organized does this. I think it is mostly based on (1) with the only deference: "Weekly Goal" always brings the task on the top. It is described there with more details: http://www.mylifeorganized.net/products/my-life-organized/how-it-work...
3) "Multiplicative algorithm" the way Stephen R. Diamond (and ratz?) propose it. 4) "Combined approach" some kind of combination of the approaches.
If I understand everybody correctly the approach (3) is different from approach (1) Right? But these words of ratz confused me. What approach you mentioned here (1) or (3)? : [ratz wrote]
>The key when going with a multiplicative >approach is that you much Set the priority >of each Task RELATIVE to ONLY the parent , >and not in context of anything else.
Because according to Stephen it is not a "Multiplicative" algorithm right?:
[Stephen wrote:] >I think if you did it multiplicatively as >I suggested in my first >comment, the you would have a >simply brilliant application
Anyway I have a proposition for Stephen, ratz and Bob Pankratz. Can you describe the algorithm you propose short and logical (mathematically?) so that I understand the way you want me to implement it. Once we agree on this algorithm I will implement it as an alternative for the current MLO algorithm (you will have to select what algorithm you will use in the options of the application). This way we could play with this together and improve it if necessary.
1) The LB algorithm is very complicated and unknown to us. All we have are guesses as to how it works. But we understand what we like about it is the multiplicative approach and the factoring of several items to calculate a priority.
2) MLO algorithm; understood based on the best guess of (1) and the nice addition of the goals.
3) Mutliplicative is the same as (1) but with some extra "rules" to prevent entering a bogus combination. example if only 1 subtasks it should be essential. Child tasks always have an importance "relative" to the parent task. Global priority of the task is calculated down the branch by multiplying.
(4) Combined approach really would be great. The whole "boost" concept is to avoid the problems cause by making (3) smart enough to protect the user from themselves.
I've have a theoretical math background and I am willing to take a swing at an algorithm; and then have everyone else tear it apart and make it better. I would be able to work on it tonight after 6pm CST US time. (it's 9am now).
What would help me is a definition of the object values you currently have defined for a task item; then I can factor in everything you have available. Several of the names I see poping on this list; have been discussing this topic for about 3-5 years now; I bet in a week we could have a pretty solid algorithm defined.
A quick example for a branch and some of the things to consider for just the thought of urgency.
myLifeOrganized wrote:
>Hello: Stephen R. Diamond, jamezzz, ratz and Bob Pankratz
>So let's define the names of the algorithms we are talking about:
>1) "LB algorithm" - the way Life Balance calculates priority of the
>tasks (sort them in the to-so) right now
>2) "MLO algorithm" the way MyLife Organized does this. I think it is
>mostly based on (1) with the only deference: "Weekly Goal" always
>brings the task on the top. It is described there with more details:
>http://www.mylifeorganized.net/products/my-life-organized/how-it-work...
>3) "Multiplicative algorithm" the way Stephen R. Diamond (and ratz?)
>propose it.
>4) "Combined approach" some kind of combination of the approaches.
>If I understand everybody correctly the approach (3) is different from
>approach (1) Right? But these words of ratz confused me. What approach
>you mentioned here (1) or (3)? :
>[ratz wrote]
>>The key when going with a multiplicative
>>approach is that you much Set the priority
>>of each Task RELATIVE to ONLY the parent ,
>>and not in context of anything else.
>Because according to Stephen it is not a "Multiplicative" algorithm
>right?:
>[Stephen wrote:]
>>I think if you did it multiplicatively as
>>I suggested in my first
>>comment, the you would have a
>>simply brilliant application
>Anyway I have a proposition for Stephen, ratz and Bob Pankratz. Can
>you describe the algorithm you propose short and logical
>(mathematically?) so that I understand the way you want me to implement
>it. Once we agree on this algorithm I will implement it as an
>alternative for the current MLO algorithm (you will have to select what
>algorithm you will use in the options of the application). This way we
>could play with this together and improve it if necessary.
>What would help me is a definition of the object values >you currently have defined for a task item >I can factor in everything you have >available.
If I understand you correctly this is what I have right now:
1) Weekly goal (yes/no) 2) Importance (0-99) or you can use 0..1) 3) Time (how close the deadline is to the day specified) 4) Project completion per cent (how many subtasks of the current project are still uncompleted)
myLifeOrganized wrote:
>Thank you Bob for taking care of this.
>>What would help me is a definition of the object values
>>you currently have defined for a task item
>>I can factor in everything you have
>>available.
>If I understand you correctly this is what I have right now:
>1) Weekly goal (yes/no)
>2) Importance (0-99) or you can use 0..1)
>3) Time (how close the deadline is to the day specified)
>4) Project completion per cent (how many subtasks of the current
>project are still uncompleted)
Life Balance does not reveal its algorithm, not because it's a trade secret--which could make sense--but because they don't want to suffer diverting discussion concerning it. I can't sympathize with such obscurantism.
In experimenting with the LifeBalance algorithm, its clear to me it invokes a multiplicative rule, which is modifiable by other considerations. Presently MyLifeOrganized does not invoke a multiplicative rule, despite collecting the information needed to use one. Instead it uses the rule that the importance of the highest factor always predominates, with the lower levels serving a tie-breaker function.
Deriving the importance of a subtasks from the importance of the Project it subserves can only be done one way. Anything else can only be called error. The way you combine other factors that moderate the impact of importance in determining overall priority--I propose these terms to capture the distinction, importance for the result of the computation based on the hierarchy and priority for the ultimate factor determining placement in a list--is artful rather than necessary and may reflect not only imperfect guesses as to how to model mathematically the function the individual would like to use but also value judgments about what function the individual should use. I'm not sure the mathematically true function should be clouded with the ad hoc pragmatic corrections. Why compute something that is imaginary? Perhaps the best approach might be to output an initial priority based solely on importance, and also capture the additional relevant information. How to combine the information may best be left to the user's ad hoc judgment. The user needs to know what the rational importance of a task is AND needs also to _consider_ whether some other reason over-rides importance in a given situation.
Personally, I didn't come to the multiplicative approch via Life Balance. I "invented" it myself, and then looked to find programs that proved that my invention was NOT actually novel. I found Life Balance from Andrei's recommendation. The root of my belief that multiplication is the way to go comes from using the outline processing software BrainStorm (http://www.brainstormsw.com), which maintains the users focus by only displaying two levels of an outline at a time, so that the user only needs to consider the relevance of an item to its parent and its consistency with its sibling topics. I figured this same hierarchical concept would be useful in determining priority in a todo list.
IMHO the key here is to get an algorithm that works well; and expose the inputs to the algorithm to the user in such a way that logical input yeilds logical output; and still have an easy to grasp interface.
At least that's the goal I'd strive for until some can clarify on it; which is always a good thing :)
srd wrote:
>Life Balance does not reveal its algorithm, not because it's a trade
>secret--which could make sense--but because they don't want to suffer
>diverting discussion concerning it. I can't sympathize with such
>obscurantism.
>In experimenting with the LifeBalance algorithm, its clear to me it
>invokes a multiplicative rule, which is modifiable by other
>considerations. Presently MyLifeOrganized does not invoke a
>multiplicative rule, despite collecting the information needed to use
>one. Instead it uses the rule that the importance of the highest factor
>always predominates, with the lower levels serving a tie-breaker
>function.
>Deriving the importance of a subtasks from the importance of the
>Project it subserves can only be done one way. Anything else can only
>be called error. The way you combine other factors that moderate the
>impact of importance in determining overall priority--I propose these
>terms to capture the distinction, importance for the result of the
>computation based on the hierarchy and priority for the ultimate factor
>determining placement in a list--is artful rather than necessary and
>may reflect not only imperfect guesses as to how to model
>mathematically the function the individual would like to use but also
>value judgments about what function the individual should use. I'm not
>sure the mathematically true function should be clouded with the ad hoc
>pragmatic corrections. Why compute something that is imaginary? Perhaps
>the best approach might be to output an initial priority based solely
>on importance, and also capture the additional relevant information.
>How to combine the information may best be left to the user's ad hoc
>judgment. The user needs to know what the rational importance of a task
>is AND needs also to _consider_ whether some other reason over-rides
>importance in a given situation.
>Personally, I didn't come to the multiplicative approch via Life
>Balance. I "invented" it myself, and then looked to find programs that
>proved that my invention was NOT actually novel. I found Life Balance
>from Andrei's recommendation. The root of my belief that multiplication
>is the way to go comes from using the outline processing software
>BrainStorm (http://www.brainstormsw.com), which maintains the users
>focus by only displaying two levels of an outline at a time, so that
>the user only needs to consider the relevance of an item to its parent
>and its consistency with its sibling topics. I figured this same
>hierarchical concept would be useful in determining priority in a todo
>list.
I love the ideas you are throwing around. I have been contemplating some of these features for quite a while. There are 2 additional factors I would like to have considered. The first, and to me the most important of the two, is a concept of time needed. For example, if I give each task an estimated completion time, I would like to have a hotkey (CTRL-T maybe) which asks me how much time I have to work. I would then fill in this value and MLO would show me only the things I have time to work on, in the context I am in. So, if I have 20 minutes until a meeting, I would hit CTRL-T, fill in 20, and MLO would filter and show only the tasks that are 20 minutes or under, still sorted by the MLO algorithm. Taking this one step further, when I finish a task, I could fill in the actual time spent on this task. Then, MLO could keep an average time, I call Slack time, showing for example that I am underestimating my time by 20%. If I wanted MLO to help me make a more accurate statement of what I can accomplish, I could select an option in Preferences that would artifically boost my estimated time by the SLACK percentage. So, if I have 20 minutes until my next meeting, I may only see items that can take 10 minutes or less because my slack percentage is 100, for example. Finally, I would like something I have named a half-life decay. This one, just artifically boosts tasks that are old. Some thoughts on this one: the average age of my tasks is 18 days (meaning, the date the task was entered). The tasks that have ages greater than 18 days would start boosting their importance values. So if something has been sitting out there for 6 months, it will be moving up the ladder. What happens to me often is that older tasks get lost. Usually, this is because I am letting newer items have an artifically higher importance just because they are on my mind. I would never let a decay item go higher than a high priority (gotta be done today) item.
Just some thoughts. Decay isn't something that has been completely thought through yet, however, I have noticed this same problem no matter what system I use (however, A&B and LB showed this problem better than most). However, I think the "what can I do with this amount of time at this place" is an essential part of task management.
I'll comment on "concept of time needed" now. I'm glad to hear that you
mentioned this.
Actually in MLO the following hidden fields are already implemented: - Task estimate (time needed for complete it)
- "How much time I have now" - additional filter field in ToDo advanced
options.
These fields are *hidden* for now (do not search for them :) since I had no
time to finish the functionality. I need it myself so it was designed.
Actually I thought about two fields (min and max) but I still did not decide
if two fields are needed.
Thanks that you mentioned this function. I do not have time to introduce and
explain all the MLO features I have in my personal "wish list" so I'll do it
step-by-step after somebody come up with the same idea and prove my
thoughts.
I'll update this item in the plan:
#F025 Task/Project estimated time (by developers and thanks to David)
You could enter estimation time for a task. As a result you will have the
following features:
- How much time would project take? It is calculated as a sum of the time
needed for each subtask. - I have 30 free minutes now. Select items from the to-do list I can
complete during this time (sorted by formula used in MLO)
> -----Original Message-----
> From: dbcoyer [mailto:david.co...@gmail.com] > Sent: Wednesday, March 23, 2005 11:47 PM
> To: myLifeOrganized@googlegroups.com
> Subject: Re: Scaling the Importance of Tasks
> If I could throw in my 2 cents...
> I love the ideas you are throwing around. I have been contemplating
> some of these features for quite a while. There are 2 additional
> factors I would like to have considered.
> The first, and to me the most important of the two, is a concept of
> time needed. For example, if I give each task an estimated completion
> time, I would like to have a hotkey (CTRL-T maybe) which asks me how
> much time I have to work. I would then fill in this value and > MLO would
> show me only the things I have time to work on, in the > context I am in.
> So, if I have 20 minutes until a meeting, I would hit CTRL-T, fill in
> 20, and MLO would filter and show only the tasks that are 20 > minutes or
> under, still sorted by the MLO algorithm. Taking this one > step further,
> when I finish a task, I could fill in the actual time spent on this
> task. Then, MLO could keep an average time, I call Slack time, showing
> for example that I am underestimating my time by 20%. If I wanted MLO
> to help me make a more accurate statement of what I can accomplish, I
> could select an option in Preferences that would artifically boost my
> estimated time by the SLACK percentage. So, if I have 20 minutes until
> my next meeting, I may only see items that can take 10 minutes or less
> because my slack percentage is 100, for example.
> Finally, I would like something I have named a half-life decay. This
> one, just artifically boosts tasks that are old. Some thoughts on this
> one: the average age of my tasks is 18 days (meaning, the > date the task
> was entered). The tasks that have ages greater than 18 days > would start
> boosting their importance values. So if something has been sitting out
> there for 6 months, it will be moving up the ladder.
> What happens to me often is that older tasks get lost. > Usually, this is
> because I am letting newer items have an artifically higher importance
> just because they are on my mind. I would never let a decay item go
> higher than a high priority (gotta be done today) item.
> Just some thoughts. Decay isn't something that has been completely
> thought through yet, however, I have noticed this same problem no
> matter what system I use (however, A&B and LB showed this problem
> better than most).
> However, I think the "what can I do with this amount of time at this
> place" is an essential part of task management.
>I'll comment on "concept of time needed" now. I'm glad to hear that you
>mentioned this.
>Actually in MLO the following hidden fields are already implemented: > - Task estimate (time needed for complete it)
> - "How much time I have now" - additional filter field in ToDo advanced
>options.
>These fields are *hidden* for now (do not search for them :) since I had no
>time to finish the functionality. I need it myself so it was designed.
>Actually I thought about two fields (min and max) but I still did not decide
>if two fields are needed.
Frankly I did not plan to integrate appointments into MLO....
But your idea is great. I'll probably consider it. It would be very useful
feature: "Tell me what should I do before next appointment today."
For now you should calculate yourself how much time you have before the next
appointment and enter it to MLO filter (after I implement this filter).
I am still thinking of Min/Max estimate time properties for a task. I mean:
"this task would take 1 hour (min) - 1.5 (max)". I can see that it is useful
in estimate calculation: "The entire project will take 130-150 hours."
Where else can I use it?
In the "available time" filter for to-do I'll probably should consider only
Min....
> -----Original Message-----
> From: Bob Pankratz [mailto:rpankr...@mac.com] > Sent: Thursday, March 24, 2005 3:59 PM
> To: myLifeOrganized@googlegroups.com
> Subject: Re: Scaling the Importance of Tasks
> Min / Max yes....
> Link to Calendar..... yes
> Display only Tasks that fix in the time windows between "Now" and the > next appointment.
> Of course that mode would always require a manual "update" and Auto > would cause the task you are currently working on to disappear..
> :)
> Andrey Tkachuk wrote:
> >David,
> >I'll comment on "concept of time needed" now. I'm glad to > hear that you
> >mentioned this.
> >Actually in MLO the following hidden fields are already implemented: > > - Task estimate (time needed for complete it)
> > - "How much time I have now" - additional filter field in > ToDo advanced
> >options.
> >These fields are *hidden* for now (do not search for them :) > since I had no
> >time to finish the functionality. I need it myself so it was > designed.
> >Actually I thought about two fields (min and max) but I > still did not decide
> >if two fields are needed.
I have 15 minutes available; I don't want to see any task that has a minimum higher than 15 minutes as I could not make useful progress on it. That's the only use I see for Min, but it's a powerful one.
Andrey Tkachuk wrote:
>Frankly I did not plan to integrate appointments into MLO....
>But your idea is great. I'll probably consider it. It would be very useful
>feature: "Tell me what should I do before next appointment today."
>For now you should calculate yourself how much time you have before the next
>appointment and enter it to MLO filter (after I implement this filter).
>I am still thinking of Min/Max estimate time properties for a task. I mean:
>"this task would take 1 hour (min) - 1.5 (max)". I can see that it is useful
>in estimate calculation: "The entire project will take 130-150 hours."
>Where else can I use it?
>In the "available time" filter for to-do I'll probably should consider only
>Min....
>>-----Original Message-----
>>From: Bob Pankratz [mailto:rpankr...@mac.com] >>Sent: Thursday, March 24, 2005 3:59 PM
>>To: myLifeOrganized@googlegroups.com
>>Subject: Re: Scaling the Importance of Tasks
>>Min / Max yes....
>>Link to Calendar..... yes
>>Display only Tasks that fix in the time windows between "Now" and the >>next appointment.
>>Of course that mode would always require a manual "update" and Auto >>would cause the task you are currently working on to disappear..
>>:)
>>Andrey Tkachuk wrote:
>>>David,
>>>I'll comment on "concept of time needed" now. I'm glad to
>>hear that you
>>>mentioned this.
>>>Actually in MLO the following hidden fields are already implemented: >>> - Task estimate (time needed for complete it)
>>> - "How much time I have now" - additional filter field in
>>ToDo advanced
>>>options.
>>>These fields are *hidden* for now (do not search for them :)
>>since I had no
>>>time to finish the functionality. I need it myself so it was
>>designed.
>>>Actually I thought about two fields (min and max) but I
Since Andrey is probably either coding or doing the holiday thing. The non official (aka don't get mad at him if I'm miss informed) word was that the gui layout changes where first because the new interface items to support the algorithm needed to be added. Then after that the lgorithm could be added. So that wouldn make it at least to dev/test/release cycles assuming the new gui is made availalbe to user to use and feedback on.