The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > Applying OmniFocus
FAQ Members List Calendar Search Today's Posts Mark Forums Read

One more time "Waiting For" / "On Hold" Thread Tools Search this Thread Display Modes

i currently switched back from toodledo to OF. quite some time has passed since i used OF and therefore some questions came up.

it is mainly regarding the treatment of waiting fors. OF can set a context to on hold and it it said that this is the intended function for waiting fors. it may be that i am missing something but i cant find any reason why the "waiting for" context should be set to on hold? perhaps someone can explain to me.

in my opinion the setting to on hold does not make sense, because i don't see WF tasks any more. i have to switch to the remaining status filter to see the tasks. this results in seeing tasks that are probably not relevant in the moment (for example in an sequential project). from a filter perspective this is ok. in fact the task is remaining in the project. but it is not relevant just now.

it would be kind if someone could post me the intended usage of the on hold function especially when using sequential projects. i really like to know if there are any new ways to fine tune my GTD implementation.

You can set a "Waiting For" context to be on hold, but it is not necessary to do so -- very much a matter of personal preference!

If you don't like the behavior you get with contexts that are on hold, try it the other way (waiting contexts not on hold) and see if you prefer it that way. You trade off being able to see those actions in a normal "available" view against not having actions which are not actionable for you hidden, though you can possibly use start dates to hide them. If you like to see the actions that are blocking further progress, don't put the waiting context on hold.
First off all thanks for the reply.

i know it is mainly because of personal preference but i like to know the inteded implementation / workflow when setting a waiting for context to on hold. perhalpes someone can outline the working process a bit.

i can tell what i do. as the GTD methodology states, when i process my stuff i decide on the next action. if the desired outcome is not achieved with this action, i create a project an attach the action to this project. let´s say this is a call. when i did the call i want to track that the called person has to come beck to me with some results. i track this "task" by creating it, associating it to the project and then assotiating it the Waiting For context. when in "doing"-mode i can look at my WF list to see "real" WFs and assess them if i have to light a fire or something. when using the parallel project function i can plan the two actions (the call and the resulting WF) in planning mode. when i finish the call, the WF gehts available and is displayed in the WF context (assuming that the filter is set to available). this seems to me the described process of GTD.

now when i think of setting the WF context to on hold i cant imaginge a "working" process. the WF would never show up in contect mode. so i can't review this list to check if i have to light i fire,etc. the task is only seen, when i set the status filter to remaining but by filtering this way i see all tasks "planned" in the several projects. event those that are not relevant right now. regarding the example above i would see the WF without having called (completed the task before). so the resulting view will not support my review very effectively.

perhapes i miss something. is there another way to implement the GTD Workflow by using On Hold? what confuses me is, that Oh Hold for Context is the intended method for implementing WF. But i just can't see how this should work. setting the context not to on hold seems more "natural". and because it´s the intended method i would like to know the process how to do it that way.

maybe someone can help.

Best Regards
I think that a Waiting For task would logically be on hold if it's not your responsibility to get the project moving again.

For example, maybe your boss asked you to prepare a document and you gave him the first draft. You know that eventually he'll get back to you with changes, but you know from experience that he'll get back to you when he gets back to you, and that nagging him is just going to annoy him. So you put the "Waiting For" action in the project as a placeholder to tell you why that project isn't in progress, but it's not your job to get the project moving again - it will move when your boss gets back to you.

This is the only kind of thing that I use Waiting For for. If it's _my_ responsibility to get the project moving, I instead create a "follow up" action with a future start date.


Edited to add: You could also reasonably use an On Hold Waiting For action if you have complete confidence that you'll evaluate and perhaps change that On Hold status in a timely manner, for example in your weekly review. That way, it's out of your way during your everyday work, but you know that you'll activate it before it gets too stale. I don't have that complete confidence.

Last edited by Gardener2; 2010-03-17 at 07:55 PM..
Hello Gardener2,

thanks for the clarification. now i can see a little clearer. your first example shows a possible usage of the on hold context.

but let me ask one more question. how do you review these on hold (waiting for) actions? are you only doing this in project mode seeing the compete inventory of a projects tasks? i am aking because i still see the issue i mentioned above. if you use a sequential project and plan it with a WF task depending on another task. when wouo then switch to context mode you first dont see the task. you have to switch the filter to remaining. then you see the task but principally this task is not due now because the depending task has not been completed. so this view is useless. especially when you have a large volume of tasks.

so reflecting on the thoughts above, you can only see the tasks associated to an on hold context (WF) in project mode in a usefull manner. here you have additional information to evaluate the task against its context (the project). does this hit the point? however, i think this functionality could work in the situation you described.

thanks and best regards
Originally Posted by offline81 View Post
but let me ask one more question. how do you review these on hold (waiting for) actions? are you only doing this in project mode seeing the compete inventory of a projects tasks? i am aking because i still see the issue i mentioned above. if you use a sequential project and plan it with a WF task depending on another task.
When I use an On Hold Waiting For context, the Waiting For action is usually the Next Action for the project, and it will hold the whole project up, and it will hide the whole project and all of its subsequent tasks from me in my normal Context view. But that's what I want to happen - that's what I use Waiting For for, because I only use it when restarting the project is entirely someone else's problem.

I will see the project and the Waiting For action when I do a full review, because I do view Remaining tasks then, not just Available tasks. But I'll generally just glance at it and move on, because, again, I don't care about getting that project moving. In fact, I may use the review frequency feature to request a project review less often than once a week.

When I _do_ care about getting a project moving, I don't use Waiting For or On Hold at all. I instead create a "follow up" action with a future start date, and usually a Context of Agenda or Email, to get the project out of my view for a few days. If I get my response before the days are up, I go to Project view and check off the task, which makes the project visible again. If I don't get it, the "Follow up" task reappears, and I can choose to either follow up, or defer it again.

So in both cases I am hiding the project, either indefinitely or for a specific amount of time. But that's what I want - if there's nothing actionable on the project, I _want_ it to disappear.

Actually, there's another place where I do frequently use something like an On Hold Waiting For - when a project is dependent on another project.

So, let's say that I'm writing a better set of, oh, zip code lookup code. I want to install this code in every application in which I have zip code lookups. It's going to require a little customization for each application.

So that's a bunch of projects -

Write Zipcode Engine
Install Zipcode Engine Into Widget Application
Install Zipcode Engine Into Gadget Application

and so on. Until I complete the first project, I can't even start on the other projects, so I want them to be on hold and usually hidden from me. But I do create the projects, because I might have thoughts about them ("Configure Zipcode Engine to support Canadian postal codes in Widget.") that I want to get out of my head and sorted into a project. Now, I could make all of these projects part of one larger project, but I don't like that - I like my projects smaller than that.

So "Install Zipcode Engine Into Widget Project" has a Next Action of "Waiting for Write Zipcode Engine Project" and a context of HOLDINGFOR, which is an On Hold context. It's going to sit there, idle, until I write that Zipcode Engine.

And the "Write Zipcode Engine" project has a final action of "Wake up Install Zipcode Engine Into Widget Project". Other actions will come and go, but I keep that action at the bottom. And I keep a similar action at the bottom of the first "Install" project, and so on in a waterfall.

Again, I'm not sure if this is proper GTD, but it is another thing that I use On Hold for. If it works, then the completed project will trigger me to wake the On Hold project. If that falls through, then I'll eventually notice the sleeping project in a Review.

In case this isn't obvious: You can review all items in a context that is on hold in context mode by selecting that context from the list of contexts on the left. Reviewing these contexts could be part of a weekly review.

I'm not sure that "on hold" is the "intended" function for implementing a "waiting for" context. It is one possibility that will suit some users. Personally, I use future start dates in a context that is not on hold.

On hold functionality has other uses. Gardener2 describes a way to set up dependent projects with an on hold context. I use this method, but only put the first (sequential) action in the on hold context. That way I can assign the appropriate contexts to other actions, but don't have to see them until they are actually available to me.

Contexts can be on hold for other reasons. I may have a "laminator" context, but then lend my laminator to a friend. While I don't have access to the laminator, I can set the context on hold. All of my laminating tasks will stay out of my action lists until I have my laminator back.

Or I may travel a lot. I may have some tasks that I can only do in my Toronto office, and others to do in my Edmonton office. While I'm in Toronto, I don't really need to see the Edmonton items on my action list, so I put that context on hold. Or a colleague who gets his own "Agenda" context may be on vacation. I'll put that context on hold until he's available.

OmniFocus has a lot of flexibility built in - so that you can arrange things the way you like. People may want to have different contexts or projects or even folders disappear from sight for all kinds of reasons. There are a number of ways to make this happen, including "on hold" functionality. It's there as an option - not an official implementation of any particular GTD list.

[Edit: spelling...]

Last edited by Hope; 2010-03-27 at 12:35 AM..
Just chiming in to say that I personally use future start dates to delay on hold actions, as well.
Perhaps it will be in some future release, but I would find being able to have status for folders would be great. Set a folder to "on hold", then just drop stuff into to. I use both on hold, and future start dates. I picked 1/1/2030 for indefinite (nearly) hold. Maybe I should use 1/1/2525. "In the year, twenty five, twenty five, if OmniFocus is still alive..." (Sorry, you have to be middle aged to get that.)


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
Thread Thread Starter Forum Replies Last Post
German localization problems, WebDAV iCal export due: "fällig" vs. "Fälligkeitsdatum" FatalError OmniFocus 1 for Mac 5 2011-04-08 07:32 AM
How to create task with "due date" BUT without "due time" ? fire00 OmniFocus 1 for Mac 3 2010-04-14 12:36 AM
How does OF for iPhone handle "Someday/Maybes" and "On Hold"? JRArseneau OmniFocus for iPhone 12 2008-08-04 06:56 PM

All times are GMT -8. The time now is 12:03 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.