Repeating Actions Feature - an Experiment?

question
#1

What is the plan for this feature?

It seems so awkward in so many ways:

  • why are they shown as projects, with a project icon, and with “subtasks” for each instance?
  • if you miss a few, then start doing them, why are they still all delivered, and why in reverse order? The more natural way would be to just show the first one, then simply inhibit the repetition until that one has been done. For example, if I missed my Daily Review for a whole week due to illness, why would I do this seven times, and why in reverse order?
  • although I love since dates (historic start dates), and in that sense am happy to see the since date here, why is it shown only for repeating tasks, and why as a part of the task name? The more generic solution would be to show the since date either in the edit pane or/and in a fixed column as discussed in other threads, for all actions. In the above example, I would only need to see the date when I stopped doing my Daily Review, i.e. the since date of the first missed occurrence.
2 Likes
#2

Yeah, at first I was very excited: “Finally, an app that understands I don’t need 5 dailies of the same thing, because by definition, it’s either “do it that day or not””
Then I clicked, and found the “old” one was behind. :frowning:

I’m assuming that’s a bug and not intentional. One of the best things you could do is make it so that when the next occurrence is due, the old one just deletes itself. I can’t imagine anyone wanting a plethora of recurring editions of the same task, for the same reason Folk mentions.

The functionality of a recurring task that actually recognizes that the time has passed and replaces it with the new recurring instance would be, I think, unique among GTD apps and a strong selling point, IMO.

#3

I think what you guys want is the “Periodic” repeating function. It does this exactly. You set it for 1 day and it you complete the action that day, it creates a new one the next day. If you don’t complete it, it just sit’s there, but it won’t make a new one unitl you complete the first one.

I’m very excited about this feature as well. Unfortunately, it’s not quite ready for prime time yet. It’s pretty tricky. But it will be ready soon!

#4

If I may put my @Folke hat on for a minute ( :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: ), I think that’s a mistake from an ease of use standpoint. Most people are going to think of daily as “this happens today or it doesn’t” not “this happens today, and if I don’t do it today, I need to do it TWICE tomorrow.”

Think of it this way. Let’s say I need to get the mail every day. It’s annoying, so I make it part of my GTD list, so I don’t forget to get the mail. I set it up as a daily recurring task, because that’s what I, newbie user, think daily means. Now I forget–damn it!

So the next day, I do get the mail! Yay! I click! Mail captured!
But what the heck? Now I need to do it again to clear it out?

Yes, technically, you can file this sort of activity under “periodic” but I don’t think that’s logical. Periodic is only for those things which are non-crucial–AND don’t depend on recurring timing.

Re-polish my shoes is a periodic task. I want it to show up every 2 weeks after I do it. But if I go 16 days, I don’t want to polish again in 12 days. I want to do it two weeks from the day I did.

Take out the trash to the curb is NOT a periodic task. I need to get it done Wednesday night. It needs to be weekly, on Wednesday, showing up every wednesday and going away if I don’t do my household duty on time.

I hope that makes sense. I’m not sure I’m as good at explaining as some of the people who spend a lot of time thinking about this. It’s not a deal breaker–sure I can go ahead and use periodic to avoid it–but I think in terms of developing an easy-to-use, common sense system, keeping those extra tasks around and having them show back up after the fact is going to cause problems, and might steer people away from what is really shaping up to be an amazing app.

1 Like
#5

Yes, that is exactly what I meant. I don’t know if it needs a special name, though. I imagine this would be the most natural desired behavior for any recurring action.

I know from previous discussions that we also agree on a different and complementary feature that @trebro mentioned - repeat x days after completion (instead of x days after start date, the default). I see no contradiction between these features; they go very well together.

#6

Hi guys,

@trebro, on your thoughts about the non-complete tasks. I may say I feel your pain about It, I also faced the situation when the non-complete past tasks are stacked and I don’t know what to do with them.
So for sure we accept that as a problem we need to solve. And of course we don’t want this problem to steer people away!!! :0

From the other hand I wouldn’t want the item to disappear (be deleted) from the list as it is a kind of counter-intuitive behaviour of the system.

The solution.
We already have a feature that allows to mark the Action as complete and we are also planning to introduce the Cancel action feature. And that (cancelling the action) seems to be the most correct way to ‘de-activate’ the past item.

To automate this behaviour we will add the option in the user settings named “Auto-Cancel past repeating tasks” (or some similar name) that will cancel the repeating task once the new one is generated.

It fixes the problem with the stacked incomplete repeating tasks but also allows to keep the incomplete items for statistical purposes and better user experience.

#7

@sergio

Making it a user option is fine, but I honestly doubt that anyone would ever want the whole list of identical actions or would find it counter-intuitive to have just the relevant one.

What seems to be a more significant point of difference of opinion is whether it is the past repeating tasks that should be deleted when a new one is created or the generation of new ones that should simply be inhibited if an old one already exists. Like @James, I prefer the latter. I need to see the since date of the first occurrence that did not get done.

(Also, a tip: I do not need to gather statistics, and if I did I would not use check-off statistics, anyway. They are highly unreliable as a statistical indicator due to the huge difference in size and complexity of the tasks,)

#8

I too prefer that we have a way to not “stack up” uncompleted repeating items. A switch to auto-cancel them will work fine for me. However, I do think there are many use cases when people need to do something every day and even if they miss a day, they need to go back and complete each item. Example, reports at work. Some people are required to send in a daily report. If they miss Monday, they still need to go back and do Monday’s report. They can’t just “cancel” the report.

Yes, I agree, there are two very different reasons to use the date based repeating tasks versus the periodic. Which is exactly whey we added both!

Thanks for jumping up here and giving some great examples! I can see why so few (if any) other task apps have both. It’s hard to implement!

#9

You are right.

For me, personally, I think it would suffice to just see that my daily report for Monday has not been done, hence most likely not done for the following days either. If I have been ill, I probably have a backlog in many areas. I would set up whatever lists or tasks I need to deal with this backlog. I do not really need a “special feature” for it.

Yes. They are both useful. Date based repetition is far more common, but “periodic”, in the sense of “repeat x days after completion”, is also very useful, especially for things that are of a “maintenance” nature (haircuts, nail cuts, oil filter change …)

Periodic is a trickier feature, because it requires a linkage between the mother task and the specific instance task. Similarly, auto-inhibition or auto-trashing also requires such a linkage. Here is a thought (not a suggestion): if it is always one and the same task that keeps showing up everywhere - no clones - all this is much simpler. That is Toodledo’s approach.

The main disadvantage of the non-cloned Toodledo approach is that if you change something (a comment, a tag, whatever) for the present instance, then these changes are kept for future instances. Therefore, I prefer clones, which allow me to “scribble” or change the comments, subtasks, tags, anything, totally “safely” just only for this instance. But would it be easier for you to implement “after completion” and “auto-inhibit” if for those tasks, but only for those, you took away the “scribble” feature"? In that case, maybe such a mixed approach could be acceptable to many. Don’t know.

Overall, though, I believe most of us usually do our repeating tasks as intended. Clearing things up after a period of illness etc is something we are all capable of dealing with, one way or another. Even clearing away a whole bunch of identical daily tasks from Focus is no big deal, like in Nirvana or Doit, even though I would prefer an auto-inhibit feature. So let us not overthink this. The main focus probably should be on making the normal task management as smooth as possible.

The current “project approach” to repeating tasks strikes me as counter-intuitive and “clumsy”. I prefer to have the subtasks be actual subtasks, not a stack of completed or uncompleted instances.

I find these features useful:

  • regular subtasks (not a list of instances)
  • date based repetition, which you already have
  • periodic repetition (x days after completion)
  • auto-inhibit repetition (if the previous task has not been completed)
  • since date (date of first uncompleted instance)
  • ability to scribble/modify (cloned instances), which you already have
  • always a “next instance” clone available in Scheduled for “scribbling” in advance. Doit spawns the clone one day before and Nirvana and GTDNext only on the scheduled day itself. Ideally, I would like it spawned immediately upon completion of the current instance (or even earlier), for example in order to add notes (subtasks) to my next monthly Pay Bills task for non-standard payments.