Change due date without change next due date

[kapamalo]

I can accept that in OF, due dates have one use and one use only. However, that does not preclude that it could be otherwise. No harm in discussing the mechanics, methodology, and possibilities, right? Can’t grow and improve if you don’t question the status quo. We’re all here to learn from each other.

In my Outlook calendar, I have dozens of hard deadlines. Almost all of them work seamlessly all the time, because Outlook has an extensive array of recurrence options, particularly for monthly tasks: “third Thursday of the month”; “first weekday of the month”; “last day of the month”. None of my due dates fit into the simplistic “every 15th of the month” because sometimes the 15th is on a weekend, and sometimes not. So that option is useless to me. But, even if it was useful to me, Outlook gives an easy, breasy workaround for the weekend issue. If I schedule a due date for every 15th of every month (let’s say when my monthly report is due to my director), and I see that one falls on a weekend, I just drag it over to Friday the 14th, confirm I only want to change the one task and not all recurring tasks, and done. All my future recurring due dates remain on the 15th. The 15th is a very hard deadline every month (still within the OF definition of a hard deadline), except when it falls on a weekend.

Compared to programs such as Outlook and Fastastical, setting and maintaining recurring events and tasks in OF is pretty clunky and, for beginners, pretty unpredictable. Throw in Project due dates, and you’re getting into deep, disturbing waters (As a beginner, mind you. I got the hang of it eventually, after many instances of shouting, “Why the heck is this task still in my “Past Due” list when I’ve marked it complete and it clearly has a new due date and a new defer date in the future???”).’’

The basis of GTD is to have a reliable and predictable system you can trust, and I think for most people there is a threshold of complexity where an inverse relationship starts to form between complexity and predictability. Adding a feature that allows you to change one instance of a recurring task without changing all instances seems to me to be significantly less complex (and more reliable) than forcing users to create “meta-tasks” to remind themselves to set a reminder. If no other options existed, I would welcome these types of “mini-meta-tasks”. But when so many examples exist of easier, more reliable recurrence options, it’s hard not to see it as a duplication of effort.

Good discussion (minus the quite unnecessary and somewhat rude dismissals of constructive questions, scenarios, and explorations).

[Hal9K]

• 1
  Has been said many times and I welcome each. Would love this.

[PGR]

Adding a feature that allows you to change one instance of a recurring task without changing all instances seems to me to be significantly less complex (and more reliable) than forcing users to create “meta-tasks” to remind themselves to set a reminder.

I’m struggling to understand this one a bit, I have to admit.

You say that:

Outlook gives an easy, breasy workaround for the weekend issue. If I schedule a due date for every 15th of every month (let’s say when my monthly report is due to my director), and I see that one falls on a weekend, I just drag it over to Friday the 14th, confirm I only want to change the one task and not all recurring tasks, and done. All my future recurring due dates remain on the 15th.

What this seems to mean is that, every month, you would have to check your current month’s task, which is known to be on the 15th, to see if it falls on the last working day on or before the 15th. If it doesn’t, you move it so that it does.

With the OF behavior, it means that, every month, you would have to check your current month’s task, which may or may not be on the 15th, to see if it falls on the last working day on or before the 15th, If it doesn’t, you move it so that it does.

How is one of these ways “easy, breasy” and the other isn’t? They seem essentially identical. Why would you need a “meta-task” for the second way, but not for the first way, when you’re doing essentially the same thing?

You say that:

for most people there is a threshold of complexity where an inverse relationship starts to form between complexity and predictability

and I agree, but I think for most people that threshold is passed the moment you start trying to build an automated system that tries to calculate all these complex deadlines all by itself for you to just follow. For example, what if your report gets automatically moved back to the 13th, because the 15th falls on a Sunday, and now conflicts with another deadline that actually does properly fall on the 13th, and you don’t have time for both? What if the 15th falls on a Monday, but it’s a holiday, and your task is actually due on the 12th? What if that Monday is a holiday, but your director is on a different continent, and you or your company don’t take that day as a holiday, and so it’s really due on the 15th after all. How is any automated system possibly going to be able to take account of all this?

In any case, you’re going to have to look at all your deadlines for a particular period of time, regularly, to make sure you know what’s coming up and that you are able to accommodate everything. You won’t need “meta-tasks” if you do this, because you’ll just be on top of your calendar in the normal course of events. I think trying to delegate this to an automated system which will figure it all out for you will, in principle, only ever increase complexity and reduce both predictability and trust.

I don’t object to more flexible repeat options, but I do challenge the assertion that this will reduce complexity or increase trust. In all cases, you’re going to need to manually look at all your upcoming deadlines and think about them, or you’re sometimes going to make mistakes.

[kapamalo]

These are really good points. I see the impact of having the “meta-task” to remind me to ensure I’m putting my deadline in the right place. To me, that “meta-task” is a regular review of my upcoming week. When I’m doing this meta-task, however, I’d like setting the due date to be as easy as possible. If I know that 95% of the time the deadline is on the 15th, I’'d like to set a recurring deadline on the 15th. Then, on the rare cases there is an exception, I simply move that one instance.

With the OF behavior, it means that, every month, you would have to check your current month’s task, which may or may not be on the 15th, to see if it falls on the last working day on or before the 15th, If it doesn’t, you move it so that it does.

The difference is that when you change one instance of the recurring task/event in Outlook, you’re asked if you only want to change that instance, or all instances. In OF, if you change one instance, all instances are automatically changed, without giving you the option. It’s about setting rules and managing exceptions, rather than repeating a task (creating a separate task and setting a separate due date) every single time.

[PGR]

I’d like setting the due date to be as easy as possible. If I know that 95% of the time the deadline is on the 15th, I’'d like to set a recurring deadline on the 15th. Then, on the rare cases there is an exception, I simply move that one instance.

It’s going to be similar either way. If it’s not the 15th for just one month each year, for example, then with Outlook you’d change it one month a year, and leave it alone 11 months a year. With the OF behavior, you’d change it that same one month, then the next month you’d change it back to the 15th, and then it would repeat happily on the 15th again for the next ten months without intervention. So you’d change it two months a year, and leave it alone10 months a year.

In terms of reducing the number of clicks or keystrokes, I grant you it’s more than absolutely nothing, but it’s not very much more. You’re already checking each month in both cases, therefore there’s no saving in terms of thinking time or effort, so the cost saving is limited to, maybe, 5 seconds a year to change it once, instead of 10 seconds a year to change it twice. Is this saving really worth the added complexity of having to think about, for every single task, the potential for the due date to be different from the repeat date?

Maybe it is worth it to you, and in any case, we’re only here talking about one specific potential use case, so I’m not trying to pass judgment either way, and again, I don’t object to more flexible repeat dates in OF. I’m just challenging the original suggestion that the absence of this feature is leading to some kind of significant additional complexity or work, and I don’t think it is, and I actually think the opposite is more likely to be true.

[kapamalo]

Yes, PGR, I see what you mean. I appreciate you taking the time to flesh this out. Based on this conversation, I’m going to take a look at my workflow and see if I can incorporate a little less reliance on complex recurring tasks, and instead focus to a greater extent on using my review tasks to ensure the due dates are in the right place. Very grateful for the thoughtful responses.