[curt.clifton]

Originally Posted by al_f

I'd be interested to know how other people are using OF and iCal (or the calendar app of their choice) in combination in their workflow.

I used to use events in iCal to capture "hard landscape" actions, like Take Out the Trash, that have to be done on a particular day. Since repeating events and dates have been shored up in OF, I only use my calendar for appointments. My daily review includes looking at two saved perspectives in OF:

• Group Remaining Actions by Start — this one lets me review the actions that are becoming active tomorrow morning
• Group Available Actions by Due Date — this one lets me review the actions that are most urgent

I'm generally pleased with this system. I will often drag the hard landscape actions from OmniFocus into an OmniOutliner document of "Stuff I must do today". That's something I've been trying for a couple of weeks. It works OK, but seems a bit clunky. It might be better to flag those items and use filtering, but I'm already using flagging for monthly goals. What I would really like is arbitrary meta-data with filters, so I could tag monthly goals independent of flags. But arbitrary meta-data seems unlikely in the near-term.

[jelmore]

Originally Posted by Ethan Schoonover

My canonical singletons action groups:

Grocery Shopping (non repeating tasks)
Household chores (with some repeating, some non repeating tasks)

There are several others as well, but these are my standard examples.

This may be delving into the pedantic, but you're talking about the new "singleton buckets" in recent builds, right?

Originally Posted by Ethan Schoonover

I agree that it's weird to say that they aren't projects but then stick them under projects. It might make more sense to just change the name of the top level "projects" folder rather than move them elsewhere. I still want to have them live near/with my other projects within folders.

I would not have a problem with a Projects view sidebar that looks like:

[] Inbox (view for unprocessed actions)

[] Next Actions (view for processed actions that have a context but no project)

[] Projects (view for processed actions that have a context and a project)

Of course now the "Project" view sounds more like the "Planning" view...

Originally Posted by Ethan Schoonover

Also, in many cases the singletons "groups" (buckets) are really projects of a sort. For the most part they are "perpetual" projects. I.e. Grocery Shopping singletons bucket is really a perpetual project that has a goal of "maintain stock of food for the upcoming week's meals".

So for me, the key difference between singletons and "normal" projects is that singletons projects are, generally, perpetual and never complete.

I mentioned in the earlier discussion about how people use their contexts that I maintain a "Groceries" context under "Roaming" that accomplishes a similar goal; I think it's a whatever-works-best-for-you deal.

Oh, and welcome to the boards (and congratulations on the new job!)

[gary]

My feelings are that omnifocus should strive to stay true to gtd while taking into account that one person's idea of gtd could vary slightly from another's. For instance, I simply can't accept the idea of a perpetual project. For me a project has a beginning and end. I don't use gtd for a grocery list, but if I did I'd have "get groceries" as a singleton with the actual items in the notes field. Putting each item as a task seems to be simply using omnifocus as a list maker (I realize the whole thing is a list, but this seems to be more extreme).

Which is why I agree with this:

I agree that it's weird to say that they aren't projects but then stick them under projects. It might make more sense to just change the name of the top level "projects" folder rather than move them elsewhere.

I don't want omnifocus to take usefulness away, especially from Ethan (congrats on joining omni). But if by some restructuring the whole singleton/project situation could become better handled I'd be much happier.

[dhm2006]

Originally Posted by gary

I simply can't accept the idea of a perpetual project. For me a project has a beginning and end.

I did not agree with you on this idea when you first posted it on this thread a few days ago, but I have been thinking about it and have changed my mind. Your definition of a project makes sense and is more in line with DA's. I went back to DA's book and reread how he conceptualized "Projects." All of the examples he gave in his "Partial Projects List" were things that could be completed, things that had a "finish line." Besides, without a "finish line," how can one ever experience the feeling of achieving a "win" that DA talks about.

That still leave me with the problem of what to do with the perpetual items. They are still there and still have to be worked, whether I call them projects or not. Part of the solution, I think, is to cull out actual projects that can be completed (even if they repeat perpetually) and part of the solution is to use checklists (something DA mentions in his book, but on which he doesn't really expand much).

OF's folders and the new singleton buckets have been very helpful to me in organizing and completing actions associated with the perpetual items, as have been your and others' suggestions about how to use them.

[dhm2006]

Originally Posted by Ethan Schoonover

My canonical singletons action groups:

Grocery Shopping (non repeating tasks)
Household chores (with some repeating, some non repeating tasks)

There are several others as well, but these are my standard examples.

I agree that it's weird to say that they aren't projects but then stick them under projects. It might make more sense to just change the name of the top level "projects" folder rather than move them elsewhere. I still want to have them live near/with my other projects within folders.

Also, in many cases the singletons "groups" (buckets) are really projects of a sort. For the most part they are "perpetual" projects. I.e. Grocery Shopping singletons bucket is really a perpetual project that has a goal of "maintain stock of food for the upcoming week's meals".

So for me, the key difference between singletons and "normal" projects is that singletons projects are, generally, perpetual and never complete.

In some cases, singleton tasks may break out and become full projects on their own (this happens for me with "Household chores" where what I thought was a single task turns into a project when I realize it is actually multiple physical actions).

e

Thanks for your insights on how you use singleton buckets to handle perpetual items like "maintaining" something. These perpetual "projects" are very real for me and actually far outnumber the discrete, complete-able, "normal" projects I have. Dealing with them in an organized manner has become frustrating for me.

Congratulations on joining Omni and welcome to the forum.

P.S. Thank you also for articulating so much more clearly what I was trying to say about singletons being actions in larger implicit projects.

[gary]

The more I think about it the more I don't get the idea of singleton buckets if A) they're under projects and B) there can be multiple singleton buckets.

The only difference in that case and the old method of creating a project and labeling it a singleton project that I can see is that singleton buckets will eventually have all actions labeled next actions.

Why not just allow a project to be given three options: sequential, parallel, and all actions labeled as next actions. I guess I'm failing to see, at this point, other than every action being labeled a next action what the advantage of multiple singleton buckets is (of course, there is the visual advantage of seeing a bucket and knowing it's all singletons and not a project. Then again, it's under projects, so they're fighting each other).

[brianogilvie]

Originally Posted by gary

I guess I'm failing to see, at this point, other than every action being labeled a next action what the advantage of multiple singleton buckets is (of course, there is the visual advantage of seeing a bucket and knowing it's all singletons and not a project. Then again, it's under projects, so they're fighting each other).

It's all about focus.

Let me give a specific example of what I mean. I'm graduate program director for my department, and I have a bunch of one-off tasks related to that area of responsibility. I'm also teaching, doing historical research, serving on various committees, trying to keep a tidy house, and just keeping my life in order. In each of these areas, I have tasks that are not part of larger projects, but that are related to those areas of responsibility.

I had already set up "single task" pseudo-projects in each of the folders corresponding to those areas of responsibility before the singletons bucket "projects" were added to OF. That way, I can focus on a folder or two and see only the available actions--in real projects or singletons--related to that area, without being distracted by other actions. If my one-off grad program tasks weren't in that folder, I would have to see a set of unrelated actions as well, and I'd work less efficiently.

The same result could be achieved by allowing individual actions to be placed in folders, but then it wouldn't be possible to collapse the list of single actions unless OmniFocus automatically created a virtual singleton list for that folder. That solution would be fine with me, but the current behavior works well.