Single Actions ?
 

Is there a solution on the way for single actions ?
I know it has been discussed before but it doesn't appear yet in OmniFocus.
For me the only change necessary would be a checkbox in the Project inspector saying 'all next actions' which makes all the actions in the project go purple.

From what I've read in those threads concerning single actions, the Religion of GTD permits only one next action per project, regardless of the sequential or parallel setting. I believe one solution that was offered was to use the appropriate filter (available?) to see multiple actions per project. Unfortunately this is a global setting and does not affect the sequential vs. parallel setting. Your suggestion would certainly work.

However, I've noticed that folks have brought up countless issues regarding the use of OF and one solution frequently offered for each issue is to include a preference or checkbox. But how many can we put up with?

If they're ALL next actions, then NONE of them are next actions.

I hope Omni stays canonical (follows GTD principles) for 1.0, and doesn't waste time enabling "cheater" behavior until later...

In a list of single actions every action SHOULD be a next action because the actions are not related to eachother.

In OF I use a parallel project for single actions which means that all actions down from nr 2 are not considered next actions, but in fact they are !

If I put the filter bar in context view on "next" all these next-actions disappear. Now this is not very 'canonical' in my opinion...

[QUOTE=plutones]In a list of single actions every action SHOULD be a next action because the actions are not related to eachother.

In OF I use a parallel project for single actions which means that all actions down from nr 2 are not considered next actions, but in fact they are !

If I put the filter bar in context view on "next" all these next-actions disappear. Now this is not very 'canonical' in my opinion...[/QUOTE]

You currently have two options.

1. Filter for Available actions. That will show exactly the actions you want. Then change the formatting of Available-but-not-Next Actions to match that of Next Actions.

2. Don't assign your singleton actions to projects. Just give them a context and clean them from the inbox. They'll show in context view as next actions, but won't show at all in project view.

[QUOTE=curt.clifton]You currently have two options.
2. Don't assign your singleton actions to projects. Just give them a context and clean them from the inbox. They'll show in context view as next actions, but won't show at all in project view.[/QUOTE]

I have a question about this... I've created an action in the inBox and assigned it a context but no project. Then I clicked the "clean up" tool (I'm not sure if this is what you mean by 'clean them from the inbox' - but this did remove the action from the inBox). I turned on the "next" filter in context view, but this action doesn't show up. If I choose "available" then it does. Am I missing something?

- Pierre

[QUOTE=curt.clifton]You currently have two options.
1. Filter for Available actions. That will show exactly the actions you want. Then change the formatting of Available-but-not-Next Actions to match that of Next Actions.

2. Don't assign your singleton actions to projects. Just give them a context and clean them from the inbox. They'll show in context view as next actions, but won't show at all in project view.[/QUOTE]

Thanks for your suggestions.
1. I did use the available-filter already but got distracted by the different colors of actions with the same status. Your suggestion to use the same formatting does work and I will use it for now. But I do find it a shame to have to sacrifice custom formatting for next actions. I think the Omni people can come up with a more elegant solution...

2. This doesn't work for me, I would like to see a list of single actions in the project view for reviewing purposes.

[QUOTE=pvonk]I have a question about this... I've created an action in the inBox and assigned it a context but no project. Then I clicked the "clean up" tool (I'm not sure if this is what you mean by 'clean them from the inbox' - but this did remove the action from the inBox). I turned on the "next" filter in context view, but this action doesn't show up. If I choose "available" then it does. Am I missing something?[/QUOTE]

No, I was missing something. I actually keep all my singleton actions in a separate singletons project. I had forgotten how non-project actions were formatted. Sorry for the misinformation.

[QUOTE=curt.clifton]No, I was missing something. I actually keep all my singleton actions in a separate singletons project. [/QUOTE]
Yes, that's what I do as well; however, GTD does not require all actions to be in projects. It's only those actions that are part of several others, making up some... project. I think we all understand this, but OF seems to be mainly project-focused at this point.

- Pierre

How about special formatting for singletons? I don't want to see them in project view, and I'm quite happy to have them only available in Context, but it would be nice to be able to identify them at a glance at a context list. A green text maybe?

[QUOTE=pvonk]From what I've read in those threads concerning single actions, the Religion of GTD permits only one next action per project, regardless of the sequential or parallel setting.
[/QUOTE]

Actually, no. In the strictest GTD sense, every single action in your currently active list of actions is a "next action". Those next actions which are also the next logical step in a sequence of actions are highlighted purple, but they're not "more next" than the other "next actions"; they're simply the next step in a sequence. The use of the term "next action" to differentiate between those actions and any other currently active action is arbitrary at best (but an established habit in many GTD apps for some reason). The only thing the highlighting really indicates is that completing that action will result in another action being added to your currently active list of actions (unless it's the last action in the sequence).

A project can have many next actions associated with it, provided that those actions don't have to be completed in any particular order. When you view your list of actions in context view with the "active" filter enabled, you are looking at all of your next actions regardless of what is and isn't highlighted purple. In a pure GTD implementation, that's what next action means; it's any action that can be done right now, and if it can't be done right now it shouldn't be active.

It sounds like what you guys are using the highlight for is to prioritize your actions. It's like the first action in a sequence takes precedence over parallel actions (and is therefore "next" in your terminology) unless you have consciously decided (before looking at your context view) to assign the "next" state to one or more of those parallel actions (or arbitrarily assigned that state to all singleton actions). That's not the GTD way.

In GTD, the prioritization of actions occurs when looking at the action list for the currently appropriate context (whatever context you're in right now or will be in soon). You decide [I]right at the moment of action execution[/I] which action needs to be done right now. Complete that action and then look at the list [i]and decide again[/i]. One of the main points of GTD is to free the user from arbitrary prioritization schemes which have to be hierarchically assigned prior to the actual moment of action execution; schemes which require us to predict what will and won't be important at some time in the future rather than allowing us to decide in the moment what is important right now.

The purple highlight currently used for "next actions" (still an overloaded term, I hope Omni calls the style "next steps" or something else in their final build) only indicates the next step of a sequence. Every active action is a next action in GTD sense and has equal precedence on the list. If OF is to be a GTD app, that's really how it should be used. Any other behavior is acceptable if that works for you (hell I do tons of things that aren't in David Allen's book that work for me), but let's not fundamentally alter OF's functionality in any way that breaks it as a GTD app.

For single actions...

I create a project with a context name...

-Project Errands - default context Errands

Then when I need to do an errand that is a single action, I'll just add a task to it.

[QUOTE=brooce]If they're ALL next actions, then NONE of them are next actions. [/QUOTE]

True, but beside the point.

The issue is, SOME projects have actions that can truly be carried out in parallel. Think of cooking a meal of stir-fried beef and peppers. We can do the prep work for the stir-fry in any order -- it doesn't matter whether we cut the red pepper first or the green, or whether we do the garlic before the ginger. So, under the "knife work" sub project, [B]any[/B] task can be the next step, and we might do them in different orders on different days.

However, in the "cook" sub-project, we do have to follow a series of steps in exact order. If we try to cook the peppers first, they will overcook in the time it takes to cook the beef.

Now, if we were to enter this in OF, we'd have, in Project View:

Project: Cook Pepper Beef
Sub-P: Prep Work
Task: cut red pepper Context: Knife
Task: cut green pepper Context: Knife
Task: cut beef Context: Knife
....
Sub-P: Stir-Fry
Task: Cook beef Context: Wok
Task: Cook peppers Context: Wok
Task: add ginger & garlic Context: Wok
....

In Context View, the one we'll see during cooking:

Context: Knife
[COLOR="Purple"]Task: cut red pepper[/COLOR]
Task: cut green pepper
Task: cut beef
...
Context: Wok
[COLOR="Purple"]Task: Cook beef[/COLOR]
Task: Cook peppers
Task: add ginger & garlic
....

Note the purple Next Actions.

If we set the filter to Show next actions, we can't see all the knife tasks, though we want to. But if we set Available Actions, we'd see the Knife tasks for several other meals as well. What we want (well, what I want) is to set ALL the knife work tasks in this project to Next Actions, so I could see them all at once.

[No, I don't plan out my cooking — but this is an example most people can understand.]

--Liz

[QUOTE=LizPf]
If we set the filter to Show next actions, we can't see all the knife tasks, though we want to. But if we set Available Actions, we'd see the Knife tasks for several other meals as well. What we want (well, what I want) is to set ALL the knife work tasks in this project to Next Actions, so I could see them all at once.
[/QUOTE]

If you want to see all those tasks but exclude those for other meals, couldn't you Focus on this project and then view Available?

[QUOTE=brooce]If they're ALL next actions, then NONE of them are next actions.[/QUOTE]

This isn't quite right, though, for reasons others (MEP, LizPf) have articulated. The clearest counter-example to your assertion, though, is the following:

I may have 3 "available" actions (in OF parlance) in a project, each in a different context. [B]Each[/B] one of those actions would be the "next" action for that project in its particular context.

So the current notion of "next" action in a parallel project seems like it will in fact hide the next action in that project that [I]I could be doing[/I] in my current context, if it just so happens that the "next" action is assigned to a different context.

A lot of the current work-arounds discussed above require focusing on a project, which kind of breaks the GTD context model (i.e. what's the entire set of things I could be doing right now?).

Maybe "next" should mean something different in Project vs. Context view? In "Project" it might be the next available task (to your point), but in "Context" it might be the next available task (if any) in the selected context.

Maybe OF already behaves this way? I'm still anxiously awaiting entry into the alpha club.

[QUOTE=pvonk]Yes, that's what I do as well; however, GTD does not require all actions to be in projects. It's only those actions that are part of several others, making up some... project. I think we all understand this, but OF seems to be mainly project-focused at this point.[/QUOTE]

I'm not sure I agree with this assessment. I have plenty of single actions in my context lists, and work just fine out of them.

Ethan Schoonover, in one of his marvelous screencasts, said that the easiest way he found to use OmniFocus is to use the Project view for planning (figuring out what the next actions are, etc.) and the Context view for actually working out of.

If I understand the "canonical" GTD system correctly, the primary focus should be on your Next Actions and Next Action lists; that is the "horizontal view" he describes, where you see where you are in all of your projects so you can decide which NA to do, as opposed to looking the "vertical view" of the breadth of a single project (or group of projects) in Projects view.

(Of course, none of this should be construed as how you [i]must[/i] use OF; I'm speculating on some of the design decisions that have been made.)

[QUOTE=jelmore] the easiest way he found to use OmniFocus is to use the Project view for planning (figuring out what the next actions are, etc.) and the Context view for actually working out of.
[/QUOTE]

Yes, I use the project view to plan and for maintenance. I also like the overview of all projects currently active. But that's the problem. Theoretically, single actions don't belong to a project, hence they shouldn't show up in any project view, which means I'm not getting an overview of everything. We need a more general "view" in place of the projects, or, within the choices of projects, we need an "all projects and singletons".

- Pierre

[QUOTE=pvonk] We need a more general "view" in place of the projects, or, within the choices of projects, we need an "all projects and singletons".

- Pierre[/QUOTE]

I brought this up a while ago.

[URL="http://forums.omnigroup.com/showpost.php?p=15904&postcount=46"]Change Project Name[/URL]

However, it seems difficult because this would be a major change now since everyone is used to having a view called [B]Project[/B].

[QUOTE=Terry]I brought this up a while ago.

[URL="http://forums.omnigroup.com/showpost.php?p=15904&postcount=46"]Change Project Name[/URL]

However, it seems difficult because this would be a major change now since everyone is used to having a view called [B]Project[/B].[/QUOTE]
I agree with Terry's observations in the post he links above. I've also brought this up:

[URL="http://forums.omnigroup.com/showthread.php?t=3774"]Showing tasks with "No Project"[/URL]

Specifically, I wrote:

[QUOTE=Paul Hoadley]Calling it "project view" is somewhat arbitrary---it could just as well be called "task view", and projects just happen to be the way we group sets of related tasks.[/QUOTE]

Just today I've hit another wall with singleton tasks: you can't search for them in Project View—they're completely invisible in this view. I don't want to get into another argument about whether this is somehow the canonical behaviour for something called "Project View", because as several of us have noted now, that's pretty much an arbitrary name for that view. In my opinion, at least, it's certainly [I]unexpected[/I] behaviour from a general UI point of view. I can enter a singleton task via the Inbox while in Project View, but after cleanup, it becomes invisible and is unsearchable. It certainly caused some wasted time for me this afternoon—I ended up creating some duplicates of tasks I couldn't find, but which turned up later when I was in Context View.

[QUOTE=Paul Hoadley]Just today I've hit another wall with singleton tasks: you can't search for them in Project View—they're completely invisible in this view.[/QUOTE]

We're planning to make every action be visible in both project and context view, rather than only having them be visible in*the corresponding view when they have an assigned project or context.

Actions with no project (aka singleton actions) will go into some sort of "quick list" smart group in project view, and single actions will probably have their own style (colored blue?) in both project and context view.

Actions with no context will go into a smart group in the context view (perhaps the "Unassigned" context, or maybe just the "No context" context?).

Does that help?

[QUOTE=Ken Case]Does that help?[/QUOTE]
It certainly sounds good to me.

[QUOTE=Ken Case]Actions with no project (aka singleton actions) will go into some sort of "quick list" smart group in project view, and single actions will probably have their own style (colored blue?) in both project and context view.[/QUOTE]

I'm wondering if we will be able to assign actions to [B]folders[/B] but not projects, so that we could somehow have these one of these blue smart groups for each folder.

I use folders for "areas of responsibility" and I have recently changed from having one big "singletons" category to "singletons-father," "singletons-homeowner," etc., each in the corresponding folder. (I did this to break up the huge singletons project, and to put a little check on whether little things I'm adding to the system actually fit within my areas of responsibility. It also allows me to include singletons when Focusing on one of those areas.)

If Omni is going to arrange distinct formatting for single actions, I hope they can accommodate this type of setup - it would be useful (to me at least) to be able to assign actions to folders while still having them recognized as single actions.

[SIZE="1"][sent via feedback][/SIZE]

[QUOTE=Ken Case]We're planning to make every action be visible in both project and context view, rather than only having them be visible in*the corresponding view when they have an assigned project or context.

Actions with no project (aka singleton actions) will go into some sort of "quick list" smart group in project view, and single actions will probably have their own style (colored blue?) in both project and context view.

Actions with no context will go into a smart group in the context view (perhaps the "Unassigned" context, or maybe just the "No context" context?).

Does that help?[/QUOTE]

I would like to be able to hide that smart group in Projects, as I have no desire to have a group of pansy single actions cluttering up my planning area. I can see value in being able to [I]search[/I] for project-less tasks in Project View, but I really don't want to see them.

As for context-less tasks, I also prefer the current status quo - that they are not actionable at all and remain in (or return to) the inbox. If it doesn't have a context, I haven't properly processed the item.

[QUOTE=GeekLady]I would like to be able to hide that smart group in Projects, as I have no desire to have a group of pansy single actions cluttering up my planning area. [/QUOTE]

Again this begs the question of why we use "project" view for everything. There are projects (and their actions) which may form a subset of all actions. There should be some "maintanance" view that lists every action and we could use the filters to view the actions that fall into certain subsets, like those in projects, those not due, those in folders, those not in projects, etc.

Pansy single actions? We don't have no steenking pansy single actions!

[QUOTE=pvonk]Again this begs the question of why we use "project" view for everything. There are projects (and their actions) which may form a subset of all actions. There should be some "maintanance" view that lists every action and we could use the filters to view the actions that fall into certain subsets, like those in projects, those not due, those in folders, those not in projects, etc.

Pansy single actions? We don't have no steenking pansy single actions![/QUOTE]
I confess, I don't really see the need for some overarching maintenence view.

Right now, we have a view for planning and a view for working. I think OF needs a separate view for input, an Inbox View. The Inbox is where I do 'task maintenence', if you want to call it that, I don't. In my opinion, single actions shouldn't need maintenence, and projects can be worked on in the planning view.

I am hungry for better ways to move between and focus on tasks, projects, and contexts in ALL views. For instance:
1. The only way to make a task into a project in context is to give it a context of none, which sends it back to the inbox, then you can promote it to a project.
2. Singletons show up in context when you've focused on a project
3. You can't convert a project's task into a single task easily
4. There's no clear way to send things back to the inbox.

The idea of having a 'maintenence' view bugs me, no matter how nicely it could be sorted, because I can't find a purpose for it other than to collect [I]everything[/I] and shove it in my face.

[QUOTE=GeekLady]
I am hungry for better ways to move between and focus on tasks, projects, and contexts in ALL views. For instance:
1. The only way to make a task into a project in context is to give it a context of none, which sends it back to the inbox, then you can promote it to a project.
2. Singletons show up in context when you've focused on a project
3. You can't convert a project's task into a single task easily
4. There's no clear way to send things back to the inbox.
[/QUOTE]

For now, #2 and #3 can be solved by making a "singletons" parallel project.

[QUOTE=Craig]For now, #2 and #3 can be solved by making a "singletons" parallel project.[/QUOTE]
:-) except my hatred of "Single Action" projects outweighs those two inconveniences. I hated it in kGTD too. And I'm awfully stubborn.

I understand that there are people who want that special project for singletons, and their opinions are just as valid as mine. I'm just begging that it please, please, please be hideable, because I really hate the idea of seeing single actions in my planning space.

[QUOTE=GeekLady]The idea of having a 'maintenence' view bugs me, no matter how nicely it could be sorted, because I can't find a purpose for it other than to collect [I]everything[/I] and shove it in my face.[/QUOTE]
And I don't like the idea of a black box that I have no control over, no ability to maintain the hidden database. For me, there are times when I have to do a major reconfiguration of portions of my task structure due to changing events around me. If I can't get an "overall" view of all my tasks, not just those in projects, then I can't organize with confidence.

There was a post by Paul (earlier in this thread) who stated "I can enter a singleton task via the Inbox while in Project View, but after cleanup, it becomes invisible and is unsearchable."
This concerns me!

The ideas that Omni has proposed above seemed okay, until Craig brought up a scenario that may cause problems. But Omni seems to be studying this issue; we'll have to see what they come up with.

[QUOTE=GeekLady]... I really hate the idea of seeing single actions in my planning space.[/QUOTE]

I'm curious, you don't use single actions?

[QUOTE=pvonk]I'm curious, you don't use single actions?[/QUOTE]
Oh, I use them all the time. But they don't need planning, so I don't want to see them in Project view, that's planning mode. I only want to see them in doing mode, context view.

[QUOTE=GeekLady]Oh, I use them all the time. But they don't need planning, so I don't want to see them in Project view, that's planning mode. I only want to see them in doing mode, context view.[/QUOTE]
Ah, I see. Unfortunately for me, I frequently have singletons that really are single actions until a new directive comes down to me that suddently incorporates that action into others that I suddenly become responsible for. That's when I have to go back to the drawing board.

I've been re-reading GTD, and I don't find any discussion of dynamic events. The examples I find are all static, a perfect world where things don't change. Perhaps I'm missing some crucial pages or just getting info-overloaded.

[QUOTE=GeekLady]
I understand that there are people who want that special project for singletons, and their opinions are just as valid as mine. I'm just begging that it please, please, please be hideable, because I really hate the idea of seeing single actions in my planning space.[/QUOTE]

If there is a pseudo-folder in project view for Singletons, would it meet your needs to just collapse the pseudo-folder?

[QUOTE=GeekLady]... I have no desire to have a group of pansy single actions cluttering up my planning area.[/QUOTE]
I actually laughed out loud.

[QUOTE=Ken Case]We're planning to make every action be visible in both project and context view, rather than only having them be visible in*the corresponding view when they have an assigned project or context.

Actions with no project (aka singleton actions) will go into some sort of "quick list" smart group in project view, and single actions will probably have their own style (colored blue?) in both project and context view.

Actions with no context will go into a smart group in the context view (perhaps the "Unassigned" context, or maybe just the "No context" context?).

Does that help?[/QUOTE]
Yay! Exactly what I was hoping for.

I have to say that the difference between a view with everything and a view with everything except single action would be quite small for me. My planning space is already too big to work with all at once. I love that I can just select one or a couple folders/projects and do my planning with a divide-and-conquer methodology. I imagine a psuedo-project for single actions would be pretty easy to ignore, as I typically ignore 80-90% of my projects at any given moment as is.

[QUOTE=pvonk]I've been re-reading GTD, and I don't find any discussion of dynamic events. The examples I find are all static, a perfect world where things don't change. Perhaps I'm missing some crucial pages or just getting info-overloaded.[/QUOTE]

I'm not sure what you mean by dynamic events, but the whole concept of "mind like water" is about being able to react appropriately to things as they come at you. If you inherit a new bunch of tasks, you figure out what to do with them and put them in the appropriate places (defer, delegate, add to action lists or project lists as needed).

How and when you do that are left up to the urgency of the tasks and the intuition of the person; I think David Allen favors the "toss it into your Inbox and deal with it when you have the time" approach, but circumstances may force you to stop and prcoess it [i]right now[/i], which is okay too.

I think David Allen deliberately keeps GTD-the-book light on specific implementations because people need to adopt a system that will be comfortable to them and because people like to nitpick specifics, which distracts them from seeing the system as a whole...

GeekLady:
2. Singletons show up in context when you've focused on a project
3. You can't convert a project's task into a single task easily

[QUOTE=Craig]For now, #2 and #3 can be solved by making a "singletons" parallel project.[/QUOTE]

But the way things are set up, tasks in a parallel project aren't parallel, not really.

If they were, they'd all be next actions, and show up in my context view. Instead, the top item is "Special", and I see none of the others.

If I were in charge, I'd add another project type, so we'd have parallel, sequential, and All Next Actions. Parallel would be intended for complex projects with many sub projects where actions could be done in any order, sequential is for step-by-step things, and All Next Actions would be for projects where we can do any of the items, in any order, and want to see them all as Next Actions.

We could set up our singletons in our choice of one ANA project, or set up several Singleton projects anywhere in our Project structure.

Then again, I'm not in charge here.

--Liz

[QUOTE=jelmore]I'm not sure what you mean by dynamic events, ...[/QUOTE]
At times, everything in a project changes. There may be new duties to attend to that impact existing tasks. For example, a project to establish a new Advising Sciences Web Site for incoming freshmen at our college may suddenly change to a global Sciences Web Site. Existing tasks in the current project and subprojects may need to be reassigned to new subprojects, merged with other new tasks, or removed altogether, since the college's web group has taken over part of the work. This requires a mantenance view in which I need to see projects and singleton tasks (there have been some) and reorganize.

I don't think GTD-book gets into such redesign of projects/tasks in a methodical way.

[QUOTE]I don't think GTD-book gets into such redesign of projects/tasks in a methodical way.[/QUOTE]

Sequel!

;)

There's too much to quote here and it would make this even longer, so here goes nothing.

First of all, nothing should ever be unsearchable, whereever you are in the application. However that single actions aren't searchable in projects is a limitation of the search, not of the projects view. The same problem exists when you search for something that is hidden by your current filter settings.

Second, I don't like the idea of a maintenence view because I don't think it fits well into the GTD concepts. If something has gotten to the point that it requires such extensive reworking as you describe, I much prefer to send it back to the inbox for a proper reprocessing.

Third, when I want an overview, I look at my context view, because it [I]does[/I] contain everything. It is my jello landscape, tasks that need to be done, but don't have the scheduling cojones to live on the hard landscape. And I can't even begin to wrap my brain around a task that doesn't have a context.

Now I understand I'm the only person here that doesn't want to see single tasks in Project view, and I'm not campaigning against you guys. I'm just begging that there be a preference to hide the Project-less tasks Project and the Context-less tasks Context. The concept already annoys me, but being able to make them hidden but active would make everybody happy I think.

[QUOTE=LizPf]If they were, they'd all be next actions, and show up in my context view. Instead, the top item is "Special", and I see none of the others.

If I were in charge, I'd add another project type, so we'd have parallel, sequential, and All Next Actions.[/QUOTE]

Maybe my brain is still running slowly, but I don't see why you can't just use the "Available" filter if you want to see all the actions you can do in a parallel project or subproject: that is, all actions that are logically next (they're available) but not necessarily semantically next (I really think they're next on my plate even though I could skip them and do something else further down the list).

It seems to me easier to use the filter instead of creating a new kind of project.

Available will show [B]all[/B] of my un-done tasks.

I have lots of tasks that I don't need to see on a day-to-day basis, such as my shopping list for my upcoming trip to IKEA. I'll get there sometime in the next 6 months, but I sure don't need to see those items/tasks now.

--Liz

[QUOTE=LizPf]Available will show [B]all[/B] of my un-done tasks.[/QUOTE]

Available shows all actions in a parallel project but only the first action in a sequential project. Remaining shows all un-done tasks.

I must not understand the difference between your ANA projects and parallel projects. Can you say more about that?

[QUOTE=LizPf]
I have lots of tasks that I don't need to see on a day-to-day basis, such as my shopping list for my upcoming trip to IKEA. I'll get there sometime in the next 6 months, but I sure don't need to see those items/tasks now.[/QUOTE]
Could this be where marking contexts as inactive could help?

[QUOTE=curt.clifton]Available shows all actions in a parallel project but only the first action in a sequential project. Remaining shows all un-done tasks.

I must not understand the difference between your ANA projects and parallel projects. Can you say more about that?[/QUOTE]

An example:

I have a long list of household tasks -- fix the doorbell, repair a chair, unpack some more boxes from our move 2 years ago, clean the undersink cabinet ... there are maybe 30 tasks like this.

I also have a short list of weekly tasks to do for my online t-shirt shop: upload to Google Base, add a new design, check my web page stats ... maybe 5 tasks.

Right now, both Projects are parallel. If these were the only things in my OF file, my context view/next actions would show 2 items; the available view shows 35. I really don't need to see all my household tasks all the time, but I do want to see my shop tasks.

If I could, I'd leave the Household tasks Parallel, and switch my shop tasks to All Next Action. Then I'd have 6 items showing in my Context/NA — the 5 shop tasks I need to do this week, plus a Household task.

Now, add my 15 other big projects, and you can see how having an ANA setting can let me focus on the stuff I [B]*have*[/B] to do, not the stuff I kind of have to do. Make sense?

And I know there are other ways to do lots of this, by futzing with dates, flags and the like -- but the ANA concept makes a lot of sense to me.

--Liz

[QUOTE=LizPf]
I have a long list of household tasks -- fix the doorbell, repair a chair, unpack some more boxes from our move 2 years ago, clean the undersink cabinet ... there are maybe 30 tasks like this.

I also have a short list of weekly tasks to do for my online t-shirt shop: upload to Google Base, add a new design, check my web page stats ... maybe 5 tasks.

Right now, both Projects are parallel. If these were the only things in my OF file, my context view/next actions would show 2 items; the available view shows 35. I really don't need to see all my household tasks all the time, but I do want to see my shop tasks.

If I could, I'd leave the Household tasks Parallel, and switch my shop tasks to All Next Action. Then I'd have 6 items showing in my Context/NA — the 5 shop tasks I need to do this week, plus a Household task.[/QUOTE]

Thanks, Liz. That example helps.

If I understand correctly, you could make the Household tasks sequential and use the Available view. But there are two problems with that: (1) you would be stating a false dependency between those tasks and (2) you wouldn't have an easy way to view just the 35 tasks.

I use flags for this sort of focusing, but it doesn't exactly solve the problem. For example, I'd flag the shop project and use an Available+Flagged view. But that wouldn't show any household tasks.

Hmm, what if there was a way to view Next Actions plus Available, Flagged Actions?

You know, if flagging a task would override task ordering and automatically set a task as a next action, it would be the first useful thing flagging a task ever really did.

[QUOTE]Hmm, what if there was a way to view Next Actions plus Available, Flagged Actions?[/QUOTE]

[QUOTE=GeekLady]… it would be the first useful thing flagging a task ever really did.[/QUOTE]

What?!?

Flagging is already [B]extremely[/B] useful as is. Since separate filtering on flags was added, flagging has been a key part of my system. At the beginning of the month I flag the projects that support my goals for the month. (You just have to flag the top-level project; children inherit the flags.) If my weekly review, or my gut instinct, says that I'm not making good progress on monthly goals, then I turn on the Flagged filter in context view. This lets me really focus on my key priorities.

[QUOTE=GeekLady]Now I understand I'm the only person here that doesn't want to see single tasks in Project view[/quote]

No you're not. :) If a task can be accomplished in a single physical action, surely by definition it isn't a project? In a paper GTD implementation these single tasks would definitely not be in your Projects list.

I also agree that tasks with neither project nor context should stay in the inbox, as their processing is incomplete: you have neither done, delegated (it'd be in @waiting for) or deferred (it'd be in a context).

[quote=GeekLady]I'm just begging that there be a preference to hide the Project-less tasks Project and the Context-less tasks Context. The concept already annoys me, but being able to make them hidden but active would make everybody happy I think.[/QUOTE]

Being able to collapse the view of these down to a folder would be fine, but I agree that these two views are unnecessary.

[QUOTE=al_f]I also agree that tasks with neither project nor context should stay in the inbox, as their processing is incomplete: you have neither done, delegated (it'd be in @waiting for) or deferred (it'd be in a context).
[/QUOTE]

I agree on this too.

Those two views are worse than unnecessary; they're between OmniFocus and SHIPPING!

Defer those non-canonical boondoggles to 2.0.

[QUOTE=curt.clifton]What?!?

Flagging is already [B]extremely[/B] useful as is. Since separate filtering on flags was added, flagging has been a key part of my system. At the beginning of the month I flag the projects that support my goals for the month. (You just have to flag the top-level project; children inherit the flags.) If my weekly review, or my gut instinct, says that I'm not making good progress on monthly goals, then I turn on the Flagged filter in context view. This lets me really focus on my key priorities.[/QUOTE]

Heh, so that's how you prioritize. I'm sorry, I started using OF flags to prioritize so I could sort important things to the top, and then within 2 days they got moved to their own filter and I gave up in disgust.

Anytime soon?
 

[QUOTE=Ken Case;17180]We're planning to make every action be visible in both project and context view, rather than only having them be visible in*the corresponding view when they have an assigned project or context.

Actions with no project (aka singleton actions) will go into some sort of "quick list" smart group in project view, and single actions will probably have their own style (colored blue?) in both project and context view.

Actions with no context will go into a smart group in the context view (perhaps the "Unassigned" context, or maybe just the "No context" context?).

Does that help?[/QUOTE]

I really hate the way omnifocus deals with single tasks. When I heard of this solution I was thrilled and decided to wait until it was implemented to try omnifocus again.

Almost a month later and I haven't heard word of its inclusion. Can someone from omni tell me if this is still planned? And if so, any idea when?

I feel as if, in recent builds, the concept of the singleton/single action/atomic task is getting relegated to second-tier status in favor of projects.

It used to be that I could go to context view, pick a context, and add a whole host of next actions by hitting Return after each line item -- which is useful if I'm processing my physical inbox or other collection bucket, or creating a quick shopping list in one of my contexts.

Then actions with a context and no project became inactive actions, which can only be seen if you're viewing remaining or all actions. Somewhere around the same time, hitting Return to create a new line item in a context broke, and hasn't been fixed as of build 90172.

Then this idea of a "singleton project" appeared. I'm hoping this is a placeholder for a real single-action view because I am now required to either assign a Next Action to my singleton project when I create it using Quick Entry, or I have to:

Create an entry
Send it to the Inbox
Use Clean Up to move it to the context list (and default "singleton project")

This, coupled with the broken ability to create new items directly into a context list, have needlessly complicated the elegant workflow that was present when I first started using OmniFocus.

As I said, I hope the "singleton project" goes away and is replaced by a view similar to the Inbox, and single Next Actions do not have to be intentionally assigned to anything other than the context they inhabit.

I still find Omnifocus an incredibly useful program. I just think the current incarnation is much less easier to use than it was in the beginning.

[QUOTE=al_f;17658]I also agree that tasks with neither project nor context should stay in the inbox, as their processing is incomplete: you have neither done, delegated (it'd be in @waiting for) or deferred (it'd be in a context).[/QUOTE]

Agreed, that makes a lot of sense.

Now, I hope the "singleton project" concept stays, it's a nice, useful concept,that I have high hopes of being able to implement a digital Tickler file with.

But I absolutely, positively refuse to lump all of my single actions together in one bucket project just because they are alone. It's an awful idea having to set up the proper implementation of single actions when they used to work PERFECTLY before they were fiddled with.

Now you can't even remove a task from your inbox unless it has a project, which is so bassackwards I can barely function in OF anymore.

[QUOTE=jelmore;19471]
As I said, I hope the "singleton project" goes away and is replaced by a view similar to the Inbox, and single Next Actions do not have to be intentionally assigned to anything other than the context they inhabit.[/QUOTE]

GeekLady, when you say they worked perfectly, was that when actions without projects showed up in context lists?

I liked that "no project, context assigned"=="do-able item". But it wasn't perfect, because I rely heavily on the folder focus, and focusing on a folder meant no single actions showed up. So I had to use the "project for singletons" idea anyway. I disliked that very much, especially that the first one was a next action. This is a *slight* improvement.

I really want to leave the project blank, but tag an action as belonging to a certain folder. That would be my perfect solution. I don't know if that's possible given the "folder" implementation.

[QUOTE=anna;19689]I really want to leave the project blank, but tag an action as belonging to a certain folder. That would be my perfect solution.[/QUOTE]

That's my wish, too.

[QUOTE=anna;19689]...
I really want to leave the project blank, but tag an action as belonging to a certain folder.[/QUOTE]


What is the barrier to having these tasks just be individual projects under a folder. Is it that there are too many to scroll through, is it that they don't have the right behavior in Context view? I'd like to hear a discussion about this and why some folks have gravitated towards using singletons.

[QUOTE=pjb;19693]What is the barrier to having these tasks just be individual projects under a folder. Is it that there are too many to scroll through, is it that they don't have the right behavior in Context view? I'd like to hear a discussion about this and why some folks have gravitated towards using singletons.[/QUOTE]

As I understand GTD, a project and an action are two different things conceptually. A project is comprised of two or more actions. A project is more like a goal or a finish line. You can't actually "do" a project; you can only "do" the (or a) next action for that project.

Single actions could be placed in a project, but sometimes just a list of single actions is quicker and easier to create and complete. But then, maybe I just haven't thought through my projects (or roles) clearly enough.

[QUOTE=pjb;19693]What is the barrier to having these tasks just be individual projects under a folder. Is it that there are too many to scroll through, is it that they don't have the right behavior in Context view? I'd like to hear a discussion about this and why some folks have gravitated towards using singletons.[/QUOTE]

I currently have 82 singleton actions in my system. Adding them as items under folders would quadruple the size of my project listing. Also, projects don't show up in context view at all.

I find that singleton projects work fine for me. I look forward to a better bucket icon. I strongly agree that the default behavior of QuickEntry items bypassing the inbox is broken.

I understand that you want singletons to show up in you folders and you did need a solution. I'm glad you have one, and I'm glad that it's nice a flexible solution that can be put to all sorts of different purposes. But it's just not an excuse for completely destroying any ability to have properly projectless actions.

Right now, having a project is an absolute requirement for a task to become actionable, but it doesn't need a context, it's just ridiculous.

[QUOTE=anna;19689]GeekLady, when you say they worked perfectly, was that when actions without projects showed up in context lists?

I liked that "no project, context assigned"=="do-able item". But it wasn't perfect, because I rely heavily on the folder focus, and focusing on a folder meant no single actions showed up. So I had to use the "project for singletons" idea anyway. I disliked that very much, especially that the first one was a next action. This is a *slight* improvement.

I really want to leave the project blank, but tag an action as belonging to a certain folder. That would be my perfect solution. I don't know if that's possible given the "folder" implementation.[/QUOTE]

[QUOTE=GeekLady;19705]Right now, having a project is an absolute requirement for a task to become actionable, but it doesn't need a context, it's just ridiculous.[/QUOTE]

I'm not seeing this behavior. The first part fits - an action must have a project to become actionable. (If this seems absurd, a perfectly good workaround is to call your default singleton project "None.") But the second doesn't. If I don't give an action a context, it doesn't become actionable (available).

It will leave the Inbox when cleaned up. I presume the current behavior is based on the presumption that, if you assign a project but not a context to an action, you intend to decide on the appropriate context when you review the project. There should be a preference to control Inbox behavior so that users whose workflow doesn't fit this assumption can change it.

I have to agree with those who argue that much of the power of the Focus command would be lost if there were no singleton buckets within folders. Putting individual actions in folders is certainly the logical way to do it, but from my perspective, Curt is right to point out that it would be a UI nightmare.

Okay, I was too busy ranting to be completely accurate, items without a context don't become actionable, but if they have a project, they leave the inbox, which my pea brain interprets as 'fully processed and ready for action upon completion of prerequisites'

My apologies.

In another thread I was complaining about the direction Omnigroup was heading with how omnifocus deals with single actions. I mistakenly believed that a project had to be given for an inbox item to be cleaned out. I didn't realize I had to create a default single bucket. Now that I realize that, I'm much happier.

If I had my wish there would be a default singles bucket already out of the box and not under projects. It would be on the same level as the inbox and projects.

In my opinion it is absolutely not logical to have single buckets in folders. The folders are under projects and should hold projects. Single actions are not projects. In this case, however, functionality, and the fact that others will use omnifocus differently, trumps logic.

I'm resigned to, and ok with, losing that fight. If we can only make all single bucket tasks next actions I'll be happy.

[QUOTE=GeekLady;19705]. . . But it's just not an excuse for completely destroying any ability to have properly projectless actions.[/QUOTE]

True! I wonder why they don't still allow projectless actions, even with the singleton-bucket implementation? (Especially since context-less actions are allowed.)

(And pjb, these are really, REALLY not projects. They are immediately do-able items. Simple do-able items, that definitely need to show up in the context lists. Projects require planning/thinking/organizing. I look through my project lists to find out what big things I'm working on, what requires thought. "Do Laundry" should not be there.)

[QUOTE=gary;19721]
If I had my wish there would be a default singles bucket already out of the box and not under projects. It would be on the same level as the inbox and projects.

In my opinion it is absolutely not logical to have single buckets in folders. The folders are under projects and should hold projects. Single actions are not projects. In this case, however, functionality, and the fact that others will use omnifocus differently, trumps logic.

I'm resigned to, and ok with, losing that fight. If we can only make all single bucket tasks next actions I'll be happy.[/QUOTE]

A default singles bucket at the top level is a good idea. But I don't buy that single buckets in folders is "not logical". I use folders to group my tasks into major life roles. Having singleton buckets under each role is very useful to me.

[QUOTE]But I don't buy that single buckets in folders is "not logical". I use folders to group my tasks into major life roles. Having singleton buckets under each role is very useful to me.[/QUOTE]

It's not logical to me only because folders are under the title of projects. So it would seem only projects go in folders. Nitpicking I know.

But doesn't mean it isn't logical in the way you use it, and I don't want omni to take away functionality that is useful. I'm glad it's there for you to use.

I'd love a top level, default, singles bucket to be available when checked in the preferences, which vanishes when unchecked, and the ability to creat new singles buckets under projects if the user chooses. But the current implementation may be the closest I get, and I'm ok with that.

[QUOTE=GeekLady;19713]...if they*[actions] have a project, they leave the inbox, which my pea brain interprets as 'fully processed and ready for action upon completion of prerequisites'[/QUOTE]

It's not a pea-brain thing, it's a matter of what works for your workflow. I can see good GTD-compatible arguments for either approach, which is why I think it should be a preference. Those who think, "I've assigned this task to a project, so I'll think about its context during the review," and those who think, "I want this in the inbox until it is good to go," could both be accommodated. That seems exactly the kind of preference that would allow the user to fine-tune her or his interaction with OF without adding needless bells and whistles.

I'm also seeing this whole debate as a problem with the definition of Project.

Sounds like most people are defining Project as: the group of actions that, when taken all together, meet a definite goal. Examples: Prepare 2008 budget, Vacation to Hawaii, etc.

But, what if we re-define Project to: a group of items that have a reason to be classified together. Goal isn't necessarily part of the definition. Examples: House Cleaning (a group of repeating single actions), Daughter (single tasks I need to do for/with my daughter), Subaru (a standing project, sometimes empty, with actions I need to take regarding my car).

Actions for the second group are often very different in how we enter them from actions in the first group. With the first, an action might be: figure out what format the President wants the numbers in this year (this would probably be an action group, with more planning needed). The second: Call dealer for appointment to fix the seat adjuster.

We need the Inbox to hold ideas for group 1 actions, but we also need a quick and dirty way to get group 2 items where they belong.

We also need to realize that different people have different proportions of items in each group. I live in Group 2, with a very occasional Group 1. Other people are the opposite. OF handles my Group 2 actions well, but it needs to make the Group 1 folk happy without complicating group 2 stuff.

--Liz

[QUOTE=LizPf;19916]But, what if we re-define Project to: a group of items that have a reason to be classified together. Goal isn't necessarily part of the definition. Examples: House Cleaning (a group of repeating single actions), Daughter (single tasks I need to do for/with my daughter), Subaru (a standing project, sometimes empty, with actions I need to take regarding my car).[/QUOTE]

I'd call those "areas of responsibility" with associated projects, i.e. put them at the 20,000ft level rather than at the 10,000ft "projects" level. For example, your car example "Call dealer for appointment to fix seat adjuster" is probably really a next action in the project "Repair seat adjuster on car". Similarly, I'd say that "figure out what format the President wants the numbers in this year" is also a project in the GTD sense.

What I would really like is a per-singleton-bucket configuration that will let me control the behavior of which tasks are considered "next".

1) The current behavior is that NO tasks in a singleton bucket are considered "next actions".

2) Some have requested the ALL tasks in the singleton bucket be considered "next actions".

3) But, frankly, I can see the use for making the singleton bucket behavior more like a normal project, i.e. only the first single task should be considered the "next action". (This is handy when the singleton task list grows very very large and begins to overwhelm your context view.)

I realize regular projects behave like #3, but I can't tell the inbox to shuffle projectless tasks into a regular project.

And I may from time to time wish to change the behavior of my singleton bucket.

So this seems like a good candidate for a drop-down menu in the project inspector, perhaps even applicable to all projects (although this would definitely break the GTD system for normal projects).

E.g. "Next action: (all|none|first)"

[QUOTE=pjc;19922]3) But, frankly, I can see the use for making the singleton bucket behavior more like a normal project, i.e. only the first single task should be considered the "next action". (This is handy when the singleton task list grows very very large and begins to overwhelm your context view.)[/quote]

I think the vision of singleton actions is as single-step tasks that are independent of each other. If that's the case, why would you consider only one of them as a next action i.e. something you can move on now?

[quote=pjc;19922]I realize regular projects behave like #3, but I can't tell the inbox to shuffle projectless tasks into a regular project.[/quote]

That'd be because they aren't part of a project until you assign them one, wouldn't it?

[QUOTE=al_f;19921]I'd call those "areas of responsibility" with associated projects, i.e. put them at the 20,000ft level rather than at the 10,000ft "projects" level. For example, your car example "Call dealer for appointment to fix seat adjuster" is probably really a next action in the project "Repair seat adjuster on car".[/QUOTE]

Depends on how much time you want to spend structuring your life.

To me, the car repair is a 2 action thing: call to schedule, then go @ the right time. One OF action, one Calendar event. [You may have more complications in getting your car to the shop; I don't. If it was more complex for me, I could see making a Project.]

I guess I could spend the time setting up a Project, but I really don't need one, because only one action will show in OF.

I also see the "altitude" levels differently. I see them as Someday/Maybe levels, where each 10,000 feet equates roughly to years in the future. So 10k feet would be things I might want to do next year (camping in Acadia Park), 20k would be things I'd like to do in 2-5 years etc. Car Maintenance is too immediate for this.

--Liz

[QUOTE=LizPf;20040]I also see the "altitude" levels differently. I see them as Someday/Maybe levels, where each 10,000 feet equates roughly to years in the future. So 10k feet would be things I might want to do next year (camping in Acadia Park), 20k would be things I'd like to do in 2-5 years etc. Car Maintenance is too immediate for this.[/QUOTE]

Fair enough if it works for you, but neither that nor your definition of projects fits with GTD so it shouldn't be the way OF implements those features.

[QUOTE=pjc;19922]What I would really like is a per-singleton-bucket configuration that will let me control the behavior of which tasks are considered "next".

So this seems like a good candidate for a drop-down menu in the project inspector, perhaps even applicable to all projects (although this would definitely break the GTD system for normal projects).

E.g. "Next action: (all|none|first)"[/QUOTE]

I'd just like to say that this sounds like a fantastic idea. I'd really love this to be included in OmniFocus! :)

[QUOTE=LizPf;20040]Depends on how much time you want to spend structuring your life.

To me, the car repair is a 2 action thing: call to schedule, then go @ the right time. One OF action, one Calendar event. [You may have more complications in getting your car to the shop; I don't. If it was more complex for me, I could see making a Project.]
--Liz[/QUOTE]

See, while I would agree that getting your car repaired involves more than one action, I still wouldn't make it a project, because most of the actions end up on my calendar.

I'd have the first task "call to make an appointment" in my task list, and once I had an appointment, it wouldn't end up in back in my task list, it would end up on my calendar as an appointment. And I never give my car to someone without knowing when they're planning on giving it back, so dropping my car off gives me another calendar appointment - this may change, but it's still hard landscape and doesn't go on my task list. A task may evolve from this if the broken bit is hard to fix, but until the task is ncessary it doens't go into my lists.

I keep my GTD system as unstructured as absolutely possible because I can drown myself in obsessive details and never even notice.

Unfortunately this is why OF is completely unusable for me at the moment - requiring tasks to have ficticious details to process them is what I cannot tolerate in my system - it's exactly the behavior I'm desparately trying to avoid.

[QUOTE=al_f;19925]I think the vision of singleton actions is as single-step tasks that are independent of each other. If that's the case, why would you consider only one of them as a next action i.e. something you can move on now?[/QUOTE]

Because OF has a distinction between "Next" actions and "Available" actions. I want them all to be available, because, as you rightly observe, I can move on any of them now.

However, one of the benefits of "Next" actions over "Available" actions is in clearing the clutter. You could be doing any of your available actions, but "next" actions are simply the available actions you've designated as the next one to tackle.

Because I have so many available actions, I tend to have my active to-do list show only next actions (a much more manageable list I can spontaneously prioritize). Because singleton "projects" have no next actions, they don't show up in my to-do list.

[QUOTE]That'd be because they aren't part of a project until you assign them one, wouldn't it?[/QUOTE]

I agree that this would be a little bit of a misuse of a project, but then again, so is making a singleton "project" bucket. I offered this as a simple implementation alternative to customizable next-action behavior within singleton buckets: simply remove the restriction of sending project-less tasks only into singleton buckets. It would effectively be assigning a default project.

I still prefer the flexibility to select all/first/none available actions to be "next" in a singleton bucket.

[QUOTE]I still prefer the flexibility to select all/first/none available actions to be "next" in a singleton bucket.[/QUOTE]

You could actually make this a choice for all projects. I have projects where the top 3 tasks are completely independent of each other and none more important.

But if you did that there's no advantage to the singleton bucket other than the different icon.

[QUOTE=pjc;19922]2) Some have requested the ALL tasks in the singleton bucket be considered "next actions".[/QUOTE]

Which surely is the most logical in GTD terms?

Single actions are by default all next actions aren't they? At least in my head they are! If a task only has one specific step it's got to be a next action as it's an ONLY action!

At present I'm finding it too easy to miss important single actions because my usual 'doing' view would be Contexts->Next Actions. I don't want to be looking at 'Available' as that list could be huge.

[QUOTE=RiK;20566]Single actions are by default all next actions aren't they? At least in my head they are! If a task only has one specific step it's got to be a next action as it's an ONLY action![/QUOTE]

Ken said in another thread that, in the release version, all actions in single action buckets will be next, and that they will have a distinct style so that you can distinguish them (if you wish) from next actions in multi-step projects.

[URL="http://forums.omnigroup.com/showpost.php?p=19556&postcount=32"]http://forums.omnigroup.com/showpost.php?p=19556&postcount=32[/URL]

please elaborate by "clean them from the inbox" what do you mean? if I do that each one appears as it's own project

[QUOTE=kebmo19;20679]please elaborate by "clean them from the inbox" what do you mean? if I do that each one appears as it's own project[/QUOTE]

By "clean them from the inbox," Curt (I think it was Curt) meant use the Clean Up command (Edit > Clean Up). That will move actions out of the inbox and into a project if you have entered a project for it, and into your default single action container if you haven't.

You're correct that if you drag an action out of the inbox and into the sidebar, without dropping it onto an existing project, you will create a new project. That's not what clean up means in OmniFocus, though it can be hard to tell without a manual.

How are singltons not orthodox GTD?
 

It's been a little while, but in my reading of Getting Things Done projects were treated almost as an afterthought. The emphasis was in filing away individual tasks in the daily tickler folders (the "43 folders"). These tasks could be next actions from projects, but he didn't put an excessive emphasis on projectizing everything.

[QUOTE=Frosty Crunch;21966]It's been a little while, but in my reading of Getting Things Done projects were treated almost as an afterthought. The emphasis was in filing away individual tasks in the daily tickler folders (the "43 folders"). These tasks could be next actions from projects, but he didn't put an excessive emphasis on projectizing everything.[/QUOTE]

That's not quite right. A project, in GTD terms, is an open loop that cannot be done in one physical action. "Throw away the brown apple core" is an action, but "Clean up the kitchen" is a project. A list of projects, reviewed regularly, is an essential part of GTD. That's what makes the back-of-the-envelope project planning work: to get things done all you need to do is identify the next single action that will move your open loops toward closure.

The 43 tickler folders are actually a relatively minor aspect of GTD: they're a way of deferring action on an item by sending a message to "future you." But there are other ways of doing that. I seem to recall that Allen, in <i>Getting Things Done</i>, says that some of his clients don't actually use the 43 folders, though he finds them useful.