[gary]

Top-level actions, or actions in folders, would remain actions unless they were given child actions. Once they get a child, they become projects.

If we were voting, that's what would have my vote.

[jasong]

Originally Posted by dhm2006

Most of my folders, however, are areas of responsibility (or roles or goals or whatever terminology that applies to that type of organization), such as "Household."

I use several singleton lists there. One is "Purchases." In purchases, I have an action called "Grocery List" where I note items I need in the note field (not the routine items like milk and bread, but items I won't necessarily think of when I am at the grocery store). It is just a placeholder, not really an action, because I never mark it complete. I just delete the items I bought from the note.

Is that GTD? I think so. I need a way to get the items to be purchased at the grocery store off my mind until I am at the grocery store. Do I want the grocery list at the root level with my folders? No. Do I want it at the top level inside the Household folder? Not particularly.

I think I'm starting to get a better understanding of the objections to treating single actions and projects as one-in-the-same. The issue as I understand it it that there are *actions* and there are *lists*, and many are using OmniFocus to manage both, while I use a separate application to manage my lists.

I don't think the two ideas are incompatible with each other, we just need to redefine a few things.

What if "single actions" and projects were treated the same (listed in the library/projects/whatever-it-gets-called list), and then there was a "Lists" collection, at the same level as Inbox and Library, that contained checkbox items, as done in OmniFocus? I could see, e.g.

Inbox
- all my inbox items

Library
- Single Action
- Single Action
- Project (Multiple actions)
- Project (Multiple actions)
- Single Action

Lists
- Grocery List
- Movies to See
- Books to Read

Important in this suggestion would be the ability to open and close all of the top level items, so I can, e.g., see only the items below my Lists.

Of course, all folder organization that works under Library should work under Lists, so I can organize my lists as I see fit.

I threw together a mockup in OmniOutliner (using Omni's own icons; I hope that's OK!). I wonder if this works for folks?

[dhm2006]

Originally Posted by jasong

there are *actions* and there are *lists*, and many are using OmniFocus to manage both

That is true for me. I like having everything except calendar items in one place.

Your suggestion is interesting (and very clear from the graphic). I would certainly give it a try if *actions at project level* is implemented.

[brianogilvie]

Given the positions of most posters to this thread, at least lately, I'd like to play devil's advocate and suggest keeping the current distinction between projects and single actions (and thus keeping buckets for single actions).

From a GTD perspective, single actions belong on the appropriate context list, and not necessarily anywhere else. Projects belong on a separate project list, so you can review them and make sure that an appropriate next action is defined and placed on the appropriate context list.

Singleton buckets were implemented in OmniFocus to allow a couple things, IIRC. Those who review in planning/project mode were missing singletons in their review, and those who use folders for organization and focus (one of the most powerful features of OF, IMHO) wanted to be able to place single actions in folders without seeing the sidebar grow to immense proportions.

However, from a GTD perspective, there's no reason to include single actions at the same hierarchical level as projects in the project list. Why? Because they are open loops that can be closed purely from the context lists. Check 'em off and they're done. Projects, on the other hand, represent commitments to outcomes that are not physical actions and thus have to be broken down. When I review my projects, it's largely to make sure that I know what action they need next. I like having a singleton bucket in folders where I have a lot of miscellaneous tasks, but I would hate to see those at the same level as my projects when I do a review.

At the very least, OmniFocus should allow users to implement the current behavior as a preference, even if they allow those who want the app to work in a different way to choose that. I mentioned earlier that I used to put a (p) at the beginning of my projects in Life Balance, to distinguish them from single actions. I would hate to have to do that in OmniFocus.

[gary]

The issue as I understand it it that there are *actions* and there are *lists*, and many are using OmniFocus to manage both, while I use a separate application to manage my lists.

So do I (omnioutliner). Your mockup is interesting. I'm not against using omnifocus to manage lists (or become a reference center, or whatever), but only if it can be done without affecting the core job of being a gtd application.

I don't think debates such as singles bucket/no singles bucket should be affected by a desire to keep a grocery/gift list. If there's a way to do it cleanly while keeping them out of the way of each other I'd be for it.

[ips]

Hi,

jasong is so right with his proposal to include lists; I wanted to bring this idea into the discussion, too. He was faster.

David Allen himselves mentions checklists a couple of times in GTD. These are very useful tools in several ways, and right now, it is a little bit tricky to implement them into OF, but it should'nt be a too difficult to make it could.

Generally, OF should be the place to keep these lists; right now, I have one folder in project view called checklists, which inclues for example a list of lended things, objects I owe to others, a list of things I have to do once a month, other lists are – as mentioned by jasong – movies to watch, CDs to buy, pieces to study on the piano. Keeping all these things as projects with seperate review/repeat days would be too complicated, right now, I can see all on one click (and can print these cards out nicely by copying and pasting into another app).

The structre of a checklist is basically the same as a project with two small differences: The actions do not have a context, they are only list items (perhaps with checkboxes). Therefore, there is no "next step" (no purple text), and the items aren't greyed out just because the context is missing (as it is now), they are black from the beginning.

That would lead to the project options:

Project type:
- Standard project
- Project containing single actions (however this is handled)
- Checklist

Project status:
- Active
- On hold
- Waiting for (is hidden from the "active projects" view, but shows up in the context "waiting for"
- Completed
- Dropped


Greetings
ips

[moniot]

A little off topic:

"Gallon of milk, Loaf of Bread, Stick of butter..."

Jasong, you just sent me back to my childhood in a flash!

: )

Originally Posted by jasong

I threw together a mockup in OmniOutliner (using Omni's own icons; I hope that's OK!). I wonder if this works for folks?

[Craig]

More properly, "a loaf of bread, a container of milk, and a stick of butter."

http://www.youtube.com/watch?v=tFy2jHSIOKA

[jasong]

Heh. Happy to oblige. <grin>

(I realized I had it in the wrong order after I posted, but didn't feel like doing the work to fix it...)

Jason

[jdh]

Originally Posted by brianogilvie

However, from a GTD perspective, there's no reason to include single actions at the same hierarchical level as projects in the project list. Why? Because they are open loops that can be closed purely from the context lists. Check 'em off and they're done.

Although this is an older thread was resurrected by what looks like a piece of unintelligible spam, I just have to add that I agree with the above sentiment.

I don't particularly understand the whole debate about how things are laid out in planning mode, since it's really just that -- Planning mode. Singleton actions rarely require review in this mode, which is why they are conceptually "buckets" rather than "projects" (ie, you drop something into the bucket, and then you should seldom need to look at it again or even think about it from a Planning mode perspective).

I suppose if you were using the Planning Focus modes to actually get things done (ie, follow checklists), this might be more relevant, but I don't really think that's the way that GTD is supposed to work.... You plan in "Planning" mode, and then take action in the "Contexts" view.

In this system, your actions are in the appropriate contexts regardless of whether they are a Project or Singleton item, and will appear hierarchically at the same level within the appropriate context. When you check off a singleton item, it's simply done. If you need to reassign it or create a project out of it, that can be done from the Contexts view in such a way that it pops up during your next daily/weekly review.

So if I've created a singleton action that says "Clean up my desk" and later realize that there are more steps to do that, when I'm going through my @Desk context, I simply notice that, and punch in a project name beside it. Suddenly, it becomes a project, and will show up as part of my next review in Planning mode, at which point I can modify it or assign the necessary sub-tasks to it.

So while I wouldn't strenuously object to changing things as described early, I really don't see any point in it, personally.

On the other hand, being able to rename the "Library" folder sounds like a very reasonable idea. I also like the "Lists" concept that jasong describes -- I presently use OO for most of that stuff, although a few "parallel actions" projects are starting to creep into OF for some of these, I still don't necessarily feel it's the most correct place for them).