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

 
I really need a third category... Thread Tools Search this Thread Display Modes
Janice, my interpretation of your tasks would be something like:

(Project view)
Code:
Project 1 title
[] Conf call with myself, Jane & X	[duedate]	@Awaiting:Jane
[] Email Jane if not had call 		[startdate]	@Email

Project 2 "ABC"
[] Prep for meeting with Jane & Y	[duedate] 	@Office
[] Check in-box for results of ABC	[startdate]	@Email
	
Project 3 "out-of-state conference"
[] Update on out-of-state conf. 	[duedate]	@Awaiting:Jane
[] Call Jane for update			[startdate]	@Calls
(Context view)
Code:
@Awaiting:Jane
[] Conference call with myself, Jane & X	[Project 1]	[duedate]
[] Update on out-of-state conference		[project 3]	[duedate]
	
@Email
[] Email Jane if not had call 			[project 1] 
[] Check in-box for results of ABC		[project 2]

@Calls
[] Call Jane for update				[project 3]
	
@Office
[] Prepare for meeting with Jane & Y		[project 2]
Of course what is actually displayed in OmniFocus would depend on what filter settings you were using and what dates were applied to dated items. Also, some follow-up items might be needed depending on the results of of calls, etc.
 
This is an interesting debate for me, I find merit in both Janice and Ken's ideas (and in Dansays post too, I have to say, that would be cool..)

Tags seemed a no-brainer to me for quite a while, A context is nothing more than one after all. Janice is looking for a free-form approach to this and Ken is using the structured, disciplined but limited, approach of hierarchical contexts.

I'm not so sure about tags now, it seems like they would permit me too much openness, that I'd slide into poor practice easily, I'm not too sure why however, I can't quite put my finger on it...

For me, I think the answer might lie in use of the date columns, scheduling my attention for set periods of time.

But enjoying the interchange between these two POVs for the meantime...
 
Quote:
Originally Posted by dansays
I don't have to have a separate context for each person to whom I have delegated a task. One list for @agendas, one for @waitingfor, filterable by contact via the search bar, filter ribbon, or some other clever mechanism that the Omni folk dream up.
This is a good idea. For the time being, you can do the same just by putting the person's name in the task, though, and using the search bar to find all tasks that contain that name.
 
Quote:
Originally Posted by Janice
Other than doing something convoluted (in my opinion), like creating 10 different contexts that include the needed resource tool at the top of the chain, e.g. Phone : Agenda : Jane, Email : Agenda : Jane or Meeting : Agenda : Jane, what's your recommendation to capture status and context simultaneously?
OK, I see what you're getting at. Like dansays, I guess I've been considering the needed resource to be simply Jane and not Calls or Email or Meeting, so I just put it all in Agenda:Jane. In general, I try to keep my contexts as simple as possible, which sometimes means I see things I can't really do but means that it's less likely that I'll miss something I could be doing. (So while I do have a general Phone context, I reserve that for things like making an appointment with the dentist, and not for agenda items with team members.)

But I'm not trying to foist my particular structure on everyone else using OmniFocus: I understand what you're trying to do and it seems reasonable enough.

One of the items we're planning for 1.0 is limited metadata support, similar to what we currently have in OmniPlan. This means that you will be able to add your own arbitrary attributes to all objects in OmniFocus (actions, contexts, projects, and folders) and to access those later. For example, you could use metadata to add tags or people to your actions.

What I mean by limited support is that we're trying to just provide the basic metadata capture and retrieval in an inspector in 1.0 (because we want to finish what we've already started and ship!), so we'll be missing a big piece of the puzzle: building arbitrary queries (possibly as smart folders) which can reference different pieces of metadata. (Leopard provides a*nice query-building interface in Leopard which we'd like to leverage for this in 2.0.) You will be able to access the metadata from AppleScript and do some smart logic that way, but that's not really an accessible feature for most of our target audience.

Looking ahead to OmniFocus 2.0, we're planning integration with OmniPlan, so that you can build a project plan (with complex dependencies) in OmniPlan, delegate actions from that plan to team members who are using OmniFocus, and have them update their own status in the plan as they work through their action lists. But, again, we want to ship what we've already started first!
 
Quote:
Originally Posted by coconino
If my understanding of contexts is correct—that it is "what you can do, where you are, with the tools available"—then "Waiting for" is not a true context and asking the context system in OmniFocus to handle waiting-fors is to knock a hole in the hard wall of that definition.
Let's go to the source: "You'll probably find it works best to keep this 'Waiting For' list close at hand, in the same system as your own 'Next Actions' reminder lists. The responsibility for the next step may bounce back an dforth many times before a project is finished." So sayeth the David, p. 149.

So, no, "Waiting for" is not a context. In the book, it's never referred to "@waiting for," in the sense that "@office" or "@computer" is noted. But when it comes down to it, we're just talking about lists. Whether there's an @ sign before the name isn't really important, and treating the list as another context allows a level of customization (separate WF lists for personal/professional, for example) that would be lost if "waiting for" were formalized as a feature.
 
Quote:
Originally Posted by dansays
Whether there's an @ sign before the name isn't really important, and treating the list as another context allows a level of customization (separate WF lists for personal/professional, for example) that would be lost if "waiting for" were formalized as a feature.
I respectfully disagree. My WF tasks also require contexts. Given my work process, being forced to choose either status or context limits my ability to customize.

At any rate, true customization comes with metadata support and it reads as though our Omni ninjas have it in the gameplan.
 
Thanks, Ken. Your responsiveness on this forum is sincerely appreciated.
 
Wow! That type of Omniplan integration sounds marvelous. Too bad most of our team are not on macs...
 
Quote:
Originally Posted by Janice
I respectfully disagree. My WF tasks also require contexts. Given my work process, being forced to choose either status or context limits my ability to customize.
A "waiting for" item is not a task, it is a stake in the ground, a reminder that the ball is in someone else's court. If you need to call or email that someone to light a fire under their ass, then you add a task to your @calls or @email list.

If you have a different system that works for you, that's awesome, but it's not the GTD system that David Allen developed.
 
While it is true that a task that is waiting does not technically have a context at that moment, once its waiting status has been removed, it will have a context, and likely had one before. To strip the original context, and then rethink about replacing it later, perhaps even multiple times in the life of the task (as has been my experience, and in the quote you copy and pasted above), is a waste of time--and it breaks the rule of not doing the same thing more than once.

Finally, a task having a latent context and being waited on makes more sense than a task that has a context of "waiting for," which makes no sense at all, and isn't "Real GTD" either (whatever that is).
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Asign Category and Project to Actions skillet OmniFocus Extras 5 2011-07-09 04:12 PM
Actions that don't leave "Overdue" category Faulkner OmniFocus for iPhone 5 2009-09-04 08:14 AM
Organize Projects by Category or Roles dwayneneckles OmniFocus 1 for Mac 6 2008-07-16 06:48 AM


All times are GMT -8. The time now is 11:33 AM.


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