One of the fundamental concepts used in OmniFocus is that of "Next Action." Each project has a Next Action, and it is the very next task you have to get done in order to keep that project moving. Being able to focus on such Next Actions is tremendously helpful for managing a large number of projects without losing track of what literally needs to be done next. Due to a curious problem with the way OmniFocus determines what a project's Next Action should be, however, you may overlook some tasks without even noticing that they are being hidden from your view.
Let's assume that, as part of your backup regime, you regularly create an off-site backup using two external hard drives, one of which you keep in your house while the other is safely stashed away off-site. Once a month, you clone your Mac's hard drive to the external drive in your home and rotate the two drives between your home and the off-site location. (For more on hard drive cloning and other backup suggestions, see Best Practices for Personal Backups).
To help you ensure that you stick to this monthly routine, you create a project in OmniFocus that may look like this:
By configuring the project to repeat every month, you have captured a basic backup schedule in OmniFocus, and it works just fine: as you check off the actions one by one, a Next Action is properly defined and appears as such -- the purple text color indicates a Next Action -- in Context view.
As soon as you decide to repeat a project's actions with different time intervals, however, OmniFocus fails rather miserably at deciding what the Next Action should be.
When the Next Action isn't really the next action
Let's go back to the backup example: to further improve your precious data's safety, you decide to not just clone the hard drive right before taking the external disk off-site, but you'd rather create a clone once a week. The project may look like the one shown below, with the cloning action's due date set to "this Friday" -- in fact, literally typing "this friday" in the date field will enter the date of the upcoming Friday -- and repeated weekely and the disk rotating action set to be due by the last Friday of the month and repeated monthly.
Now look what happens when you check off that cloning action: even when that action's due date moves beyond the due date of the other two actions, it remains top-most and, consequently, also remains the Next Action for the project. That's because OmniFocus generally considers the project's action that is top-most in Planning View to be the project's Next Action, regardless of any due dates. Which leads to a serious problem.
In the screenshots above, you can see my favorite setting for OmniFocus's Context View, which is to have only those actions shown whose status is Next Action, and display them ungrouped, but sorted by due date. That way, I can easily focus on what I have to do next without missing any actions that are due soon.
In my humble opinion, this ability to only focus on what needs to be done next and removing all other projects details from your field of vision is the most helpful aspect of the Getting Things Done methodology, which OmniFocus is based on, for keeping each of my projects moving (as long as I can overcome my stupendously annoying Post-Breakfast Procrastination Disorder for a given day, that is...).
When working inside this specific Context view, though, the two "take that clone drive to the bank and bring back the other one" actions will never show up, because OmniFocus never assigns them Next Action status.
View it all or risk missing something
There is a work-around, which is to choose a different setting for the Context View's status filter. For parallel projects, "Available" would suffice to show inadvertently hidden actions, but for sequential projects, you'd have to set the filter to "Remaining." Then again, since no-one wants to keep double-checking a project's type just to ensure that no actions go unnoticed, "Remaining" is the only truly trustworthy option here, but it has a severe side effect: the view will now show all remaining actions for all projects for the selected context. "Goodbye, trusty Action-Focus, you were a real friend. Fare thee well!"
Put less dramatically, having to keep all remaining actions for any given context on-screen because that's the only surefire way to avoid missing any actions, is a major blow to what this application promises to deliver: focus.
Fundamental flaws need a fundamental fix
When I first noticed this behavior, I wondered whether OmniFocus would benefit from a new type of project which, as the only difference from the current behavior, would sort its actions by their due date. But the more I've been musing on this, the more I am convinced that OmniFocus's current way of dealing with repeated due-dated actions is flat-out wrong.
How should the good folks at the Omni group modify OmniFocus, then? Here's a suggestion: whenever a repeated action is re-created after it's been checked off, it should be sorted into the list of remaining actions inside its project based on that due date. That way, any non-repeating actions will not change their position in the project, and non-repeating projects are not resorted at all.
This slight change in OmniFocus's behavior would ensure that no action goes unnoticed, which I consider an essential "feature" in any task management system. What's more, I can't imagine any problems this sorting would cause, which could not be fixed by using action grouping.
To round off this modification, OmniFocus should present a warning message whenever a project contains both non-repeated actions without a due date, and repeated actions. That's because OmniFocus considers an empty due date to mean "sometime very, very far into the future, in fact, so far into the future that any specified due dates come before it," so that it would be these actions -- non-repeating and with no due date -- that would never show up in the Next Actions in Context view...
What's your view on this: have you run into this issue? Have you found a feasible work-around that I've missed? And how would you change OmniFocus's way of deciding on the Next Action?
Update Here's a follow-up post with more info on the work-arounds contributed in the comments below, plus some good news from the OmniFocus developers.
Categories
Mac
Comments (12)
Read More Entries by Jochen Wolters.
Rob:
Thanks for your comment.
Using a "Single Actions" project type is another valid workaround, but it does share some of the limitations found in lucas's suggestion about using Start Dates.
What's more, a future release of OmniFocus will have an option to sort repeating projects by due-date, so that should solve this problem for good.
See the follow-up post for more on this.
Apologies if I missed something or am repeating something already said...
Can you not just make the project a singleton (blue bucket)?
Actions not yet due will be greyed out; actions due will not block each other - they will all be next actions.
Hope that helps.
Thanks for your extensive comment, lucas. I'll address it -- and a few other things -- in a follow-up blog post next Tuesday, which, by the way, will also include some interesting news from the OmniFocus developers.
Joshen,
Using start dates seems to work as long as a) the project is of the parallel type and b) the start dates are set so that actions' time frames don't overlap. Which approach basically does not qualify for being called "usable" either: too much hassle, too many limitations.
It may be that, for some cases, the OF scheme has "too much hassle, too many limitations", but certainly not in this case. You want to have the Next Actions that OF provides, in order, be clone the drive (repeating weekly), bring it to the vault (repeating monthly), bring back the other drive (repeating monthly). All you have to do is put those three actions in OF, in that order, with start dates on each and have them repeat by a month or week as applicable. Right - they do have to be in a parallel project, but who cares if the others are Available in a parallel project? You did tell me that you were limiting context view to Next Actions. Oh ps. they are not confined to parallel projects; just set them in a parallel action group in a sequential project, and the Next Action will skip over them if none of them have come to their start date.
I sense that the problem is that OF just goes down the order of available actions when setting Next Actions and not according to the next one that has a due date. I think that the OF scheme is actually much better in a practical sense though. In this case, let's say that you just dropped the ball on bringing your backup to the bank for a whole week. In that case, now you're overdue on depositing the backup and coming due for making a new backup. If you followed your scheme of looking for the oldest due date, the Next Action would be marked as depositing your backups, instead of making this week's backups first and then bringing all of them to the bank at the same time. QED.
I couldn't figure out what you meant by "the action's time frames don't overlap" or how you would cause a problem with that, but it seems like the paragraph above might have something to do with it. In any case, if it were me, I would take off the due dates. On the other hand, I don't want to imply that if you want to have due dates that OF won't accommodate that, because I couldn't figure out how the time frame overlapping causes a problem.
Even worse, a group is not checked off automatically as soon as all actions inside that group have been checked off.
I understand the reasoning to be that you might not think of every single thing that has to be done to complete the action group's goal and may need one last look before OF moves on. I know that is not everyone's preference but I really don't think it's "too much hassle, too many limitations" either.
Matt:
In any project, a task is required to be completed before you can move on to the next task, but if you have that task repeated, then you have an infinite loop. The project can never be completed. The project can never be completed. As far as I can see, you should never assign tasks as repeating events. Is there some way to make them useful that I can't see?
You can mark the project as completed, or the containing action group of the repeating item as completed.
(Also, when you complete a repeating task without a due date, one is assigned to it after it is completed the first time. That didn't work for me as a work-around.)
Try setting your repeating task with a start date and no due date.
To make daily, weekly, monthly checklists, etc. ... you pretty much have to group things together and only tell the group to repeat.
Or you can mix them with individual repeating periods, but you want to repeat on their start dates, as above.
Matt:
"To make daily, weekly, monthly checklists, etc. ... you pretty much have to group things together and only tell the group to repeat."
Trying unsuccessfully to create a weekly check list was the very motivation for me to write this blog post.
After experimenting with a few ideas, including lucas's suggestions, I still have not found a usable work-around for the way OmniFocus handles repeating actions. Using start dates seems to work as long as a) the project is of the parallel type and b) the start dates are set so that actions' time frames don't overlap. Which approach basically does not qualify for being called "usable" either: too much hassle, too many limitations.
"Also, you cannot check off the group until all the tasks are checked off."
Even worse, a group is not checked off automatically as soon as all actions inside that group have been checked off.
Having to explicitly check off projects does make sense, as you would do that during the weekly reviews to mark them as properly completed. But groups, in contrast, are for logically grouping tasks together, much like a folder is used for logically grouping files. And just like a folder does not itself constitute a file containing data like a text or an image, an action group should not itself constitute an action. Come to think of it, I don't think an action group should have a check mark to begin with.
As I mentioned in an earlier comment, I'll keep digging into this and post a follow-up as soon as I find out more.
[removed duplicate post]
I just started using OF today, and I am trying to create a daily checklist for work.
However...
In any project, a task is required to be completed before you can move on to the next task, but if you have that task repeated, then you have an infinite loop. The project can never be completed. As far as I can see, you should never assign tasks as repeating events. Is there some way to make them useful that I can't see?
(Also, when you complete a repeating task without a due date, one is assigned to it after it is completed the first time. That didn't work for me as a work-around.)
To make daily, weekly, monthly checklists, etc. ... you pretty much have to group things together and only tell the group to repeat. For example, put all daily tasks in a group called 'Daily' and all weekly tasks in a group called 'Weekly', then only assign the due date and repeat to the group and not the individual tasks. Also, you cannot check off the group until all the tasks are checked off.
This is the only way I can find to make daily, weekly, monthly checklists in OF. Maybe it would be nice if they made two categories, 'Projects' and 'Repeating Checklists' because projects don't really seemed to be intended for infinitely repeating daily lists. They seemed to be intended to be completed always.
Anyways... those are my thoughts and first impressions. Please let me know if there is something I have overlooked that would help me use OF for a daily checklist.
Thanks!
Matt
Work-around, no. It's how it is designed to work.
Thank you for your suggestions, Lucas, and thank you, Macdork, for chiming in with that spot-on clarification. ;)
Grouping actions does not solve the problem, but it seems as though using start dates might provide a work-around. I'm currently playing around with this approach and will share what I'll find in a future blog post.
Fair enough. Then use repeating start dates instead of end dates. Done and done.
@lucas -- I think you missed a minor detail from the second example.
In the second example, there's a shorter repeat-period for the first action (one week), where every other action is a month.
Set the due date and the repeat on an action group, not on the individual actions.
Done.