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.
(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.
Linear Mode
