[michelle]

Using strict GTD, projects should only have one next action. We've received many requests for multiple next actions and that is why we have an item called "available" actions in the filter. In a parallel project, this will show all actions.

[chrjohns]

Originally Posted by michelle

Interesting . . . we were thinking of creating a special type of project for single tasks that had no next actions. You're idea may be better. Do others agree? Should they all be next actions?

I agree that people should not be forced to adhere to the GTD dogma and that it should be as flexible as possible and it looks like OmniFocus will be that.

But here is my understanding of the way GTD works. The goal is to get things off of your mind. You do this by quickly adding items to your inbox for processing later. So you have an inbox, a number of context lists and a project list. Once things are in your “inbox,” the goal is to get “in to empty" by processing your inbox. Processing is not actually doing the task, but rather putting it on a context list or a project list.

Taking a look a David Allen's workflow diagram (http://images.google.com/images?um=1...rkflow+diagram) you "process" by first asking, "is this item actionable?" If it is actionable, you ask, "is this item multi-step?" If it is multi-step, then it is a project and you add it to the projects list. If it is not multistep, then you add it to one of your context lists. Next actions from your projects will also be added to your context lists as you see fit.

The context lists really seem to be the most important part of the GTD process because they are the lists that you review when you actually want to get some work done. The project list is just one way of getting next actions onto your context lists.

One possible solution would be to ever so slightly course correct OmniFocus so that the focus is on the context lists. The inbox would be just a default context that captures next actions if they are entered without a context or project. As soon as a context or project is assigned to the next action (or in other words "it is processed"), it disappears from the inbox and appears on the new context list. It does not show up in the project list ... unless you associate a project name with it. Then it magically appears as part of a project too. OmniFocus would also have the flexibility to add the item as a project first, before adding any next actions. But adding the next action to a project would not be required to move it out of the inbox. Leaving it in the inbox seems like it has not been processed.

But hey, I might not know what I am talking about because I have not actually gotten my hands on the app yet. In any event, we all really appreciate the opportunity to have a little input into your development process. Thanks.

[brianogilvie]

Originally Posted by chrjohns

One possible solution would be to ever so slightly course correct OmniFocus so that the focus is on the context lists. The inbox would be just a default context that captures next actions if they are entered without a context or project. As soon as a context or project is assigned to the next action (or in other words "it is processed"), it disappears from the inbox and appears on the new context list. It does not show up in the project list ... unless you associate a project name with it. Then it magically appears as part of a project too. OmniFocus would also have the flexibility to add the item as a project first, before adding any next actions. But adding the next action to a project would not be required to move it out of the inbox.

That actually strikes me as a very good idea, on reflection. One basic idea behind GTD is that projects are for planning anything that requires more than one step. A single task, by its nature, does not. If the Inbox appeared in both the Project and the Context view (iGTD, for instance, has the Inbox as a context), tasks there could be assigned a context without a project. You plan in the Project view, but you do in the Context view.

Whether it could be implemented is a different matter! Or perhaps it could be an option, at least in a later release, so that those who prefer to work in the Project view (maybe because they're always bouncing between contexts) can still see single tasks that they have moved out of the inbox. One solution would be to create a default project (called "no project") to which any task that had a context but no project would be assigned. In project view, users could be given the option of displaying this "no project" project at the top of the project list (below the inbox), at the end of the list, or not at all.

[curt.clifton]

Let me add to the chorus that every task in a parallel project should be a next action. If I make a project or subproject parallel, that means there are multiple things that I can do to move the project forward. For example, for an upcoming trip I can send an itinerary to my SO in an email context and I can brainstorm a list of things to take in an off-line context. There is no precedence between the two tasks, so there is no sense in which one is next and the other isn't. If I just wanted to focus on one task at a time for this project, then I'd make the project a sequential one.

I do need to maintain some discipline to not make every project parallel. And I'm probably not applying GTD very well if I have multiple tasks for the same context in a parallel project. (In fact, I will probably write a script to check for this warning sign in my weekly reviews.) But I don't want the tool getting in the way of my usage.

Of course if I can make Available Actions and Next Actions appear the same, then I can just use the Available Actions filter and be happy.

[jelmore]

Originally Posted by chrjohns

The context lists really seem to be the most important part of the GTD process because they are the lists that you review when you actually want to get some work done. The project list is just one way of getting next actions onto your context lists.

I think you've hit the sticking point for me with so many of these GTD-style applications; they want to focus on projects and priorities, when projects are holding places for potential Next Actions, and priority is irrelevant in my understanding of the true a GTD workflow.

GTD is supposed to help you deal with sudden changes in your contexts and priorities, where "priority" is determined by your context, energy level and time available, not by a scale of 1 to 5 in a productivity application. Merlin Mann illustrates it much better than I can:

http://www.43folders.com/2006/10/01/priorities-vacuum/

If you have a bunch of parallel projects, maybe you have a bunch of stuff that really belongs in a context list instead.

Hmm... something to ponder while I await my pre-release invite...

[duodecad]

Personally, if we're looking for a place to put single tasks that are not part of any project, I would rather not have that be the Inbox. For me, according to canonical GTD, the Inbox is where I dump things to get them out of my head and be processed later. I want to be able to get that inbox to empty by simply *processing* tasks, not actually *doing* them-- I think David Allen's emphasis on keeping "processing" and "doing" separate is a really key part of successful GTD implementation.

So if single items are going to go into some default place if you don't enter a project for them, I'd rather see that place be a project-like bucket-- a default "Single Actions" project or folder or something like that.

For what it's worth, this is why it makes sense to me to just create a project called "single tasks" and then dump my single tasks in there, and mark it as a "parallel" project so that tasks can be done in any order. The only thing I'd like to see beyond that is the idea suggested above, where for this particular bucket/project/whatever-you-call-it, you could have it show n next actions where n is a user-defined number-- or you could set it to "all" so that OF shows them all as next actions, no matter how many single tasks you've got in there. That would be really fantastic!

[chrjohns]

Originally Posted by duodecad

Personally, if we're looking for a place to put single tasks that are not part of any project, I would rather not have that be the Inbox.

***

For what it's worth, this is why it makes sense to me to just create a project called "single tasks" and then dump my single tasks in there, and mark it as a "parallel" project so that tasks can be done in any order.

I agree that the single tasks should not stay in the inbox. However, in my opinion, they don't belong grouped together as a project because they are by their nature unrelated. It would be great to have the option to have them reside in the context lists only.

[Hoff]

That seems like an elegant solution. I imagine an icon below the in-box, or at the top of the project list, with its own icon, labeled "Single Tasks" (which seems as clear as anything I've heard so far). In every other way, it would behave like a project. When I'm processing the In-Box, in the Project column, I choose "Single Tasks" and all is well. Then it would be out of my In-box, show up in contexts, and still be available to work with in Project view - all without a major UI or philosophy change.

[Janice]

Another potential approach. Currently, I utilize Journler as my GTD application and organize my tasks according to three broad categories; status, context and projects. Status captures tasks as either Scheduled, Delegated, Pending, ASAP, Reference or Prospective.

When processing my inbox, each task is assigned a status and context. Project assignment is optional.

I find it distasteful to categorize my Status groupings as Projects for the reasons previously stated in this thread. And I find it equally distasteful to classify these groupings as Contexts. Personally, I use Context groupings to determine the environment (e.g. office, loft) and resources (e.g. phone, labeler) required to execute the task. To manipulate the definiton of Context to include the "status" of tasks, dilutes the effectiveness of both categories.

[duodecad]

Originally Posted by Hoff

That seems like an elegant solution. I imagine an icon below the in-box, or at the top of the project list, with its own icon, labeled "Single Tasks" (which seems as clear as anything I've heard so far). In every other way, it would behave like a project. When I'm processing the In-Box, in the Project column, I choose "Single Tasks" and all is well. Then it would be out of my In-box, show up in contexts, and still be available to work with in Project view - all without a major UI or philosophy change.

chrjohns raises a great point about these single tasks not being related-- now that I think about it, that's spot on-- and Hoff's followup hits the nail on the head. I'd *love* to see something like this in OF.