Recurring date survey and discussion

[Erica]

It’s finally time to work on recurring dates, yay!

But before we can jump into it, we want to make sure we’ve heard everyone, so that we can build that something that’s useful for the majority of you guys.

Here are two polls that we hope everyone interested can complete. Feel free to comment too, we’ll read every comment.

What’s your primary use case of recurring dates?

• I want to see them as recurring dates and remind myself
• I want to see them on Google Calendar with the integration enabled
• I want to see them when do use search filters like “within:7d”
• I want to make dates automatically change to the next occurrences when I complete them
• Other (please leave a comment)

What would you expect to happen when you complete an item with a recurring date?

• Nothing
• A new instance appears and the new instance has the date set to the next date (from the due date)
• A new instance appears and the new instance has the date set to the next date (from the completion date)
• The item gets modified and the date is set to the next date (from the due date)
• The item gets modified and the date is set to the next date (from the completion date)
• Other (please leave a comment)

[pottster]

The problem here is that there are different use cases for each of the options and at different times you might want different behaviour. I’m not currently using Dynalist for To-Do list management because of this type of complex requirement. If it helps, I’ve attached a screenshot of the dialog in my To-Do list manager giving the task recurrence options. These were arrived at after a LOT of discussion but met most user requirements.

[Erica]

Nice, thank you for the screenshots!

May I know the name of this particular todo list manager?

[pottster]

Sure, it’s MyLifeOrganized. https://www.mylifeorganized.net/

[Kevin_Murray]

For me, the ideal model would be Todoist (though I had previously used MLO like @pottster, but it critically lacks a web version). This offers the option to make it recurring by date of completion or due date. And, nicely, you can postpone a task while leaving its due date unaffected. It also has a filter to only show today’s due tasks yet to be completed. Ideally, I would like completed day’s tasks to disappear until they are due again. This is possible in the PowerPack of @Piotr but it is not yet integrated into Dynalist.
Of course, neither Todoist or MLO have anything like the organisational capacity of Dynalist. But it would be great, one day, not to need them.

[Erica]

Do you choose whether you want to make it recurring by date of completion or by due date for every date? Or do you have a default setting and override on a per date basis?

[Kevin_Murray]

That’s determined on an item-basis, rather than for each date, if understand your question correctly.

You can create a recurring task that repeats at regular intervals from either the original task date or from the task’s completed date by using every or every! .
https://get.todoist.help/hc/en-us/articles/360000636289

[pottster]

I forgot to mention. Another aspect of recurring tasks is a facility to skip an occurrence. I wouldn’t say I am entirely happy with how this is handled in MLO but here is the dialog…

[Mark_Eichenlaub]

I currently use reminders in Gmail, so I want them to basically replicate that.

I would also like it to be pretty easy to get a record of how often I completed a recurring task. e.g. if I had a recurring task for “brush your teeth” and the dentist asked how often I brushed my teeth, I could easily look it up and tell them (assuming I completed the task in Dynalist whenever I did in the real world).

[Chris_Kunicki]

First, I just want to thank you for starting to explore this feature and including your users in the process. The recurring date feature will provide Dynalist with a crucial component to making it a time management tool. So thank you.

I would add that recurring dates (or tasks) are a very well established field and its good the wheel does not need to be reinvented for recurring tasks. I like other users in this forum used MLO and loved it (but no web version, so bye bye). MLO though has one of the most advanced repeating engines. So if that was implemented, it would be well beyond our imagination and the needs of the average user. So it might be overkill.

Another very solid repeating task solution is found in Outlook. While I dislike Outlook tasks, the repeating feature is reasonably robust. So this would be probably less powerful than MLO, but still very powerful.

Another user mentioned Todist, and that might be the best model to folllow as the “common denominator” that covers most use scenarios.

For me, recurring tasks fall into a few categories:

1. a task repeats on a time based interval (example: repeat this item once a month, or every two weeks and so on).
2. a task may repeat on certain days of the week (Example: a task that has to be performed Tuesdays and Thursdays).
3. Tasks that begin at the beginning of a month or at the end of the month.

Another simple but flexible solution is the Trello “Repeater” powrup. It provides simple repeating cards. You define the card template, how often it should repeat and where the card should appear when its generated. This has also proved to be a slick way to generate repetive tasks.

I would add, I already do repeating tasks in Dynalist. I have a place where I have all my recurring tasks defined, and then once a week when I do a weekly review of my schedule (GTD old school), I duplicate the repetitive task and set the date for the task on the duplicate. In the end it works well.

Which brings me to a last point. It would be useful considering the dynamic nature of dynalist, if I could define a repetive task, but also define where it appears (example, to define in which node, like the Inbox, that the recurring task should be generated.) the problem with dynalist and many documents, you might have repetive tasks being generated, but then you have to go look for them. If we can define where they are generated (or spawned), this would probably help manage the possible chaos of many tasks being generated from many diffferent places.

Warm regards,
Chris

[Alan]

@Chris_Kunicki

if I could define a repetive task, but also define where it appears (example, to define in which node, like the Inbox, that the recurring task should be generated.)

The one single feature I’ve been seeking for ages in mobile is simply to copy a task. Though not based on dates. If this repeat feature could solve my problem i woukd be happy.

[Yatharth_Agarwal]

Whatever we decide, hopefully it looks as simple and textual as !(21 Nov 2018 every wednesday) or !(01/01/18 every four days after completion)!

Although I initially voted for it, modifying the task doesn’t make too much sense: If you hit complete, then the task would have to be uncompleted to be useful, and that’s weird. Generating another item right below would make more sense.

[Alan]

@Yatharth_Agarwal

Whatever we decide, hopefully it looks as simple and textual as !(21 Nov 2018 every wednesday) or !(01/01/18 every four days after completion) !

Seems sensible. Now if you mark it off do you get

Bob !(01/01/18 repeat every four days after completion)
[ ] Bob !(01/01/22 repeat every four days after completion)

Or

Bob !(01/01/18).
[ ] Bob !(01/01/22 repeat every four days after completion

Or some other scheme?

[Aaron]

I chose for the second question “A new instance appears and the new instance has the date set to the next date (from the completion date)” but I’d like the option of both from the completion date OR from the due date.

The best UI I’ve seen for creating recurring tasks is in the Tasks app for Android (previously known as Astrid Tasks).

It packs all of the essential options into just three lines (due date/time, repeat by X Y, repeat type):

Video demo (really helpful to see the extent of “repeat by X Y”)

[Yatharth_Agarwal]

@Alan

Seems sensible. Now if you mark it off do you get

Bob !(01/01/18 repeat every four days after completion)
Bob !(01/01/22 repeat every four days after completion)

Or

Bob !(01/01/18) .
Bob !(01/01/22 repeat every four days after completion

Interesting question! I think the pertinent question is: What do we want to happen if we uncomplete the task? I like the ability to undo an accidental completion, so that would imply leaving the recurring part in.

[Erica]

@Yatharth_Agarwal

Although I initially voted for it, modifying the task doesn’t make too much sense: If you hit complete, then the task would have to be uncompleted to be useful, and that’s weird. Generating another item right below would make more sense.

Yeah, modifying itself would be weird and unsatisfying (I did work but nothing was checked off!).

The biggest problem I see with adding a new instance is that some people might think that makes the document too crowded. Right now 54% of people voted for having a new instance, so I guess that’s not too big of an issue.

[KC]

I use “is:completed -edited:3m” to remove completed task older than 3 months, so too crowded is not a big problem for me. But what happen if a task have two different days (sometime I put start and due date in a task)? I hope it will automatically choose the recurrent/due day when completed. Thanks.

[Erica]

If you make one date recurrent and the other non-recurrent (i.e. a normal date), I don’t think that would be a problem.

[Kevin_Murray]

I’m curious to know how you purge the completed tasks. If you select all, it seems to include the top nodes which are uncompleted, which naturally you don’t want to delete. Doing it branch by branch is quite a lot of work.