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
Quote:
Originally Posted by Ken Case
OmniFocus does have a notion of project status: a project can be active, on hold, completed, or dropped, and you can filter the project list using these states. You can also set start dates on projects and actions (giving you a "scheduled" state), and you can create different top-level folders for projects and use those to create your own arbitrary groupings of folders (such as a someday/maybe list, which might be a bunch of projects in an inactive folder).
What this discussion suggests to me is that while a paper-based system may be hard-edged enough (as required by DA in GTD), when it comes to a digital system some of those edges might need further hardening. The four states you mention are not quite enough to prevent a "state" requirement being hijacked by the context system. On paper, a separate list for "Waiting for" (or "Awaiting", as I prefer) is a perfectly reasonable requirement, but when it comes to the world of OmniFocus it's harder to fit it in.

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. But then if not a context, how should such tasks be identified? One might point to "On hold", but are such tasks really on hold, or are they active but just being active elsewhere on someone else's desk?

Does the inclusion of a scheduling system in OmniFocus (start date, due date) mean that "waiting for" is no longer a useful state to recognise? Does the hole in the context wall really matter?
 
Quote:
Originally Posted by Janice
What do you do when you've delegated several tasks to several different persons (some occasional, some not), and you want to review all of your delegated tasks in one glance?
You could nest contexts:

@Delegated
Abel
Baker
Charlie

Then focusing on Delegate would show all delegated tasks, grouped by name.

--Liz
 
Quote:
Originally Posted by pjb
Allen wrote about separate piles for "waiting for" and "pending" and "reference" (that one's not really a pile but a filing system) and "someday/maybe" and there have been comments on these boards that at least "waiting for" should be a special box like Inbox but some are using Context for this. That might be "Waiting for...
---John
---Purchase Meeting
---etc as the dependencies arise"

which would allow you to Focus on that list.

Tags such as Flags, ASAP, priorities, interest are considered impediments to GTD. Janice lumped a few of these piles and tags together.

If it's scheduled, it's off your task list and into your calendar (processed).
If it's reference it's off your task list and in your file system (processed).
If it's delegated that's the same as pending/waiting on someone.
If it's ASAP then you've given yourself a stumbling block that's bound to create conflict and unhappiness (as Allen would say, as I understand him).

So we're back to having a special category for "Waiting for..." and processing everything else to either an un-prioritized action you are going to do or sending it off the task list altogether. You might send it to a tickler in the calendar to remind you to pester the person you're waiting for on some future date. "Waiting for..." can be an active task but one that doesn't allow next actions (I was tipped off to this approach elsewhere in the forum).

Sorry if this comes across as to righteous. I've been listening to the Allen audiobook in the car lately. I'm trying to grok it myself.
I won't argue your preferences or process (to each her own interpretation), but I would encourage you to look at David's suggested Workflow Diagram. ASAP is my shorthand for the tasks that take longer than two minutes and are deferred as "Next Actions" - to do as soon as one can.
 
Quote:
Originally Posted by Janice
...ASAP is my shorthand for the tasks that take longer than two minutes and are deferred as "Next Actions" - to do as soon as one can.
I understand you, now, but I think we were talking at odds before. Thanks for the clarification. I do still try to catch myself from prioritizing once I'm working off the Available or Next Actions list.
 
Quote:
Originally Posted by Ken Case
OmniFocus does have a notion of project status: a project can be active, on hold, completed, or dropped, and you can filter the project list using these states. You can also set start dates on projects and actions (giving you a "scheduled" state), and you can create different top-level folders for projects and use those to create your own arbitrary groupings of folders (such as a someday/maybe list, which might be a bunch of projects in an inactive folder).

I have to confess to a certain puzzlement over the whole notion of "delegated" as a context or separate state for an action. If I delegate an action, it's off my plate: that action is not really my action any longer. Instead, my action is to check to see if my designated delegate is progressing appropriately on the action, which usually implies adding a new action to an Agenda context (along the lines of "Review Jane's progress on plans for t-shirts") and scheduling it (say, for next week). When I look at my action list, I now see something concrete and specific that I can do at an appropriate time and place to keep that project moving forward.
If only status could be applied to single tasks as well as projects.

I understand your solution. And I think it's a valid one. However, I'd personally find this method problematic when I have more than a few tasks delegated.

Unfortunately, in my realm, "delegated" does not correspond to "removed from plate." When managing a project, I'm held accountable for its ultimate success or failure, which means I have a vested interest in each of the moving parts.

I appreciate Journler, in that it allows me to create a smart folder of my 60 + delegated tasks and enables me to group and review these tasks in a glance. The thought of having to sift through numerous contexts and projects, and over 300 tasks, to find all 60 + tasks that have been delegated seems a bit perilous.

Because I really want to take advantage of OmniFocus's clean and intuitive UI, I envision "tagging" each task with [Delegated] and utilizing the search button to spotlight these tasks until another solution comes along. However, Ken, if I read your message correctly, it seems y'all don't see the need of status and haven't any plans for making provisions for those that do. Is this true?
 
Quote:
Originally Posted by joelande
They may be impediments to GTD, but that doesn't mean they have to be impediments to OmniFocus.

If you don't want to use tags, don't.
Amen, brother. Amen.

Again, I don't want to disassemble methods that work for others, but I do think that the inclusion of tags (and smart folders) would allow me to put together a method that works for me.
 
Quote:
Originally Posted by LizPf
You could nest contexts:

@Delegated
Abel
Baker
Charlie

Then focusing on Delegate would show all delegated tasks, grouped by name.

--Liz
Thanks, LizPf, for the recommendation. If you reference my first post in this thread, you'll note my frustration that by using contexts in the way you suggest, I'm precluded from using the contexts as defined by GTD.

In other words, any tasks listed under your suggested context of Delegated, wouldn't appear under phone, email, server. This means I'd have the status of the tasks, but I wouldn't be able to access them according to my current environment or available resources.
 
Quote:
Originally Posted by Janice
Unfortunately, in my realm, "delegated" does not correspond to "removed from plate." When managing a project, I'm held accountable for its ultimate success or failure, which means I have a vested interest in each of the moving parts.
Of course! This is part of what I don't understand about making the state "delegated". I could certainly see adding a note saying "Delegated to Jane on 5/1", but I still need to follow up on these actions in an appropriate time and place, and the way for me to do that is to set their contexts to "Agenda:Jane" and "Agenda:Bob" and to set a start date or due date—so that they're appropriately actionable for me, and not just pushed off my plate.

Quote:
Originally Posted by Janice
I appreciate Journler, in that it allows me to create a smart folder of my 60 + delegated tasks and enables me to group and review these tasks in a glance. The thought of having to sift through numerous contexts and projects, and over 300 tasks, to find all 60 + tasks that have been delegated seems a bit perilous.
To see all my delegated actions, I just click on my Agenda context (the parent of Agenda:Jane and Agenda:Bob) and I now see all the actions delegated to anyone (along with anything else I need to talk with them about).

Quote:
Originally Posted by Janice
However, Ken, if I read your message correctly, it seems y'all don't see the need of status and haven't any plans for making provisions for those that do. Is this true?
We're trying to build a very flexible system, but also trying to introduce no more complexity to the system than necessary. I certainly do understand the need for that sort of state, I just think that it's already part of the system (in the form of contexts, used as described above), so I don't yet understand the need. (That doesn't mean that you should stop trying to help me understand it, though!)
 
Quote:
Originally Posted by Ken Case
Of course! This is part of what I don't understand about making the state "delegated". I could certainly see adding a note saying "Delegated to Jane on 5/1", but I still need to follow up on these actions in an appropriate time and place, and the way for me to do that is to set their contexts to "Agenda:Jane" and "Agenda:Bob" and to set a start date or due date—so that they're appropriately actionable for me, and not just pushed off my plate.



To see all my delegated actions, I just click on my Agenda context (the parent of Agenda:Jane and Agenda:Bob) and I now see all the actions delegated to anyone (along with anything else I need to talk with them about).



We're trying to build a very flexible system, but also trying to introduce no more complexity to the system than necessary. I certainly do understand the need for that sort of state, I just think that it's already part of the system (in the form of contexts, used as described above), so I don't yet understand the need. (That doesn't mean that you should stop trying to help me understand it, though!)
Alright. You've got me working hard for this one. We'll use your example. Let's say I've three tasks under Agenda : Jane. (1) Conference call with myself, Jane & X (which Jane is delegated to initate), open-ended; (2) Meeting with Jane & Y to discuss ABC the results of which Jane has been asked to email me on such and such date; and (3) Update on out-of-state conference she's attending during such and such time frame. My follow-up of these tasks could involve several and different contexts, perhaps with task #1, I'd shoot her an email if I haven't heard anything within the week, perhaps #2, I'd schedule a meeting if there's nothing in my inbox on the date due, and perhaps task #3 would be a phone call given that she's out of town.

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?
 
The concept of an "agenda" has always seemed somewhat ambiguous to me, but here's my take. I use my @agenda lists as a way to keep track of things I need to discuss with others the next time I happen to be speaking with them, be it in person, over the phone, or in an email. It's a more passive context than, say, @calls or @email.

I don't keep @waitingfor items in my @agenda lists, since the context is different--not physically, but conceptually. My @waitingfor list is for delegated tasks whose completion is necessary to move a project forward. During my weekly review, if I come across a @waitingfor item that requires a reminder, I add an action to @calls. This is merely my interpretation of the "official" GTD system; your mileage may vary.

Not to introduce more complexity into an already confusing issue, but what I'd love to see is the ability to attach tasks--any task, regardless of context--to contacts in my address book. This does two things:

1. 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.

2. I see lots of cool possibilities to "put it in front of the door," as David says. For example, when my bluetooth phone is paired with my MacBook, my computer pops open a caller ID window showing the contact's profile. This would be a perfect opportunity for OmniFocus to chime in and remind me that I have to remind Jane that I'm waiting for a decision on the whatzit, or tell Bob about the new Thai restaurant I read about in the paper. (This feels like an OmniFocus 2.0 feature, but tying tasks to contacts lays the foundation.)

Thoughts?
 
 


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 05:11 AM.


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