I really need a third category...

[Janice]

From what I've gathered from the forum, I have only two options. I can view my tasks either via projects or via contexts. But I need a third category, status. Status could encompass categories such as delegated, pending/waiting for, scheduled, ASAP, reference, prospective/someday/maybe. The idea of creating contexts @delegated or @reference seems silly given the GTD meaning of context (environment(s) and/or resource(s) required to execute the task). And if I use a context to assign a status, I then can't assign a true context. For example, if my follow-up of a delegated task requires a phone call, I'm forced to make a choice as to whether I'll see it under @phone or under @delegated. Frustrating.

The other alternative is to create projects with status categories. But again, ultimately, I'm relegated to a similar compromise. I can (a) see a bunch tasks, unrelated, but for having a simiar status of, for example, delegated, in a "project" that is counter to the GTD definition. Or, (b) see the related tasks in the project to which these tasks belong. But I can't do both. Frustrating.

Thinking Rock is the only app I've seen that allows for one to filter according to status, context and project, simulateously. Unfortunately, it's UI is impossibly cluttered (especially in comparison to the clean UI of OmniFocus).

And so, I continue to live with hope that one day, an upcoming screencasts will have a third view mode next to projects and contexts that will read status.

Am I the only one?

I'd be interested to hear from the Omni Ninjas what the road map is to address issues re status...

[Mario.Batz@cern.ch]

Well,

In the case you describe I decide on what the next action will be when I enter the the task that I have delegate. Then, if I need to call it becomes e.g.: call John to check that car is ordered. When I need to discuss this with the person I choose for two alternatives: either I file a task in @John, or in a @PurchaseMeeting.

Can also just simply be that I delegated something to someone I am only occasionally working with or a foreign person. Then I define a next action and file it in @WF (Wating For). This is not a real context, but the only one I use like that. For me this is not a problem.

Personally, I think that it is important to decide on the next action for me to be done, when I delegate something. the context where to file it is then clearly identified.

Using an additional thing like status will make it in my opinion more complex to enter taks and to follow them up.

Cheers

Mario

[Janice]

Well,

In the case you describe I decide on what the next action will be when I enter the the task that I have delegate. Then, if I need to call it becomes e.g.: call John to check that car is ordered. When I need to discuss this with the person I choose for two alternatives: either I file a task in @John, or in a @PurchaseMeeting.

Can also just simply be that I delegated something to someone I am only occasionally working with or a foreign person. Then I define a next action and file it in @WF (Wating For). This is not a real context, but the only one I use like that. For me this is not a problem.

Personally, I think that it is important to decide on the next action for me to be done, when I delegate something. the context where to file it is then clearly identified.

Using an additional thing like status will make it in my opinion more complex to enter taks and to follow them up.

Cheers

Mario
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?

[joelande]

Everyone say ... tags ...

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

[Ken Case]

Status could encompass categories such as delegated, pending/waiting for, scheduled, ASAP, reference, prospective/someday/maybe. The idea of creating contexts @delegated or @reference seems silly given the GTD meaning of context (environment(s) and/or resource(s) required to execute the task).

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.

[joelande]

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

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.

As a sys admin and manager of an IT department, all of my life is on the computer. And much of it is spent delegating tasks, and following up with them to make sure it has actually been done.

There needs to be another way to organize things besides @Computer, @Email, and there need to be a mechanism to follow up with delegated tasks.

And even the piles you reference ARE GTD.

There is a great thread on tagging here:
http://forums.omnigroup.com/showthread.php?t=2546

[joelande]

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.

Well, that works, but I think the issue here is you are creating two tasks for the same task
1. the original task, which you "completed" by delegating it
2. the task to follow up with the person you delegated it to

Which one could argue
A. That seems like a lot of busy work
B. It kinda goes against the GTD principal of handling a task only once

[coconino]

As a sys admin and manager of an IT department, all of my life is on the computer. There needs to be another way to organize things besides @Computer, @Email.
As I understand the idea of a context in GTD, it is the specific situation within which the task can be completed; and although it may be "organisation" in the strict sense, the function of contexts is to filter-out the noise of those tasks which cannot be addressed in any given situation.

If this reading is correct, it follows that each user will have different requirements for the degree of specificity needed to focus meaningfully on their tasks. For one person @computer may be specific enough but someone else might need to use @photoshop to filter-out all their other computer-based tasks; yet another person may want even finer-grained control and use @retouching to separate this field of their attention from others such as @scanning and @resizing. In OmniFocus these contexts can be nested, grouping them together in the list for clarity (e.g. @computer>photoshop>retouching), but in the line item they show as the single specific context. On the other hand, for someone using a computer all day an @computer context may be meaningless and using @photoshop, @internet might be broad enough.

My understanding is that contexts should not be regarded as "categories" as such, but as a means to help you ignore those tasks on which it would be pointless to waste your attention at that particular moment.

[coconino]

Well, that works, but I think the issue here is you are creating two tasks for the same task
1. the original task, which you "completed" by delegating it
2. the task to follow up with the person you delegated it to

You may be entirely confident in the competence of the person to whom you delegated, so (2) may not be required. On the other hand, the task may be a large one requiring your oversight and therefore additional follow-up tasks.

In the first place, however, I think that when you delegate a task you are then merely awaiting its completion. If it is anything more than that then you still have a project and everything which that entails.

[coconino]

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?

[LizPf]

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

[Janice]

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.

[pjb]

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

[Janice]

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?

[Janice]

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.

[Janice]

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.

[Ken Case]

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.

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

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!)

[Janice]

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?

[dansays]

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?

[coconino]

Janice, my interpretation of your tasks would be something like:

(Project view)

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)

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

[TommyW]

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

[brianogilvie]

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.

[Ken Case]

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!

[dansays]

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.

[Janice]

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.

[Janice]

Thanks, Ken. Your responsiveness on this forum is sincerely appreciated.

[smew]

Wow! That type of Omniplan integration sounds marvelous. Too bad most of our team are not on macs...

[dansays]

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.

[AmberV]

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

[Janice]

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

Well said, AmberV.

[dansays]

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.

Maybe an example would help convey my point. Let's say you need to format a TPS Report, and deliver it to your boss. In order to do that, you need to call Samir to get some figures.

I'm guessing (please correct me if I'm wrong) that what you want to do is...


Call Samir re: TPS Report (@calls)
Format TPS Report in Word (@computer) (STATUS: waitingfor:samir)
Print cover sheet for TPS Report (@computer)
Deliver TPS Report to Lumburgh (@agendas:lumburgh)


Once Samir gets you the figures, you remove the "Waiting For" status, and "Format TPS Report in Word" becomes actionable in your @computer context. There's nothing wrong with that approach, but it's not the method Mr. Allen prescribes in his book. I'm not claiming that his "Real GTD" is the One True Way(tm), just that the majority of people who follow his system do it this way instead:


Call Samir re: TPS Report (@calls)
WF Samir to email TPS Report figures (@waitingfor)
Format TPS Report in Word (@computer)
Print cover sheet for TPS Report (@computer)
Deliver TPS Report to Lumburgh (@agendas:lumburgh)


It's a subtle difference, but here's where it becomes more flexible. What if, during your call with Samir, you determine that you also need some stats from Michael Bolton. "Oh, I'm meeting Michael for coffee at Chotchkie's this afternoon. I'll just ask him then," says Samir. So now you're "waiting for" different things from different people. I'm not sure how you designate this with statuses, but here's how it would look under GTD proper:


Call Samir re: TPS Report (@calls)
WF Samir to email TPS Report figures (@waitingfor)
WF Michael Bolton to email TPS Report stats (@waitingfor)
Format TPS Report in Word (@computer)
Print cover sheet for TPS Report (@computer)
Deliver TPS Report to Lumburgh (@agendas:lumburgh)


If, during my weekly review, I see that Michael dropped the ball, I simply add a new action to my @calls list:


Call Michael Bolton re: TPS Report stats (@calls)


Again, I'm not saying that this is the One True Way. Everyone is free to adapt and adjust their system as they see fit. But designing great software--great Mac software, in particular--is about editing. Adding features like tagging and statuses may get them a few more users at first, but I think the majority of people would trip over them, or attempt to use them and fail.

Personally, I think Ken's approach of user-definable meta data is the perfect compromise.

[BwanaZulia]

BEST EXAMPLE EVER!!!

You almost saw my "O" face. :)

BZ

[AmberV]

I am a bit rushed for time, so I do not have time to produce a well formulated response and feature proposal. I do have some ideas about this though. In summary: My concern is that some of the "strict" methods were designed for paper systems, and we have the opportunity to take advantage of much more automated and efficient computerised methods. In my opinion, it would be a mistake to simple apply the paper method without giving some serious thought as to how it can be optimised.

For one thing, the paper method never automatically collated anything in a fancy context view. This produces errors in task availability, especially in the cases where parallel projects have individual tasks waiting on one or more other tasks (which may or may not be located in the same project) to be completed.

Anyway, more later today. :)

[dansays]

You're quite right that, given the right circumstances, a software-based system can--and should--deviate from the strict, device agnostic system in David's book. I'll watch for your full response this evening, but for now I'll just make two more quick points:

1. Some of us still use paper, in the form of print-outs of context lists. Anything that's implemented in OmniFocus needs to be backward compatible to dead trees.

2. Sometimes the action immediately following the "waiting for" item isn't clear. Maybe I have no idea what condition the figures will be in when Samir emails them to me. They might need double-checking, or they might need additional formatting. Designating "waiting for" as a special status forces me to decide the next action, even when it's not clear what that is.

[AmberV]

Okay, first some quick responses to your quick points:


Absolutely, and not only for the sake of people who still use paper: Some parts of GTD are always going to be paper for most people, due to the nature of society. The physical inbox is a necessity. Sure, you could scan documents in as PDFs and attach them to items in OF--but that would be wasteful for most people. That issue aside, I think that a more dynamic system can (and should) unfold into a system more conducive to static physical means upon export. What I'm getting at is something that would be useful in a dynamic collation environment, that when printed out would look something more like what you've got, which is less useful dynamically, but more usefully with a pencil and a pad of paper. Hold that thought.
What you are really talking about here is decision trees, an important part of any comprehensive project plan with contingencies. Basic GTD does not really address the notion of a forking dependancy system explicitly, so we are kind of in murky waters here. When I designed a GTD system using Tinderbox (a data management application with the ability to embed logic into the outline), one of the things I programmed into it was a basic decision tree model. I could essentially make a WF task that had an optional number of dependant inactive tasks. Once I fed an answer into the parent WF task, the relevant portion of my project would enable itself and inject into the contextual collation. In other words, I could work in contexts, and as long as my project was well planned, I could continue working in there, even if variable circumstances caused forks in the task plan.


This is precisely the kind of thing that a computed list excels at. Not only can it handle the automated collation, it can provide a fluid expansion and contraction process. Dependency forks can be developed and nixed as necessary, in real time without throwing out sheets of paper.

Theories aside, how can something like this be implemented in OF, and better yet should it. Your argument, if I am reading it correctly, is that this process should be inherit in the way a list is formed, and not supported at all by the software. This is certainly possible, but even in simple scenarios like your example, it can create a raft of tasks that are really nothing more than supporting data for a single task. The two WF tasks you generated should, in my opinion, be addenda to the principle task of formatting a TPS report.

The two most common errors I see in GTD software is that the notion "waiting for" is only peripherally addressed, if at all; and, when it is addressed it either does not provide a place to discuss why something is waiting, and/or it overrides other meta-data in the process.

Here is a proposed solution: A new icon is placed in the task line, it can be as simple and space efficient as an hour-glass. Normally, this icon is invisible except on focus or mouse-over. This icon would have a bi-modal usage.

In one mode, you could click it once (or hit a hot-key like Cmd-"), and a space below the task would open up (similar to how Notes appear), letting you type in a short note. This would be where you would place an ad-hoc conditional on the task. In the example above, you could type "Samir to email TPS report stats." If there is anything in this field, the action becomes unavailable from a filtering standpoint, and could perhaps be exclusively filtered by "Waiting For..." type. The appearance of this item would be almost like a sub-task, the difference is that it falls within the task border, like a note, and it does not convert the parent task into a sub-project. It will however have a checkbox associated with it. When checked, the status of the parent task would become Available. Of course, once a task has listed dependencies, the hourglass icon (or whatever) would always be visible.

The second mode of operation would be to actually link other existing tasks. There are cases where tasks rely on other tasks to be completed. I know this falls a bit out of canon GTD, but there are many instances in my own experience where tasks (and even projects) outside of the current project's realm need to be completed before a certain task is ready to take action on. These may even be tasks that I myself need to complete, and are therefore not strictly "WaitingFor" in the sense that I need to halt process on account of somebody else. This mode of operation would best be addressed via drag and drop. You would take the task or project that a certain task requires completion on, and drag it right on to the hourglass. It becomes a dependancy, displayed just like the ad-hoc, with perhaps a little arrow icon to the right to indicate that it is linked to another spot in OF. This would essentially just be a collation, that is key. Editing the text of this dependent task would edit the text of the linked task wherever it is located. Checking it off would check off the linked task, too (potentially enabling other tasks in the case of sequential projects.) To describe it another way: It would be a formalised way of symbolically linking (or aliasing) parts of an OF outline into other parts of an OF outline.

In your example, you addressed how multiple dependencies can erupt in certain situations. As such, multiple links and ad-hocs should be able to exist beneath a certain task.

http://www.semigreenpenny.com/img/forums/07158.114-dependencies.png
(Some key things to note: I didn't have a handy hourglass icon so 'WF' will have to suffice. The first dependency has a small arrow indicating that it is linked from another part of the OF outline; the second is an ad-hoc. Notes would appear below all of this.)

Note that even though the first action here is unavailable because it is waiting for these other actions to be completed, the next action on the list is not available either! This is important. In a sequential project, if there is a hold-up in the middle, all production ceases until that hold-up can be addressed.

So what we basically have here is the ability to fold non-actionable items, actionable dependencies, and extra-project links beneath a single item that shows up in the contextual view. A single item that can be expanded by clicking on the hourglass icon, and can be expanded on print to produce a list not unlike the example you provided. The difference is, the OF context list is not cluttered up with things that may not be actionable yet. Meanwhile, the process of fluidly expanding and contracting the addenda for a single task is intuitively addressed and displayed. Meanwhile, the context of the waiting task is not overriding by what is, at best, a temporary pseudo-context.

Your usage proposal addresses part of all this, but it makes the assumption that dependencies are a part of the same sequentially progressed project, and can be displayed in a linear fashion. It works quite well for that specific scenario, and requires no voodoo on the part of the OF team to accomplish. But, once you get into more complex areas where projects are complicated webs of dependencies and conditionals, with a mixture of parallel and sequential, I think it falls short of what can be effortlessly accomplished with a computer.

To return to the original brief discussion on forking decision trees: This proposal, while it does not specifically address it, would in fact allow it. Look at it this way: I can create a project with three sub-projects. I know from the original planning that I will only need one of these sub-projects once the dust settles, but I want to plan for each contingency so that once the team starts rolling, there is no down-time necessary for re-planning. Using this system, I could create three parallel tasks at the top of the project which each state one condition, and then link these three tasks into the dependency bank for the sub-projects below, respectively. Since the sub-projects will become considered unavailable, the only visible actions for the project will be the three conditionals. Say condition B looks like the direction the company will go. You tick it off in context view, and instantly the sub-project linked to that conditional activates. The others remain unavailable and you can either keep them for archival, or delete them if you truly think you'll never need them, later on. Either way, the only thing that hits your contextual action board is the necessary actions.

In closing: I stress that all of this is conceptual. The mock-up is more functional than aesthetic, and there are doubtlessly some worms in the way I'm thinking that would make things not work precisely as described. However, I think this would be a powerful direction to go in, in some form. The best thing about it is that, like other OmniFocus advanced features, if you never need it, it stays tucked away and out of site.

[brab]

Thanks everyone for the very informative discussion. My very modest contribution is the simple way I deal with this: I have no waiting for context, but when I start waiting for something, I choose a date when I want to contact the person again to ask for the thing again and create a task in the future. If I get the answer before I simply delete this task, otherwise I get an automatic review at this date and ask the person again.

[kmarkley]

Wow. What a neat idea. I can see that this would be a subtle and powerful extension of OF's capabilities. Something tells me that it is not a 1.0 feature, however.

But there is something I don't quite get. In your example "Get TPS Report figures from Samir" exists elsewhere in the database, but what is the context for this? No context? The ad hoc dependency "Email from M. Bolton..." exists only here and does not seem to have a context

So the trouble I see is that the opportunity one has for checking off dependencies is only when reviewing the project in project view (during a weekly review or whatever) or if "Format TPS report in Word" is visible in context view b/c the filter is set to 'all' or 'remaining'.

So the more basic issue is how to keep these single, simple items/tasks/dependencies on your radar (i.e. not buried 12 levels deep in projects view) but not in the way of things that are currently actionable. This is true with both the currently implemented dependency logic and in your much more powerful proposal.

Using a @WaitingFor context may not be ideal, but at least it does this one thing. Personally, I am just trying to get in the habit of doing a daily review of my @WaitingFor context, which I ignore (i.e. don't have selected) the rest of the time. At the end of the day I check if anything I was waiting for has happened, or choose to create a new action to remind someone, or add a start date in the future so I don't see it again until then. In any case when something I was waiting for does happen, I don't need to go hunting to find it deep in my project hierarchy. It is right there in the @WaitingFor context (which is flat by definition).

I wouldn't mind having WaitingFors handled in a way that doesn't confuse the concept of a context, but it would still need this basic funtionality with or without a complex dependency logic.

[AmberV]

Wow. What a neat idea. I can see that this would be a subtle and powerful extension of OF's capabilities. Something tells me that it is not a 1.0 feature, however.

Possibly, though I did try to keep the implementation proposal within the bounds of what I guessed as existing task logic (with a few tweaks). Naturally, I don't know the code intimately...

In your example "Get TPS Report figures from Samir" exists elsewhere in the database, but what is the context for this? No context? The ad hoc dependency "Email from M. Bolton..." exists only here and does not seem to have a context

I probably should have used my own example data, as these are not the best examples. In a real life scenario, both of these would be ad-hoc, not existing outside of the current project; I just wanted to quickly display appearance ideas.

As for context, should either of these have a context? I'm not responsible for either of them. There is no place or medium I have to use to make sure they happen. I am simply waiting for somebody else to produce the necessary results for me to continue.

In the case of a cross-linked action which does have a context, it probably should be displayed. There is space for that in the design.

So the trouble I see is that the opportunity one has for checking off dependencies is only when reviewing the project in project view (during a weekly review or whatever) or if "Format TPS report in Word" is visible in context view b/c the filter is set to 'all' or 'remaining'.

The issue of filtering is somewhat outside of the scope of this proposal, but does require thought. The way I handled WFs in my Tinderbox solution was by colouring them a special colour, and including them in the available lists. That way, they stay in your face, but are obviously not actionable. In the context of OF, simply including them in Available but leaving them light-gray and italic would accomplish that; but is it the right solution for OF?

This is true with both the currently implemented dependency logic and in your much more powerful proposal.

Precisely.

And I agree about keeping it simple. The thing that would absolutely kill this idea is making it difficult to read and write. It needs to feel natural from both the review and the creation end.

[kmarkley]

As for context, should either of these have a context? I'm not responsible for either of them. There is no place or medium I have to use to make sure they happen. I am simply waiting for somebody else to produce the necessary results for me to continue.

...

The issue of filtering is somewhat outside of the scope of this proposal, but does require thought.

These two points get right to the crux of the issue (and back to the original topic of the thread).

My point is only that:

1) Contexts, as currently implemented, provide exactly the right functionality for WaitingFors. Namely that items that one is waiting for are sort of "brought to the surface" from the project hierarchy and are filtered the same way as tasks you ARE responible for. Selecting a @WaitingFor context and filtering to see 'next actions' displays items that are next up in a project, but that someone else is responible for. Filtering for 'available' shows WFs that do not themselves depend on other actions and are not scheduled to start in the future. And so on.

2) But using contexts in this way confuses the concept of what a context is - there really is no place or medium you have to use to make them happen.

So maybe the way to handle this is for OF to have 'special' context for WFs (much like the Inbox is a special project). It would work just like a context, but appear differently in the UI.

[AmberV]

While I do not disagree, I do think it extends to the held up action, because technically the action that is held up by the external things supporting it is waiting, too. This to me, speaks of something more like a status (like "On Hold" for projects, which is precisely what is going on--just at the task level). To me, the things which hold something up (that are not also something within your area of responsibility) are really something more like a note that implies a status shift, which is why I chose to present it the way I did. The fact that I need Samir to get some data to me should not occupy a task row in and of itself. It has no business in my todo list, except to explain why Task A is not proceeding.

Your conclusion about having a separate bucket is something that I personally agree with, though I would take it a bit further. Personally, I'd like context view to merely be another "staging" area like project view, discrete from a hypothetical third view: The working area. The working area would have sections for next actions (which would be a collation of context+projects; simultaneously addressing the problem of singletons, from another thread), which could be grouped by context, project, or however you wish to work. Also it would have sections for someday/maybes and waitingfors. This working area would allow easier review as it would pull out specific types of tasks and projects by status. This is where smart folders would go in the future.

I think the current setup is trying too hard to combine working+context. Granted this is how GTD is described, and I am not contesting that at all, I just wonder if too much is going on in the OF context view? I'm always flipping filters around in there, and wishing that there were somehow more filters for isolation and review. Adding filters and buckets to the context view is, while the easiest direction to develop, in my opinion a bad direction to go.

But, this is definitely getting into a post 1.0 release discussion. :)

[kmarkley]

While I do not disagree, I do think it extends to the held up action, because technically the action that is held up by the external things supporting it is waiting, too. This to me, speaks of something more like a status (like "On Hold" for projects, which is precisely what is going on--just at the task level). To me, the things which hold something up (that are not also something within your area of responsibility) are really something more like a note that implies a status shift, which is why I chose to present it the way I did. The fact that I need Samir to get some data to me should not occupy a task row in and of itself. It has no business in my todo list, except to explain why Task A is not proceeding.

I agree. I am just emphasizing that it should be easy to a) see what is holding up the project (Samir), b) find and check-off the item (when Samir does send in the data) and thereby release things that ARE on my todo list, and c) review these as a group (so I can decide whether to send Samir another email). Co-opting a context for WFs does these three things (which is why I have a @WaitingFor 'context'). But it remains confusing conceptually.

[kmarkley]

I think the current setup is trying too hard to combine working+context. Granted this is how GTD is described, and I am not contesting that at all, I just wonder if too much is going on in the OF context view? I'm always flipping filters around in there, and wishing that there were somehow more filters for isolation and review. Adding filters and buckets to the context view is, while the easiest direction to develop, in my opinion a bad direction to go.
Also: the planned-for-1.0 "Perspectives" feature (there's discussion of it in other threads) will actually go along way along these lines. By saving sets of filter-states, context-selection, and folder/project-focus, you should be able to quickly get pretty isolated. "Next TPS Report action" or "Everything I'm waiting for" or what have you.