Repeating Actions?

[billback]

OK - how do I set up repeating actions? I have the latest version, but can't figure it out. This is one of the hot features for me. TIA.

[AmberV]

First, make sure you have the Repeat Inspector open. It's really hard to miss it in the menu. Next, select a test action with a due date. The Inspector should be pretty self-explanatory. Fixed just means that even if you click it a few days late, it will still calculate the next date from the prior due date, rather than when you clicked it.

[billback]

:)) yeah - guess that was pretty hard to miss. I have a tendency to only look in the menu when I have to. I expected something on the task line. Might be something to look at in the future like the duration and calendar icons - have a repeat icon that I can click to show the inspector.

[Wild Rye]

The repeat icon would be nice in the display, so that you can differentiate a repeating action from a non-repeating action.

Make sure you set a start date on your repeating action, or it will behave strangely!

(Maybe OF should enter a default start date of Today for repeating actions?)

[AmberV]

My preferred way of handling it would be to allow repeat syntax right in the due column. I think I posted something along those lines in another thread. I'd love to be able to type "19 jun +3w" to mean: Do this on the 19th, and then every 3 weeks afterward. Then you don't waste a column, and can do everything with the keyboard.

Addenda: Good point, I think auto-filling the start date the same way it auto-fills it when you check it off would be a good idea, if the field is already blank. Having to fill out three fields is a bit cumbersome.

[billback]

Make sure you set a start date on your repeating action, or it will behave strangely!


Due date works as well instead of a start date.

[AmberV]

It will work once, but if you do not have both entered, the repeating action will consistently come up as a next action. If you have a sequence of actions that all happen after each other, that means the ones below it will never show up in context view. So you need a start date set to earlier in the day, and a due date set to later (though it seems to work fine if they are the same). That way, it will stay inactive until the start date arrives.

[curt.clifton]

I totally do not get how repeating actions are supposed to work.

Say I have an action "Mow the lawn". When I complete this task, I want it to disappear and not reappear on my schedule for 5 days. So I want the Start Date of the new "Mow the lawn" action to be 5 days after the completion of the previous task. (In Gantt charting terms this is a finish-start dependency with a 5 day lag.)

I've been trying to determine the current behavior to see if I can make it work. The gory details are below, but they seem somewhat arbitrary to me. Perhaps this is just because of a bug in the alpha, but it seems like it might also be due to copying a somewhat arbitrary design from kGTD. This posting is my attempt to figure out a less arbitrary approach.

Listing all the possibilities helps me understand the problem:


There are three possible dates from which repeats can be calculated: the start date, due date, or completion date of the original task.

There are two possible dates that can be set for the generated task: the start date and the due date.

Finally there are two approaches to the date calculations: calculate the new start and due dates independently, or calculate just one of the new dates and then set the other to maintain the amount of time between start and due dates. The second option is the only one that maintains consistency over multiple repeats, so seems like the logical choice.


Thus, we have just six possible repeat patterns:


Start-Start: the start date of the new item is calculated from the start date of the original

Start-Due: the due date of the new item is calculated from the start date of the original

Completion-Start: the start date of the new item is calculated from the completion of the original

Completion-Due: the due date of the new item is calculated from the completion of the original

Due-Start: the start date of the new item is calculated from the due date of the original

Due-Due: the due date of the new item is calculated from the due date of the original



Currently fixed repeats with the start date set yield the Start-Start pattern with the wrong due date or else the Start-Due pattern with the wrong start date, since the start and due dates of the new action are the same. Non-fixed repeats yield the Completion-Due pattern with a bug when the start date is set. A fixed repeat with no dates set also uses the Completion-Due pattern, but since the due date is set for subsequent repeats this only happens on the first repeat. Finally a fixed repeat with just the due date set uses the Due-Due pattern.

The Completion-Start pattern, which I want, is not available, nor is the Due-Start pattern.

It seems like the Repeat inspector should have a drop-down list for choosing the repeat pattern instead of just a single "Fixed" checkbox. Something like:

http://www.rose-hulman.edu/~clifton/images/RepeatPatterns.png

Some of these options would be unavailable if a particular date wasn't set on the original action. For example, the Due-Start and Due-Due patterns don't make sense if no due date is set for the original action.

Thoughts?

The Gory Details

First the behavior if the start date (if any) for an action is in the past and the due date (if any) is in the future:

Original: start set, due not set
Repeat: every 5 days, not fixed
Result: Completion-Due with bug, new due date is set to 5 days from today, start date is wrong? (4 days from original start date)

Original: start not set, due not set
Repeat: every 5 days, not fixed
Result: Completion-Due, new due date is set to 5 days from today

Original: start not set, due set
Repeat: every 5 days, not fixed
Result: Completion-Due, new due date is set to 5 days from today

Original: start set, due set
Repeat: every 5 days, not fixed
Result: Completion-Due with bug, new due date is set to 5 days from today, start date is wrong? (4 days from original start date)


Original: start set, due not set
Repeat: every 5 days, fixed
Result: Start-Start or Start-Due with bug, new start and due date are set to 5 days from original start

Original: start not set, due not set
Repeat: every 5 days, fixed
Result: Completion-Due, new due date is set to 5 days from today

Original: start not set, due set
Repeat: every 5 days, fixed
Result: Due-Due, new due date is set to 5 days from original

Original: start set, due set
Repeat: every 5 days, fixed
Result: Start-Start or Start-Due with bug, new start and due date are set to 5 days from original start

There is one case that changes if the the due date is also in the past:

Original: start set, due set
Repeat: every 5 days, fixed
Result: Start-Start or Start-Due with skipped event and due date bug, new start and due date are wrong? (Both are set to SIX days from today or 10 days from original start date. This make some sense if we interpret the fixed occurance has having been missed.)

[kmarkley]

Here's another way to parse the logic for reapeating actions.

There are three meaningful ways that dates can be set for actions: start date only, due date only, or both. (If you set neither the start nor due dates for a repeating action, then I don't believe there is any good way for the software to interpret what you want. So I will ignore this for the moment.)

There are two ways to set a repeat interval: fixed or unfixed.

Thus there are 6 relevant cases, 5 of which I believe should have obvious results and the 6th is somewhat questionable.


Orig Action New Start New Due
------------ ---------- ---------
1. Start/Fixed Start+Int (None)
2. Due/Fixed (None) Due+Int
3. Both/Fixed Start+Int Due+Int
4. Start/Unfixed Comp+Int (None)
5. Due/Unfixed (None) Comp+Int
6. Both/Unfixed Comp+Int Comp+Int+Diff
-OR-
Comp+Int-Diff Comp+Int


Where 'Int' is the interval, 'Comp' is the completion date,
and 'Diff' is the difference between the start and due dates.


Personally, I think the second logic for #6 is preferable, but I suppose it could be argued either way.

Because the Good Omni is working the kinks out, I don't really know if this jives with their intentions or not.

[champ]

Yes, kmarkley. These seem like reasonable updating schemes dependent on the start/due/fixed settings. I agree that the second logic for #6 seems preferable, but it's a tough call, and I think either would be acceptable.

Currently, for fixed repeating intervals and a start date earlier than the due date, OF seems to update both start and due dates to (start + int) when the action is marked completed. That doesn't seem right, since I will now lose my "heads up" for the action to appear on my radar a day or two (or whatever) in advance of the due date. In this case, your number 3 logic should apply, I would think.

[curt.clifton]

Thanks, kmarkley. That's a clean way to look at it. Mapping it back to my classifications your six are:


Start-Start
Due-Due
Start-Start
Completion-Start
Completion-Due
Completion-Start or Completion-Due


Personally I prefer the first logic for #6, perhaps because I'm fixated on my lawn mowing example. (Guess what I should have been doing this evening instead of migrating to OmniFocus!) When I complete my mowing I would like the task to show up in 5 days with a 3 day window to complete it. So I'm thinking of the interval as the time in which I don't have to think about mowing. Logically it doesn't matter since with the second logic I can just set an 8 day interval and get the same result. I guess in case #6 with your first logic the interval is a minimum time between actions and a maximum with your second logic.

Missing from your characterization are

Start-Due, and
Due-Start.

But I haven't thought of a good use for either of those yet, so perhaps it's no loss.

"Fixed" seems a strange name to me, which is part of the reason I proposed a graphical representation of the intervals. In my handrolled GTD system I currently use "Repeat every" to mean fixed and "Repeat after" to mean unfixed. That could be accomplished by adding an every/after drop-down menu to the inspector. I think I prefer the graphical version, but I'm very interested in hearing others thoughts. (Interface design is a professional interest of mine.)

[coconino]

This is all very good stuff and I hope the developers are reading this!

[Paul]

Personally I prefer the first logic for #6, perhaps because I'm fixated on my lawn mowing example. (Guess what I should have been doing this evening instead of migrating to OmniFocus!) When I complete my mowing I would like the task to show up in 5 days with a 3 day window to complete it. So I'm thinking of the interval as the time in which I don't have to think about mowing. Logically it doesn't matter since with the second logic I can just set an 8 day interval and get the same result. I guess in case #6 with your first logic the interval is a minimum time between actions and a maximum with your second logic.
For all the examples that come to mind, I'm more aware of "not wanting to think about that task until ..." rather than "wanting to have that task done again by ...". So I think intuitive interface dictates the first option even if logic doesn't.


"Fixed" seems a strange name to me, which is part of the reason I proposed a graphical representation of the intervals. In my handrolled GTD system I currently use "Repeat every" to mean fixed and "Repeat after" to mean unfixed. That could be accomplished by adding an every/after drop-down menu to the inspector. I think I prefer the graphical version, but I'm very interested in hearing others thoughts. (Interface design is a professional interest of mine.)
"Fixed" is an obstacle to understanding. For me, 'repeat every' and 'repeat after' aren't clear enough for a competent but not fluent non-native speaker. I hope other people can suggest something even better to mark this distinction.

[LizPf]

"Fixed" is an obstacle to understanding. For me, 'repeat every' and 'repeat after' aren't clear enough for a competent but not fluent non-native speaker. I hope other people can suggest something even better to mark this distinction.

I don't care for "fixed" either, though it does make sense to me ... fixed date vs. floating date.

I find my repeating tasks come in two clear varieties:

1. Do this every Friday (put trash out for collection); I don't want to see this except on Friday, even if I miss a day. This is a fixed date: every Friday, or the 1st of the month, etc.;

B. Do task, then again 6 weeks after I did it the last time. So, whenever I cut my son's hair, I need to be reminded to do it again 6 weeks later. This floats.

Ethan used "repeat" and "recur" in KGTD, and I can't tell you which term meant which type of repeat. "Every" and "after" are also unclear to me. Fixed and floating work for me. I can't think of anything better, though.

--Liz

[Craig]

For me, 'repeat every' and 'repeat after' aren't clear enough for a competent but not fluent non-native speaker.

Perhaps, but I prefer them to "reset" and "recur." Those are two pieces of kGTD that I hope don't appear in OF - for some reason I could never keep them straight.

[curt.clifton]

The new repeat inspector is a significant improvement. I only see one significant problem with it.

What does "Repeat every 2 days after due date" mean for an action with a start date but no due date?

I think it should mean "Repeat every 2 days after start date". But I can't think of a use case for such a Start-Start dependency, so maybe the "after due date" option should be grayed out when an action with no due date is selected.

Does anyone have an example where you would want an action to repeat a fixed number of days after its start date, but without having a due date?

[kmarkley]

Does anyone have an example where you would want an action to repeat a fixed number of days after its start date, but without having a due date?
I have to file weekly expense reports. They are not actually due on a prticular date because they are just for auditing purposes. So it doesn't matter if I occaisionally (or even frequently) fall a couple weeks behind. But eventually I will need to have a report on file for each week.

So if I have an action with a start date of Monday the 1st, and I check it off Wednesday the 3rd, the next (repeat) action should have a start date of Monday the 8th because it is not actionable until then. Similarly, if I don't do the first report until Wednesday the 10th, the next (repeat) action should still have a start date of Monday the 8th and therefore immediately appear as available.

Also, there are innumerable examples where I would want a new task generated with a start date a fixed number of days after the completion date. The inspector is would seem to allow this, but the logic is still not working.

[BwanaZulia]

I like the addition of the new repeats, but it is not picking up any of the settings from Kinkless.

BZ

[Lizard]

We've worked on repeating tasks some more since your discussion. Anyone have feedback on the current behavior and/or interface?

[kmarkley]

We've worked on repeating tasks some more since your discussion. Anyone have feedback on the current behavior and/or interface?
Yes, thank you for asking. They now work exactly as I would expect, including for action groups. Still doesn't seem to work at all on the project level, but suspect that is still to come.

[LizPf]

The interface is nice and clear to me.

--Liz

[curt.clifton]

Repeating actions work fairly well for me now also. Still waiting for repeating projects.

Two things that occasionally trip me up:

Repeat ... from assigned date. At one point this was "Repeat ... from due date," which didn't make sense when an action had a start date but no due date. The new wording is better, but I have to remind myself that "assigned date" means due date unless no due date is present. It would be nice to have some indication of when the next repeat would be. I'm thinking of a little area in the inspector that says something like:

Next occurrence:
Start: April 1, 2008
Due: April 15, 2008

If the next occurrence would not have a start date then it would say "none", and similarly for due date. I'm not sure how that area should behave when the repeat is based on completion date.
Whole days. When I have an item that repeats in n days/weeks/months/years from completion, the repeat is set for the exact time of completion on the correct day. I would prefer that such "long stride" repeats be set to 12:00 am on the correct day. Otherwise during my morning review I fail to see tasks that start later in the day.

[johnrover]

Whole days. When I have an item that repeats in n days/weeks/months/years from completion, the repeat is set for the exact time of completion on the correct day. I would prefer that such "long stride" repeats be set to 12:00 am on the correct day. Otherwise during my morning review I fail to see tasks that start later in the day. [/LIST]


Yes. I agree. I have a morning to do list that repeats daily based on completion. (Sometimes I get to it, sometimes I don't.) If I don't get to some things on the list until that night, I still want them to pop back up as available tomorrow morning.

When I see daily repeating, I assume it means calendar daily, not 24 hours.

[Lizard]

johnrover -- daily tasks like that might be better set to repeating based on assigned date. Assign them to start at 12 am and repeat daily. As soon as you get up in the morning, they'll be there waiting for you. And regardless of when you check them off during the day, the next ones will start at 12 am again.