> > Hi Christoph, You present a well thought out and researched alternative for scoring dates in the calculation of ComputedScore. I acknowledge that your alternative handles the following use case: [A task has no start or due date specified. The user specified a due date and observes the change in Computed Score] in a manner that's considerably more consistent with intuitive expectation that does the current implementation.
But I feel that other use cases produce a less desirable result, and I would like to present two such use cases. [A task has no start date specified and has a due date of tomorrow. The user specifies start date of today and observes the change in ComputedScore] This use case involves a change which intuitively feels like it should have little if any effect on ComputedScore, however it would produce an enormous change because the "elapsed"variable is changing from infinite to zero. [A collection of tasks has varying urgency settings, start dates and due dates and is displayed in a list sorted by ComputedScore. The user adds a task with an urgency setting of max (200) and no start or due date specified, and observes where the new task is positioned in the list.] When I am managing a crisis and I discover a task that absolutely must be dealt with immediately I may not want to spend the time to create it with a fully specified and accurate set of dates. Instead I will most like use Rapid Task Entry with a specification something like Put out fire -u5 which will create a task with no context (in my system that means it must be dealt with today) and maximum urgency. In my view, no task should be able to exceed this task's (urgency+dates) score, however in your scheme, a task with lower urgency and a future due date could do so. How much lower the urgency and how far future the date depends onthe weighing assigned to the date weight factors. However, any setting that eliminates this concern would essentially make the dates irrelevant. I have no doubt that you could tweak your proposal in ways that would correct these issues. But my point is that you will end up needing far more than just another on/off switch to enable this way of weighting urgency.l You will also need more weighting sliders and, maybe a choice as to whether the urgency setting is linear. (I believe that the difference between 175-a lot and 200-max is way more significant than the difference between 60-less and 85-still less.) In my opinion, the only recommendation that would bring an actual resolutionto this issue would be if MLO implemented a computed-score API. That way you could build your hyperbolic formulas, I could run through lots of use cases, and the average user could just ignore the issue. -Dwight -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mylifeorganized. To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/c943a95e-5cd4-4e9a-8e77-b13965c46d81%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
