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.
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!
|
|
FAQ | Members List | Calendar | Today's Posts | Search |
Single tasks solutions | Thread Tools | Search this Thread | Display Modes |
Member
2007-05-17, 01:42 PM
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.
Post 11
|
Member
2007-05-17, 02:31 PM
Quote:
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.
Post 12
|
Quote:
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.
Post 13
|
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.
Post 14
|
Quote:
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...
Post 15
|
Member
2007-05-17, 03:48 PM
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!
Post 16
|
Member
2007-05-17, 04:32 PM
Quote:
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.
Post 17
|
Member
2007-05-17, 04:37 PM
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.
Post 18
|
Member
2007-05-17, 08:15 PM
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.
Post 19
|
Member
2007-05-17, 09:22 PM
Quote:
Post 20
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Feature Request: baseline for single tasks | LostProphet | OmniPlan General | 0 | 2012-08-08 09:09 PM |
Single tasks double in forecast | mogwai1904 | OmniFocus 1 for Mac | 4 | 2012-07-18 01:19 PM |
Is there a way to single tasks 'pop out' to view one at a time? | letega | OmniFocus 1 for Mac | 2 | 2012-04-03 07:29 AM |
Single tasks-OF or something else (Like 2Do)? | Lightstorm | OmniFocus 1 for Mac | 6 | 2010-10-13 10:39 AM |
Exporting single tasks' info like %Done etc | m_arts | OmniPlan Extras | 1 | 2010-03-29 12:09 AM |