Single action lists differ from parallel projects in that:
Only the first action in a project could be a “first available action”, whereas every action in a single action list could, in the right circumstances, be a “first available action”;
A project header itself can appear in a context list (in the right circumstances), whereas a single action list cannot.
However, a single action list can be marked as completed just as a parallel project can (was that always the case?) The distinction seems so small that I wonder how the existence of single action lists is justified.
Personally, I find it useful to be able to visually differentiate a group of tasks from (say) a shopping list.
That said, my needs would be satisfied by different icon types. I don’t know if I care about the logical semantics / functional differences between the two types.
A project (for me) relates to one job, in my case development of a site, and has a defined beginning and end. BTW this can be sequential or parallel.
A single action list I use for say “client requested changes” or “recurring tasks” these never have an end and encompass one off requests from all my clients and as new requested changes are constantly being added are really just a bucket for related tasks
The final project type, Single Actions, isn’t really a project—it’s a list of loosely-related actions that aren’t interdependent. A Shopping List project is a good example of a Single Action list because it contains a list of things that you need to pick up at the grocery store. You can gather these items and check them off as completed (or acquired) as you make your way through the store. The order in which you collect them is irrelevant—it doesn’t matter if you pick some of them up today or tomorrow; they’re just things you know that you need to grab.
A Single Action list is often more about a state you want to generally sustain (spoiled cat, non-spoiled food, functional household), rather than a state you want to achieve (ship an app, take a vacation, find a new apartment). Another way of looking at this is that Single Action lists rarely have due dates, and they rarely get checked off as completed. The items within the Single Action list may get checked off, but the project itself is ongoing.
Like the two comments above, I am thankful for the visual difference because I use SA lists at the top of my other project lists contained in folders as administrative lists. I don’t expect to retire the SA lists until I change jobs or make a significant life move that changes an area of responsibility.
One of the small things I appreciate about Omni’s attention to detail.
@TheOldDesigner Thanks. Often I hear that single action lists are open-ended, never completed. So why does OmniFocus allow one to mark a single action list as completed (and not only dropped)?
Well, I might have a single action list for a current project that I am working on… Maybe I’m part of a summer youth counseling program. Then I’ll have a bunch of one-off actions for the program. When the summer is done and the program has wrapped up, I can mark the single action list as complete instead of just deleting the SAL.
Some SALS can stay indefinitely. Some are good for a a short time before we can say that we completed the SAL.
[quote=“wilsonng, post:13, topic:25718”]
Some SALS can stay indefinitely. [/quote]
eg. I have SALs for many lists I keep. Also, for regular reports/meetings I have to make/attend.
[quote=“wilsonng, post:13, topic:25718”]
Some are good for a a short time before we can say that we completed the SAL. [/quote]
eg. I have SALs for events I have to organise/coordinate.
I use SALs for areas of responsibility, where the lists themselves serve as triggers in my weekly review to help me think of things I might need to do, as well as to capture “loose actions”. Examples are:
Finances
Relationships
Car
Household
Consulting
Learning and Development
I also use SALs as (very) short term ways of capturing actions about a thing happening. Things like “Pack for Travel”, “Chore Day”, or “Stuff for Saturday”.
In David Allen speak, “as long as all the things that mean that are there”, these are a great way of quickly grouping elements without the feeling of responsibility of naming a project/outcome.
This all makes good sense. My original thought was that if SALs disappeared tomorrow then we’d all happily carry on with parallel projects, just named differently. Except, perhaps, for Jan_H, whose comment is intriguing.
I think @Jan_H means that if a perspective is only set to show available next actions, only one action would show up for most projects, whereas all of the SAL’s actions would show up, since all “could be actionable” without dependencies.
@OmniChris, originally I had difficulties in understanding what the practical differences between single action lists and parallel projects were, and the manual didn’t make it clear to me. When I found that all tasks in single action lists were shown in perspectives set to show only the first available task in every project, that was a meaningful difference to me. Then I could have a perspective giving me a good overview: it could show the first available task in projects where I already had the tasks in good order and without worries could just pick the first available task to work with, but at the same time the perspective could show all tasks in an unsorted single action list containing various tasks that I know I also would like to take care of rather quickly. To me, that combination works much better than if I could only show either one task in every project or all tasks in every project.
@Jan_H Thanks for the insight Jan_H, I think this will be useful. While the design difference between parallel projects and SAL’may be obvious, exploting that difference requires at least some thought.
