[mwillems]

I do not understand the difference between "parallel" (which I think means independent actions in a project) and "single actions" (which I think means independent actions in a project). Can anyone explain?

(I've tried to read the PDFs etc, of course.)

Michael

[whpalmer4]

In many situations, a parallel project and a single action list behave interchangeably, and which you use is just a matter of personal preference. I prefer that my projects have a goal which, when I achieve it, signals the project is complete. But what about collections of tasks which have no such stopping point? Painting the house or cleaning the garage are projects with clear goals and endpoints. Maintaining the lawn or taking care of the pets are collections of tasks which have no clear endpoints. Some refer to such collections as areas of responsibility. Philosophically, I think it is a bit cleaner to use projects for the collections of tasks which have a definite ending, and single action lists for areas of responsibility, but there is no functional reason why you need to do so.

Another way a SAL list is often used besides as an area of responsibility is as a miscellaneous catch bucket. In OmniFocus 1, you can't put a single task in a folder or the top-level; it must be in a project or a SAL. This is a hindrance at times because you might want to use the tools OmniFocus provides for project management on it; OmniFocus 2 is supposed to extend the object model to allow you to do everything you can do with a project with a single action as well. In the meantime, one might have a folder full of projects relating to work, and the occasional task which is work-related, but not worthy of being a project by itself, and not really related to any of the existing work projects. A SAL in the work folder can act as a repository for such independent tasks.

There are some functional differences between parallel projects and single action lists, however. Actions in a single action list have their own special styling; by default, any action in a single action list will be colored blue, unless it is overridden by a status-based style (being due soon, overdue, blocked, or completed). Actions in a parallel project (or action group) will be colored black by default, unless overridden by a status-based style or if they are the next action (which will be colored purple by default). Furthermore, when viewing next actions only, a parallel project has just one action shown, the very first one available, but a single action list always has all of its available actions shown. Here the thinking is that a single action list makes a good container for all of those miscellaneous tasks which aren't part of a project, but if you're viewing next actions, you don't really have a "preferred" next action from that miscellaneous collection, and you are shown all of them that are available.

As an example, you might have a single action list with miscellaneous things that need fixing around the house, plus you've got a parallel project (or a parallel action group in a sequential project) holding the tasks you need to do to finish wiring your home network. All those tasks are in your Home context, so if you switch to context mode, select the Home context, and show next actions, you're going to get the first available action from the home network wiring project, and all of the tasks from the miscellaneous fixit SAL. If you want to work on the wiring, you'll do that, but if not, there's no point in showing you the other tasks in that project. On the other hand, if you feel like working on something else, you'll have numerous choices. Just because you don't feel like caulking a gutter today doesn't mean you aren't up for replacing that broken light switch or installing a new water filter in the ice maker.

In the end, you can use either construct in most places. If you want, you can style single action lists much like parallel projects (except you won't get the next action styling, and everything will still be treated as a next action by the action filters). If you are looking at available or remaining actions instead of next actions only, there are no significant functional differences that come to mind. Best of all, if you decide your parallel project would work better as a SAL, or vice versa, just bring up the inspector and change it! Sometimes when I'm working in a next action view and there are too many contributions from some of my SALs, I'll temporarily change some of the offenders to be parallel projects until the numbers of actions shown are a bit more reasonable.

I hope that gives you some guidance on why you might choose one or the other!

[whpalmer4]

Looking at your other posts, I see that you may only have the iPad version, in which case some of my comments about styling and coloring do not apply. The iPad doesn't color items in a single action list any differently than those in a project, and you don't have any control over the styling. The behavior with respect to the next action filter is identical, however.

[mwillems]

That's very useful, and yes, I indeed have the iPad version. Thanks!

[mwillems]

Mmm. So single actions are unrelated actions. But then ALL my projects are single action lists, surely? For example, I have many admin things to do. They are single actions, unrelated by anything other than "they are admin tasks". Same for Tasks around the Home. And so on. So now I end up with only Single Action Lists. And that makes the "next action" view less useful.

Maybe my "Project" concept is wrong. I have:

Admin
Post Production
Home Maintenance
Personal Misc
Prospect Follow-Up
Marketing
Schools (with 3 sub-projects)
Photo Jobs


..All those seem like Single Action lists, basically unrelated tasks. Am I using OF wrong?

[whpalmer4]

I wouldn't say you are using it incorrectly, but you might not be using it optimally.

From your description, it sounds like you've taken all of your workload and split it out into groups of similar tasks which may or may not be related to each other. If you got a new contract to do a movie or photo shoot, there would be new tasks added to a number of those categories you listed, whereas with a project-oriented setup, there would be a new project added to one of them. Which approach is most useful depends on your needs. Do you need to be able to easily pull up all of your administrative actions at once, and work only on them, or is it more likely that you need to pull up all of the actions relating to a particular photo shoot and work it to completion to meet a deadline? The structure you have is better suited to the former; the project-oriented setup is better for the latter.

Another way of thinking about this is to consider what you would need to do if you chose to drop a project (or put it on hold). That photo shoot is going to have administrative tasks (billing, collecting), post production (backing up the images, doing the processing, producing the final results), marketing (considering whether any images ought to go in your next set of marketing materials), etc. If your client cancels the shoot (or just postpones it), it's going to be much more convenient to simply mark the "Photo shoot for Bill Clinton, Oct. 2011" project dropped (or on hold, or with a future start date) than to go through all of your different containers looking for tasks that might have been related to the now defunct photo shoot — and if he flip-flops again, with the project setup you simply mark the project as active again, with no need to recreate all of the tasks you would have deleted.

The definition of a project used by most working in the GTD style is that a project is any desired result that requires more than one action step. I'll bet that quite a lot of the actions in your database are pieces that could reasonably be assembled into projects. But if your working style is more like that of an assembly line worker who happens to work at a number of different stations at different times (today I only do admin work, Saturday I only do home maintenance, Wednesday and Thursday I do post production) your current setup may make more sense. I would suggest in that case that you make them parallel projects rather than single action lists, and occasionally sort the actions into any desired priority order (the next action view will always present the uppermost available action).