[curt.clifton]

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

1. Start-Start
2. Due-Due
3. Start-Start
4. Completion-Start
5. Completion-Due
6. 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]

Originally Posted by curt.clifton

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.

Originally Posted by curt.clifton

"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]

Originally Posted by Paul

"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]

Originally Posted by Paul

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]

Originally Posted by curt.clifton

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]

Originally Posted by Lizard

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.