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 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).
Well said, AmberV.
 
Quote:
Originally Posted by 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.
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.
 
BEST EXAMPLE EVER!!!

You almost saw my "O" face. :)

BZ
 
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. :)
 
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.
 
Okay, first some quick responses to your quick points:
  1. 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.
  2. 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.
 
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.
 
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.
 
Quote:
Originally Posted by 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.
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...

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

Quote:
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?

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


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 06:51 AM.


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