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 > OmniFocus 1 for Mac
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Project Actions with Waiting For On Hold Context Thread Tools Search this Thread Display Modes
Hello Everybody,

i am evaluating Omnifocus and have a question regarding the treatment of waiting fors. here is my setup. i use an @WAITING FOR context that is set to the on hold status.

so when planning a project i set up several actions, like:

create proposal
send proposal
wait for feedback re. proposal.

the first two actions would go to an @HOME or @COMPUTER context and the last one to the waiting for context mentioned above. the project should also be set so the SEQUENTIAL order.

now i am wondering why i see the last action at the wainitng for context. i would expect that i ony see it there, if the first two actions were completed.

what do i miss?

Thanks and best regards
Patrick
 
I think you want to try setting the view filter to "available." Try searching the help for "Using the view bar to filter and arrange items".
 
hi Lucas and thank you for the reply.

setting the filter to available hides all actions in my waiting context because this context has the onhold status. what i want is only see the waiting fors that are relally the next actions. while being able to plan a waiting for i dont want to see the wating for until i finished the action needed before.

i hope this makes my intention more transparent.

Regards
Patrick
 
Hmmm. I think I get what you are trying to do. At the end of a project you want to have a list of "waiting for" actions that aren't on your task list for you to do but that you can check up on later. So when you look at that list, you don't want to see stuff that you haven't really reached that part of the list.

My suggestion 1 to try would be to use Kurt's excellent "complete and await reply" script to only add those waiting fors when you deliver the product. But, it would be kind of a change to your workflow - you wouldn't be setting them in advance.

My suggestion 2 would be to have two waiting for contexts - one that is on hold and one that isn't. Put your last action in the active on hold context and set the project to be sequential. When you reach that point in the project, it will pop up and you can move it to the on hold context containing your stuff that your holding on.
 
Hi Lucas,

thanks for your advice. i can see that this workaround will work :-). however, i am confused why there is no straight way out of the box in OF for that. i migrated form outlook to OF. and the longer i am using OF the more disappointed i am.

the killer features i thought were master/detail data structure for projects and tasks as well as contexts and perspectives. the latter ones could easily be created in outlook as well. the advantage of OF was then the master detail view and the possibility to plan projects further and also use the sequential or parallel mode in projects. now i have to use for different actions different on Hold contexts. i dont think this is intuitive and easy to use...

sorry and best regards
Patrick
 
So if I understand what you're trying to do, you want there to be some period of delay between sending the proposal to someone and when you follow up with them.

Rather than a waiting-for context, I tend to use start dates to accomplish this. check off "Send Proposal", and when the subsequent action appears, just set the start date for "next week" or whatever works for your purposes.

A start date in the future will also cause the subsequent actions to become unavailable, with the added benefit that when that start date comes, the actions will automatically re-appear.

Does that help at all?
 
Patrick,

are you sure you aren't creating a theoretical mountain out of a practical molehill? I've been using OF for a couple of years, with lots of actions in on hold contexts, and while I believe I understand your complaint, it just hasn't been an issue in my practice. Perhaps the difference is simply in how we use the tools.

I have a handful of on hold contexts:

Looking for
Waiting for
--Calls
--Email
--Mail
--<people>

A perspective that shows those contexts, grouped by due date and sorted by due date, showing remaining items

I typically work out of context mode, viewing available actions, grouped by start or due. I don't see those on hold items at all there, but they'll block progress beyond them in their project, of course. When I do see them is when viewing things in project mode (with remaining actions), typically when doing a review or focusing on a single project, or in my daily start-up process, which includes taking a look at the "Waiting and Looking" perspective mentioned above to get a reminder of anything I should be watching for. If I see that there is something I'm waiting for that is now overdue, I double-click on the action and get a new window focused on that project so I can see the whole picture and decide what needs to be done. I will see the overdue item even if the containing project hasn't gotten to it yet, yes, but I still most likely want to take some corrective action (example: I'm building a new disk farm, and I haven't finished designing the filesystem, but UPS hasn't delivered a drive when they said they would -- I'm going to want to find out why even if I'm not ready to use the drive!) I do assign a due date to most everything that is in one of the on hold contexts, and usually have the "no due date" group closed. I think that keeps items out of my active sight until there is need for attention while still allowing me to easily check up on them.

I was interrupted while writing this and Brian has contributed his piece in the interim. I notice that he has a completely different read on the situation (and that mine differs from Lucas' as well) and hope that between the three of us, we've at least straddled the target :-)
 
I think you should consider making that "waiting for" not on hold. Then, with the available filter set, final actions that haven't been reached won't show up to remind you to harass people about. Better yet, after you've harassed them, you could sleep the action by giving it a future start date.
 
Thank you so much for your feedback and the cool answers. This is a really cool community.

the more i play around with OF the more i think a lot of questions is related to the personal style.

With regard to that @whpalmer4 due dates is nothing for me because it is not GTD like. if i have fixed dates i use a calendar. the weekly review will do the rest because during it i check the calendar for important things.

So let me clarify my issue a bit more.

i think the big advantage of OF is the possibility to plan projects in project mode. so it is possible to track more than the typical GTD next action. if i have ideas for the further actions, i can plan them as well. so if i have a sequential project consisting of 5 steps or actions, an the 4th action is a waiting for action acting as a reminder for something i delivered in step 3, i would set step 4 to my waiting for category. if i am doing this and then switch to context mode, i see the waiting for action in the waiting for context, even when i am still at step 1 (with regard to the example above). after researching i found out that this is probably because of the status filter that is set to "left" (i hope this is the correct translation because my OF is in german. it is the top item in this filter category). so i set the filter to "available". now i don't see any waiting for item any more. all are hided. even those that were the really next steps in the project. for example step 4 in the example when the three steps before are completed. i still think the available filter is the correct one because it hides also other unavailable tasks in other categories that are later on relevant in other projects.

so the answer of Lucas made me think more about not setting my waiting for context on hold. i have to play around with this a bit and will post my experiences here. i think this could really work for sequential projects. i am not sure if it will work for parallel ones.

but if it does, i am confused regarding the function of setting something to on hold. what is it for then? the documentation says that it is for two kinds of things:

"
Using on-hold or “waiting” contexts
You can set a context’s status to “On Hold” with the inspector; actions assigned to an on-hold context are considered unavailable, and they block the progress of sequential projects. There are two main situations in which you might want to use on-hold contexts:

First, you might create one or more “waiting” contexts for keeping track of actions that you’ve delegated to other people. You can’t actually do anything until you hear back from that person; all you can do is wait for them to finish it, and maybe nudge them about it every now and then. So an action like “get annotated pterodactyl brochure draft back from Dennis” might go in your “Waiting : Dennis” context.

Second, you might have some contexts that you don’t expect to be available to you any time soon. You could put your “Frankfurt” context on hold when you’re in London, or put your “Boss” context on hold until she comes back from vacation, and any actions assigned to them would become unavailable. This helps you see which actions and projects aren’t likely to make progress until your situation changes.
"
interesting is, that on hold actions only block the progress of sequential projects. so this hints me more and more into the direction that it could work for both parallel and sequential projects because it seems that on hold has no impact on parallel projects.

so the first option mentioned in the documentation looks strange to me. this is exactly my case. but it is only working if i see only the waiting fors that are relevant at the moment and not future ones (that are in the context because of project planning). setting the context not to on hold will i think really that what i want. the Waiting For is the re really next step and showing up in the context. or do i miss something?

the second option seems quite clear to me. i think this i a good thing to use on hold for.

do you also use not on hold for theses waiting fors? I would be kind of you if you would send me your comments, etc..

Thanks and best regards
Patrick
 
Patrick,

My Waiting For context is not on hold. As you've seen, this means that actions in the Waiting For context will block subsequent actions in sequential projects, which is what I want and what it sounds like you want. Other people prefer to put Waiting For actions on hold so that they do not appear in their action list.

Quote:
i found out that this is probably because of the status filter that is set to "left".
In the English version this status filter is "remaining".
__________________
Cheers,

Curt
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Feature Request: Styling for 'on hold / waiting' actions mickh OmniFocus 1 for Mac 3 2009-07-16 05:46 PM
Waiting context vs waiting project status? marshallj OmniFocus 1 for Mac 3 2009-04-13 02:49 PM
Waiting (On Hold) Context Apples For Mike OmniFocus for iPhone 3 2009-01-03 12:06 PM
Using 'Waiting' context set to 'On Hold' or 'Active' lilyblossom OmniFocus 1 for Mac 15 2008-08-09 08:34 PM
Do Actions On hold force the entire Project to be On Hold? MarkSealey OmniFocus 1 for Mac 2 2008-02-26 06:27 AM


All times are GMT -8. The time now is 10:21 AM.


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