[maverator]

Originally Posted by MEP

I do that without any folders. Action groups are essentially sub-projects from a functional perspective. The UI is a bit wonky still, but the functionality is all there.

As far as I can tell, and which I also gathered from other threads, action groups are not projects. Meaning that you can't have a Project (capital-P) with action groups in it and expect the action groups to behave like Projects themselves. You can't independently make an action group sequential if the parent project is parallel, you can't review them separately, and you can't set state independently. (I.e. the attributes in the Project Inspector apply to the parent project, not the action group.) Yes you can look at an action group and mentally consider it a project, but from a software functionality standpoint it isn't. But if I'm wrong and it's really wonky UI issues that give this illusion let me know.

[djbell]

I'm a business owner, so I tried folders like this:

Personal
Business
Clients
--Client1
--Client2
--. . .

My kGTD method was to make actions called "Client1: update spam filters", "Client2: update spam filters", and so on, which was redundant and annoying; this is vastly, vastly better for me. I think of folders as project prefixes-- if I'm buying a mouse, a folder tells me who I'm buying it for and thus has intrinsic value to my workflow.

OF's folders are a GTD miracle that are a huge boon to my ability to organize. I absolutely love how folders work within OF; they truly provide the user with the ability to "Focus," and provide useful and consistent information in the Context's Outline view (when the proper option is selected in preferences).

Sadly, folders are worse than useless when it gets to iCal right now, because a project name can be completely ambiguous when relying on folders to provide structure, but I trust in the Omni to make these things universally useful soon.

[curt.clifton]

Originally Posted by maverator

As far as I can tell, and which I also gathered from other threads, action groups are not projects. Meaning that you can't have a Project (capital-P) with action groups in it and expect the action groups to behave like Projects themselves. You can't independently make an action group sequential if the parent project is parallel, you can't review them separately, and you can't set state independently. (I.e. the attributes in the Project Inspector apply to the parent project, not the action group.) Yes you can look at an action group and mentally consider it a project, but from a software functionality standpoint it isn't. But if I'm wrong and it's really wonky UI issues that give this illusion let me know.

Yes and no.

You certainly can put parallel action groups inside sequential projects, and vice versa. Right-click the action group to set it's "sequentiality". I use this all the time to control dependencies on complex projects.

You are right though, that you can't set review dates and state for action groups independent of their parent projects. You also can't assign an action to an action group using the quick-search mechanism.

So, the difference really has to do with how many of the OF features you're using. If are not using on-hold projects, dropped projects, review dates, or quick-search to assign projects, then action groups behave like sub-projects. If you are using those features, then they are substantially different beasts.

[maverator]

Thanks for the tip on parallel/sequential in the action groups Curt.

It seems to work just like it should (in terms of next actions and available actions), which is a definite help.

[brianogilvie]

Let me put in a plug for the current distinction between action groups and projects, just for the sake of argument. I'm not sure I wholly agree, but I can see value in distinguishing them.

A project is some desired outcome that takes more than one action to complete, but where you can define what a reasonable outcome would be. "Become the world's leading triathlete" is not a project--perhaps it's a life goal--but "Prepare for Iron Man 2008" might be one. You know that it's not something that's actionable in itself, but you have a sense of what getting there means.

An action group is a set of actions that, taken together, contribute to that outcome but aren't sufficient. It's like a lemma in a mathematical proof: it's not independent (at least in the context of the proof), but it hangs together. Within the context of my Iron Man example (I've never run more than a half-marathon nor cycled more than 40 miles, so this is fantasy land), "Train to improve century time" might be an action group. Getting it done is not for its own sake but for the sake of the Iron Man project.

A cyclist might make that an independent project, if his or her goal is do do well in a 100-mile race. So the distinction is semantic; it depends on the user's goals. The question is what it takes to arrive at closure. I see a value in maintaining the distinction. When I was using Life Balance, which did not distinguish different hierarchical levels, I found myself prefixing "(p)" to projects, so I could tell the difference. Other people might not find the distinction useful, and I might be able to live without it, but I wouldn't like to see it disappear.

[smiggles]

Originally Posted by brianogilvie

Let me put in a plug for the current distinction between action groups and projects, just for the sake of argument. I'm not sure I wholly agree, but I can see value in distinguishing them.

A project is some desired outcome that takes more than one action to complete, but where you can define what a reasonable outcome would be. "Become the world's leading triathlete" is not a project--perhaps it's a life goal--but "Prepare for Iron Man 2008" might be one. You know that it's not something that's actionable in itself, but you have a sense of what getting there means.

An action group is a set of actions that, taken together, contribute to that outcome but aren't sufficient. It's like a lemma in a mathematical proof: it's not independent (at least in the context of the proof), but it hangs together. Within the context of my Iron Man example (I've never run more than a half-marathon nor cycled more than 40 miles, so this is fantasy land), "Train to improve century time" might be an action group. Getting it done is not for its own sake but for the sake of the Iron Man project.

A cyclist might make that an independent project, if his or her goal is do do well in a 100-mile race. So the distinction is semantic; it depends on the user's goals. The question is what it takes to arrive at closure. I see a value in maintaining the distinction. When I was using Life Balance, which did not distinguish different hierarchical levels, I found myself prefixing "(p)" to projects, so I could tell the difference. Other people might not find the distinction useful, and I might be able to live without it, but I wouldn't like to see it disappear.

Thank you brianogilvie. I will try to look at my projects/action groups similarly and see if that makes a difference. in some ways this is semantics. But in OF it's manifest in how they have organized the system. I'll give it a try to think of it this way.

I find this whole organizational debate regarding folders, projects, actions, sub-folders etc. very interesting as I'm still an OF newbie and still trying to strike the right organizational balance.

[dwayneneckles]

Is it too much to ask folks to put up screenshots.. blur out sensitive stuff.