Single tasks solutions
 

Thanks to Omni I'm testing omnifocus and I like it so far. However, I can't find a way to incorporate single tasks. I was hoping omni would provide some means, but they haven't. Some tasks simply don't fit into a project mode. I find myself creating projects for tasks that don't need one and that simply complicate things.

So if anyone else has a solution how to deal with single tasks I'd love to hear what you came up with. Thanks.

I've created a project called Single Step Tasks, and set it to parallel tasks.

Set the filter to Available, and you should be able to have a place to put all those single steppers

I had the same thought when I reviewed Ethan's first screen cast. Although I haven't used the actual app yet, I am having a philosophical issue with the way it is set up. IMHO single actions just don't belong grouped together as a project because they are by their nature unrelated. They should start in the inbox and then move out of the inbox to a context list when a context is assigned to them. The user should not be required to assign the actions to a project to move them out of the inbox.

This is something we have been thinking and talking about a lot. We are working on a long term solution, but for now the best thing to do is make a project for single tasks. We welcome any suggestions or feedback you have on this.

[QUOTE=jakeg]So if anyone else has a solution how to deal with single tasks I'd love to hear what you came up with. Thanks.[/QUOTE]

I have a project called "Stay Organized," where I put unrelated tasks. I suppose it might better be called "Keep Head above Water"!

In terms of the interface, though, would it be possible to define a special project, whatever it's called, in which every action was a next action? Because the main problem with creating a "Single Tasks" project is that only the first one shows up in a context list as a next action, when in fact they are all, by their nature, next actions.

[QUOTE=brianogilvie]In terms of the interface, though, would it be possible to define a special project, whatever it's called, in which every action was a next action? [/QUOTE]

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?

[QUOTE=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?[/QUOTE]

Yes, that would make sense. Alternatively, the special single-tasks-collection could display the first [I]n[/I] tasks (hand-ordered by user) as first actions, with [I]n[/I] being a user defined number.

I'm still having a hard time trying to understand how distinguishing "next actions" in ANY parallel project makes any sense...

[QUOTE=Craig]I'm still having a hard time trying to understand how distinguishing "next actions" in ANY parallel project makes any sense...[/QUOTE]

You hand-order the tasks. Or you don't, if you don't care which actions comes up as the next action.

[QUOTE=Craig]I'm still having a hard time trying to understand how distinguishing "next actions" in ANY parallel project makes any sense...[/QUOTE]

You beat me to it.

It seems that having all actions in a parallel project be Next Actions would make it easy to have a parallel project named "Runway" or "Single Actions" or "Next Actions" highlight everything.

(The whole idea of a "parallel project" seems not very GTD-ish to me. But at the same time, OmniFocus doesn't have to adhere strictly to GTD, so long as it's possible to do so by choice.)

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.

[QUOTE=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?[/QUOTE]

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 ([url]http://images.google.com/images?um=1&tab=wi&client=firefox-a&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:official&q=david+allen+workflow+diagram[/url]) 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.

[QUOTE=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.[/QUOTE]

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.

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.

[QUOTE=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.[/QUOTE]

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 [i]sudden changes[/i] 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:

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

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

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!

[QUOTE=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.[/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.

"Single Tasks" sounds good to me
 

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.

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.

[QUOTE=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.[/QUOTE]

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.

[QUOTE=curt.clifton]Let me add to the chorus that every task in a parallel project should be a next action.[/QUOTE]

Let me respectfully disagree. In my way of thinking, a sequential project has tasks that [U]must[/U] be done in order. In a parallel project, tasks don't have that absolute dependency, but I might still decide that some of them are higher priority and drag them into a rough order.

I'd like to keep the first of those designated as the "next action" because, in a [U]practical[/U] sense, it is, even if in a logical sense, all of the tasks are potential next actions. Otherwise, I don't see the point of filtering "next actions" vs. available actions.

OmniFocus allows both, and I'd like to preserve the distinction. That way when I filter next actions, I get the one thing that I either must do next (for sequential projects) or really ought to do next (for parallel projects).

Three Project Kinds Needed?
 

[QUOTE=brianogilvie]Let me respectfully disagree. In my way of thinking, a sequential project has tasks that [U]must[/U] be done in order. In a parallel project, tasks don't have that absolute dependency, but I might still decide that some of them are higher priority and drag them into a rough order.

I'd like to keep the first of those designated as the "next action" because, in a [U]practical[/U] sense, it is, even if in a logical sense, all of the tasks are potential next actions. Otherwise, I don't see the point of filtering "next actions" vs. available actions.

OmniFocus allows both, and I'd like to preserve the distinction. That way when I filter next actions, I get the one thing that I either must do next (for sequential projects) or really ought to do next (for parallel projects).[/QUOTE]

Well said. It sounds like my alternative suggestion would satisfy both of our uses:

[QUOTE=curt.clifton]... if I can make Available Actions and Next Actions appear the same, then I can just use the Available Actions filter and be happy.[/QUOTE]

Some of us can choose to format the actions the same, blurring the distinction that we don't personally find useful. Others can maintain the distinction if they want.

The only problem then is if someone wants to mix the two uses. It sounds like three types of projects are needed to handle that: sequential, "parallel but ordered", and "parallel and not ordered". Snappier names would also be in order, so to speak.

[QUOTE=curt.clifton]Some of us can choose to format the actions the same, blurring the distinction that we don't personally find useful. Others can maintain the distinction if they want.[/QUOTE]

That's a great idea--once formatting changes are preserved between restarts of OmniFocus!

To go back to handling single tasks: The more I think about it, the more I agree with chrjohns that the Inbox should be available in context view as well as project view, and that tasks that are assigned a context should be moved out of the inbox and placed in the proper context list, regardless of whether they are part of a project.

Any tasks that have a context but not a project could appear in the project view in a section between the Inbox and the projects, called "Unassigned" (or "Single Tasks" or whatever). They could then, if necessary, be assigned a project by entering one in the project column or dragging them to a project.

Single tasks solutions
 

[QUOTE=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.

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.[/QUOTE]

FYI: I don't have the OmniFocus app yet, so I can't really speak to what the app does or doesn't do.

Part of my problem with, well, doing just about anything, is I will process, manipulate, modify a task or project - and frequently never get around to actually doing anything. What I like about GTD is it's focus on doing the tasks at hand. Part and parcel of that was a low barrier to creating a task, and then an equally low barrier to actually doing it.

Right now, I create a task and usually put it in a context immediately. I don't always put it in a project. And I don't want to _have_to put a task in a project. That's one more bit of editing, manipulating, processing that'd stall me from getting it done. Tasks to me are by default single action tasks. I may want to tag it as part of a project (at creation time or later), but that isn't something that has to be accomplished for the task to be "real."

All of my tasks should have a context. And all of my tasks that are part of a project should be tagged with that project. And all my tasks that are actually multi-step should be changed to projects. Although my tasks _should_be all these things, they sometimes aren't. But I don't want to find myself forced to cajole my tasks into these boxes, forced to focus on managing the system and not the tasks.

Hopefully, tasks in OmniFocus would be equally available to me to accomplish whether or not they are still in the inbox, whether or not they have an assigned context, whether or not they have an assigned project. OmniFocus maybe should encourage some "best practices" for GTD, but it shouldn't require it. I want to be able to focus work on my tasks, not on my GTD system.

Having multiple next actions from various projects or from project-less tasks is one way of providing choices. Beyond the ordering of tasks (an attempt at setting priority) and selecting a context, task may be chosen based on time and energy available which is information not available the program which would allow it to promote the next action most appropriately. To help the user choose, tasks could be tagged with these qualities. The interface could say "I've got this high priority task which will take all of your attention but only for 15 minutes, are you ready for me? or do you want to do that brainless task that will take you to the end of your shift and let you talk on your cell phone to your girlfriend at the same time?"

Since there is more to choosing the next action than context and sequence, I think the program cannot be expected to make the final choice.

-Paul (waiting for February list enrollees to roll around)

The app has come a long way since that last post, and now there is a way to manage single Tasks.

I find it a bit unnerving that the single Tasks do not appear in the Project view which is where I do my thinking and editing. brianogilvie's special inbox-like folder in the Project view would be nice.

What I like about the changes so far is the fact that you now have the option of creating a "singlton" project, if you want to, and adding single actions to that, or you can simply allow the single actions to live only in the context lists, which is what I do. Now it would be great if they added an Inbox to the context view.

[QUOTE=duodecad]
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![/QUOTE]

How about instead of a "dedicated" project that you create yourself for Singletons, OmniFpcus creates a "Smart Project" which consists of singletons that are not assigned to a project?


I don't know why, but I freak out a bit when I click on the Clean Up button, and all of my "singletons" disappear from Project View. I know I can see them just fine over there in Context View, but it makes me feel like data loss has occurred....


I think I like this Smart Project concept - it could have a different icon/color and be called "Singletons" or "No Project"
I like it over some of the other suggestions because:

- it allows singletons to be viewed in Project View - eliminates that feeling that there is data missing
- it gets them out of the Inbox
- it requires no "additional work" - it is done automatically on "Clean Up" and does not have to be assigned to a Project by drag-and-drop (and you do not have to create the Project"
- it eliminates the weird feeling you get when you drag a singleton to a project - because even as you do it, you know this task isn't part of a project, and it just feels funny - it takes your mind off of GTD
- it is more consistent with GTD, because you are not filing a task into a no-real Project, it is more like a "convenience grouping" within the Project View of OF
- it is elegant

One reason you need to be able to see project-less actions in project view as well is this: sometimes you might simply forget to assign a project, or mistakenly Clean Up before assigning a project. What if you don't remember what context you assigned it to? Go fishing through it in context view? Not nice.

Great minds think alike, fools rarely differ...
 

[QUOTE=brianogilvie]I have a project called "Stay Organized," where I put unrelated tasks. I suppose it might better be called "Keep Head above Water"!
[/QUOTE]


Funny enough, my equivalent to that is called '@storm in a desktop'.

[QUOTE=pjb]The app has come a long way since that last post, and now there is a way to manage single Tasks.[/QUOTE]

There is? Either it's not obvious, or it's staring me right in the face, yet I don't see it. Would someone please elaborate and tell us where it's located?

Thanks.

[QUOTE=soundsgoodtome]There is? Either it's not obvious, or it's staring me right in the face, yet I don't see it. Would someone please elaborate and tell us where it's located?

Thanks.[/QUOTE]
I have not searched for it in the documentation but I read about it in these forums: to have a task with no project, simply give it a context. It will show up in this context view with "no project" as project.

[QUOTE=smew]One reason you need to be able to see project-less actions in project view as well is this: sometimes you might simply forget to assign a project, or mistakenly Clean Up before assigning a project. What if you don't remember what context you assigned it to? Go fishing through it in context view? Not nice.[/QUOTE]

This could not be more true. Having tasks with no associate project is a great idea, but they should be viewable as a group if only to ensure that they all belong that way.

Finding all actions without projects
 

[QUOTE=Nigrini]Having tasks with no associate project is a great idea, but they should be viewable as a group if only to ensure that they all belong that way.[/QUOTE]

The default "ungrouped" grouping in Context view actually sorts everything by project, so if you ungroup you'll find all your actions without projects sorted together (at the bottom of the context view).

[QUOTE= Nigrini]Having tasks with no associate project is a great idea, but they should be viewable as a group if only to ensure that they all belong that way.[/QUOTE]
[QUOTE=Ken Case]The default "ungrouped" grouping in Context view actually sorts everything by project, so if you ungroup you'll find all your actions without projects sorted together (at the bottom of the context view).[/QUOTE]
I have to say it seems bizarre to me to go into context view and group your actions a certain way in order to check that actions without projects assigned really don't/shouldn't have projects. I mean, this sounds like a planning thing more than a doing thing.

OF now has a top-level "Projects" folder in project view that by definition contains every project. Right now, the top-level contains (and only can contain) the Inbox and this Projects folder. I would suggest that a new top-level entity be created that shows actions without projects assigned. The general idea is that in project view, actions come in three flavors: those not yet processed (Inbox), those processed and assigned to projects (Projects folder), and those processed, but not assigned to a project (the new folder).

This would make it easy, while in planning mode, to move actions that maybe aren't as single-step as one thought into the project hierachy. This would also mean that while in planning mode (project view) one could find EVERY action in the database. It is a little confusing to me that some actions are only available in one view and some only in the other. At least one view should show everything (with appropriate filter settings, of course).

[QUOTE=Ken Case]The default "ungrouped" grouping in Context view actually sorts everything by project, so if you ungroup you'll find all your actions without projects sorted together (at the bottom of the context view).[/QUOTE]

This actually doesn't happen for me. I have a bunch of No Projects at the top, and a bunch at the bottom. I don't know why.

[QUOTE=joelande]How about instead of a "dedicated" project that you create yourself for Singletons, OmniFocus creates a "Smart Project" which consists of singletons that are not assigned to a project?
[/QUOTE]

I'm totally with Joelande.

If not that, at least "non project" and "no context" actions should always show up at the TOP of their respective views, not the bottom. If I'm organizing manually, I want things that accidentally got "lost in the shuffle" to pop out first so I can fix them, not last. I never get to the bottom of the list.

[QUOTE=johnrover]I never get to the bottom of the list.[/QUOTE]

LOL. That's why it's "Getting Things Done", not "Getting Everything Done".

Exactly... just because I havn't assigned them to a project doesn't mean that they should go to the bottom

[QUOTE=kmarkley]
This would make it easy, while in planning mode, to move actions that maybe aren't as single-step as one thought into the project hierachy.[/QUOTE]

I agree, this is in fact a very common occurance.

I think this was mentioned earlier as a possible solution to single tasks but wanted to elaborate on possible implementation.

I think it would be nice to see a third category in projects view side bar titled "Single" or something similar. This would be a catchall group for single tasks that can be viewed and easily accessible in project view. Maybe even throw in a unique icon for single tasks similar to how the Inbox icon is unique.

For example in project view mode the side bar would show:

[B]Inbox
Single
Projects[/B]

I agree that to be true GTD you should be working in the context view for doing work but I sometimes feel more at home reviewing/working in project view based on the mindset I am in. For this reason I use the Inbox as an "unprocessed" holding tank which needs attention before I can work on it. This is just my personal preference for not keeping single actions in the Inbox.

I currently have to nest a single tasks project in the project folder and it just doesn't seem like the right place based on my workflow since it isn't a project.

Just my 2 cents....

I have a Single Tasks Project that I assign them to.

Philosophically it's a kludge, but practically it poses no problems in a workflow.

[QUOTE=TommyW]I have a Single Tasks Project that I assign them to.

Philosophically it's a kludge, but practically it poses no problems in a workflow.[/QUOTE]

It may not pose problems to your work flow but it does to mine.

As I mentioned I do the same thing with you having a "single tasks" project. When I work click on the projects folder to get the entire scope of all my projects and use the filter to group by project. When you have a single project gets placed into a "NONE" folder. I can resolve this by creating a "Single Task" folder but its redundant.

[ATTACH]222[/ATTACH]

I put a Singletons project under each of my top-level folders. This might be too much structure for some, but the advantage is that I can easily focus on a particular role. This way I can see the project actions and single-step actions just for a particular role.

That said, I think a top-level Singletons folder that was built-in would be a reasonable way to show singletons in the project view. That would help me catch items that I should categorize during my weekly review.

Yes, curt has pointed out an important organizational issue. If, as suggested by a number of previous posts, we have Inbox, Projects, Singles (or whatever you call it) at the top level, then you have the problem of some singleton actions not being placed within a folder representing that task's catagory (assuming you use folders to organize by category).

As curt suggests, place the "single" folder/project inside each folder, but then you have the next issue, what of subfolders within folders? Are you to have a "single" folder/project within each folder regardless of level? This begs for a muddled organization.

Several earlier posts have actually brought up one important GTD issue, which I fear many/most users are not in tune with. Projects are a side-issue. The GTD method is to throw ideas into a hopper (inBox) and when processed, if the idea is actionable, it must be assigned a context. All of this is supposed to be a black box from which you get "next actions" whenever you are ready to do something. The concept of projects is a convenience added to the system to keep sets of actions that belong to one objective together.

Unfortunately, many/most users focus on projects as the center of the universe. I easily slip into that mentality myself. The projects view should be for just that - projects. You can review them, tweak them, etc. But singletons should not be a part of that. However, we really do need a full view of the landscape to help us look over things, to be sure nothing is lost. So, the suggestions given above provide a way to keep everything in view. I'm sure the designers at Omni have one eye on GTD, but they also realize that OF needs to be less pure, to connect with users who are project-centric, or even those who are simply "task" oriented. The bottom line is that OF will become a hybred; a generic tool that users from different perspectives can use.

As for the problem of singletons vs. the appropriate folder/subfolder they should be associated with - I don't see a solution that offers a simple organization.

Following is a suggestion I wrote to the ninjas a few days ago when reading the singleton threads. I'm reposting here.

=-=-=-=-=-=-=-=

These terms:

Project
Context

seems to generate a whole bunch of tug-of-wars, especially concerning where to place Actions with no projects.

I submit that a slight change in terms in the toolbar may settle many conflicts.

The primary problem we have right now is that the term Project is too limiting on what the view really needs to be. If the view is called Project, then that's pretty much all you can display, Projects. Even the Inbox is displayed in the Project view. But Inbox doesn't really fit, does it? It's not a Project.

Just because GTD has Projects doesn't mean OmniFocus has to name one of its views Project. A better term for this view would be Review. Now this view can contain the Inbox, Projects, single actions with no Projects, etc.

According to GTD, when a person is actually getting things done they're working from the Context view. This view is fine.

By this simple change, now Actions with no Project can be shown in both Review and Context and everyone is happy.

So what will happen is this:

Any Action with no Context and no Project will be in the Inbox;

Any Action with no Project will be in a Review view folder called Non-Project Actions;

Any Action with no Context can't exit, because by definition, a person has to be somewhere, or in some Context;

All other Actions will have a Context and a Project and therefore will be in the Project Actions folder.

Now that there is a Review view, Smart Folders can also exist in this view and be used however the user wants.

Terry,

Having a "Review View" makes great sense.

The only tweak I would make, is that Actions with a project but no context do belong in the project actions folder, but they should be somehow highlighted.

My reason is that I often brainstorm actions while doing project planning. Sometimes I only remember to set contexts for the first couple of actions. But then when I check those off, my project is stuck. The next action, having no assigned context, doesn't show up in Context view. But if actions with projects but no context were highlighted differently in the Review view, then I could easily notice and fix them during a review.

Cheers,

Curt

Yes, please tweak away. My main idea was to modify the limiting view called Project.

Thanks, Terry! I agree that the "Projects" view should be for just that and nothing else. Your "Review" view is just the thing I was thinking about, more of a maintenance view to be sure nothing falls between the cracks. In the end, it's the Context view that we should be working from to Get Things Done.