Why setting a future due date to a task decreases its urgency ?!

137 views
Skip to first unread message

thomas COQUEREAU

unread,
Aug 6, 2015, 4:52:27 AM8/6/15
to MyLifeOrganized
Hi,
I'm currently extensively testing MLO, which I like very much in many aspects. But there is one thing that makes absolutely no sense to me. 
I understand that they worked quite a lot about urgency and importance ratings in the to do list order of appearance.
However, setting a future due date (more than one day in the future) decreases its urgency and thus places the task at the bottom of the todo list (AFTER tasks which have NO DUE DATES assigned.)

Please tell me I'm missing something, as I cannot believe a software company that has so many years of existence and surely put some work behind this to do list feature, has not fixed such an obvious problem yet.
Or there is another reason why, that is beyond me.

Could you please give me some hints,

Thank you very much for your help,
Thomas

pottster

unread,
Aug 6, 2015, 5:35:34 AM8/6/15
to MyLifeOrganized
Hi Thomas,

I'm probably not the best person to respond since I no longer use urgency/importance to sort but I'd just point out that you can attribute weighting to the Due Date in Tools>Options>Current MLO data file>To-Do ordering options. I would also say that I believe it is logical putting a Due Date back should reduce it's priority relative to No Date since a later Due Date CAN wait whereas a No Date is indeterminate. However, I can appreciate why this might not be desirable behaviour in every person's use case.

Christoph Zwerschke

unread,
Aug 6, 2015, 6:27:15 AM8/6/15
to mylifeo...@googlegroups.com
Am 06.08.2015 um 00:11 schrieb thomas COQUEREAU:
> However, setting a future due date (more than one day in the future)
> decreases its urgency and thus places the task at the bottom of the todo
> list (AFTER tasks which have NO DUE DATES assigned.)

Hi Thomas,

that's the single most annoying issue to me as well. The calculated
score would be a killer feature, but that behavior totally ruins it.

I have reported it as an issue here:
http://mlo.uservoice.com/forums/9235-general/suggestions/6511892-calculate-tasks-with-no-due-date-as-lower-priority

Revisiting it today I noticed that this only has one vote, though I'm
pretty sure it annoys other users as well.

Another indicator that UserVoice is not really working the way it
should, as Dwight just mentioned.

-- Chris

Christoph Zwerschke

unread,
Aug 6, 2015, 6:49:39 AM8/6/15
to mylifeo...@googlegroups.com
Actually I did not report this, someone else stumbled over the same
problem, and I just commented since I have the same problem.
Unfortunately I did not have any more votes to upvote it. And I wonder
if I should even bother to vote when no developers seem to be reading
there. The issue ended with a question, and until now the developers
didn't even bother to give a quick answer whether they recognize this is
an issue or not.

-- Chris






Dwight Arthur

unread,
Aug 6, 2015, 12:00:52 PM8/6/15
to MyLifeOrganized
Hi, Thomas: For me, a task with a future due date can wait while a task with no due date should be considered as possibly something to be done today./ I understand that everybody looks at this kind of thing differently, and I'm not suggesting that you would look at it the way I do. However, as Pottster was mentioning, this is all very flexible, with switches and sliders to fine tune it to math what you expect. I would suggest that you examine pages 45-50 of the user manual, and then try fiddling with the controls mentioned there to see if you can't come up with something that matches your expectations. If not, please write back in showing what settings you tried and what results you got.

Hi, Christoph.
The UserVoice item to which you refer involves adding another option to computed score. I would like you to know that computed score is already the single most complex configuration I have ever tried to tune and I have tuned some heavy stuff in my life. Adding yet another parameter is unlikely to make it any easier to understand. Before I would consider supporting a request to add another parameter I would want to know whether you had even tried to achieve what you want by adjusting the existing parameters, what you had tried, and how it had worked. Like Pottster, I hardly use this so I cannot give a lot of specific advice but I'm guessingthat a close reading of the relevant section of the user manual would be helpful.
-Dwight

Christoph Zwerschke

unread,
Aug 6, 2015, 1:41:24 PM8/6/15
to mylifeo...@googlegroups.com
Am 06.08.2015 um 18:00 schrieb Dwight Arthur:
> Hi, Christoph. The UserVoice item to which you refer involves adding
> another option to computed score. I would like you to know that
> computed score is already the single most complex configuration I
> have ever tried to tune and I have tuned some heavy stuff in my life.
> Adding yet another parameter is unlikely to make it any easier to
> understand. Before I would consider supporting a request to add
> another parameter I would want to know whether you had even tried to
> achieve what you want by adjusting the existing parameters, what you
> had tried, and how it had worked. Like Pottster, I hardly use this so
> I cannot give a lot of specific advice but I'm guessingthat a close
> reading of the relevant section of the user manual would be helpful.

Dwight, I have already read the detailed docs about the computed-score
priority and I understand how it works.

It looks pretty complex, but it is not so complex actually. The only
relevant part for our issue is the section "Factoring Dates into the
Urgency Calculation". That section is written with several case
distinctions, which makes it overly complex to read. In reality, no case
distinction would be necessary if the author had just written "we treat
unset start and due dates as the current date".

The date contribution as a function of time is then simply a linear
function (like shown here:
http://www.jleemack.com/uploads/6/7/9/7/6797819/4025486.jpg). If you
switch on "overdue boost", then the negative part of the function is
quadratic instead of linear.

The only things you can tweak are whether you want that overdue boost
(yes or no) and the weight factors, i.e. the slope of the linear
function. However, you cannot change how unset dates are treated (namely
as "current date") - and that is in practice a much more important
option than changing the slope of the function.

Your understanding that tasks with no due date should be considered "due
today" is not very intuitive for me. If I set not due date, then the
task simply has no due date, i.e. can be done any time, even a year
later. So a task that is due next week should have a higher priority,
not a lower one, as it is right now.

Mathematically speaking, "start date" and "due date" are the lower and
upper limits of an interval (for the time when it's feasible to act on
the task). If there is no start date, then normally this means that
there is no lower limit (or lower limit = -infinity), if there is no due
date, then there is no upper limit (or upper limit = +infinity).

My suggestion to fix this would be to change the mathematical function
for the date score contributions so that it does not work linearly over
the time as x-axis but flattens out and has an asymptotic lower and
upper limit when going to infinity (like this:
http://intmstat.com/analytic-trigonometry/arctanx.gif); the lower limit
should be used for unset start dates, the upper limit for unset due dates.

There should also be an option to have unset start and due dates
interpreted as "today", for people who think the current behavior is
more reasonable. But still I think this is not the obvious choice for
the option and therefore should not be the default.

-- Christoph

Christoph Zwerschke

unread,
Aug 6, 2015, 2:46:32 PM8/6/15
to mylifeo...@googlegroups.com
I have googled a bit to find if there are existing formulas for a
computed score, but didn't find anything really profound.

Here is somebody who also proposes using a linear function:
http://stackoverflow.com/questions/2379319/combined-average-for-priority-and-due-date

Request tracker uses a hyperbolic function:
https://www.bestpractical.com/docs/rt/4.2/RT/Action/EscalatePriority.html

Maybe a hyperbolic function would be the best fit. You can put it
piecewise together so that it's similar to the -arctan(x) function:

Piecewise[{{1/(x-1)+2, x<0}, {1/(x+1), x>0}}]

You can enter that formula into http://www.wolframalpha.com to see how
the function looks like. It would be 1 for tasks due today, going down
to zero for tasks due in the future, and going up to 2 for long overdue
tasks. Then you could weigh the date contribution with a factor and sum
it up with the other contributions for the score.

-- Christoph


Christoph Zwerschke

unread,
Aug 7, 2015, 12:53:58 AM8/7/15
to mylifeo...@googlegroups.com
The article
http://idealistcareers.org/could-this-math-equation-revolutionize-your-to-do-list/
suggests these score points:

This month = 5 points
Next month = 4 points
This quarter = 3 points
Next quarter = 2 points
End of year = 1 point

This is very similar to using a hyperbolic formula as I suggested in my
last post: http://bit.ly/1W4aag4

-- Christoph

Dwight Arthur

unread,
Aug 7, 2015, 2:24:11 AM8/7/15
to MyLifeOrganized
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

Christoph Zwerschke

unread,
Aug 7, 2015, 4:11:14 AM8/7/15
to mylifeo...@googlegroups.com
Am 07.08.2015 um 08:24 schrieb Dwight Arthur:
> [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.

That's why I proposed a bounded function that does not go to infinity
when the elapsed time goes to infinity. Rather it would be:

-infinity = 100%, today = 50%, +infinity = 0%.

Also, the weight factor for the start date contribution would be
normally lower than the one for the due date. Or maybe one could use a
completely different function for the start date contribution, or no
contribution at all: The main use of the start date field is to suppress
tasks that have not yet started in the todo views. So you will not see
tasks that will start in the future anyway. And for the tasks that have
already started, it does not matter much whether they have started a
week ago or just now, or whether they have no start date (i.e.
-infinity), and it is unclear which of them you want to boost.

> 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.

You're completely right with the first part of your sentence, but my
scheme solves that issue that exists in the current implementation.
That's exactly why I want to change the linear function to a bounded
function, i.e. one that has an upper limit. The due date contribution
could then never surpass the other factors like importance and urgency
(as it is doing right now, not with an unset due date, but if the due
date is far enough back in the past!).

So the due date contribution should not be limited only in order to deal
with the "unset due date" issue, but it also makes sense in view of
general productivity principles, and because the other contributions to
the computed score are also limited.

> In my opinion, the only recommendation that would bring an actual
> resolutionto this issue would be if MLO implemented a computed-score
> API.

An API would mean I must implement it in my own plugin, and that for
every platform. Nobody would want to do that.

I guess what you have in mind is having a way to enter your own formulas
- however MLO would need to support some kind of scripting language and
this may be difficult to implement, i.e. a lot of work for the
developers and again few users who would really use that.

I think more pragmatically: Creating a computed score is always a
compromise, and it's particularly difficult to combine the two factors
urgency and importance into one priority scale ("Eisenhower Matrix"). So
nobody expects a "perfect" solution. However, every user wants to have
at least a "reasonable" solution and will be happy if the software
provides such a solution, so that as a user you do not need to think
about all the details we need to discuss right now. My complaint is that
the current solution is *not* reasonable, because the date contribution
is linear and thus unlimited, while the other contributions are limited,
and because a task with a due date of tomorrow is considered less
important than a task with no due date. By using a bounded (limited)
function for the date contribution, this could be easily fixed. The
exact shape of the function, whether it is hyperbolic, exponential or
quadratic is not so important. Only two factors should be configurable:
The vertical scale of the function (i.e. the weight of the date
contribution in relation to the other contributions) and the horizontal
scale, (i.e. how quickly the function descends, like over days or over
months). It would be easy to present these with two sliders in a way
that users can understand their effect:

- How large should the due date contribute to priority (0-100%)?
- How quickly should due tasks get priority (days, weeks, months)?

And you could still have an option "treat unset due date as due today,",
though I insist this is not the obvious configuration and should not be
the default.

-- Christoph
Reply all
Reply to author
Forward
0 new messages