Single tasks as project groups & context vs project group

[eatmytag]

I have solved my single task problem by creating a _project group_ called "Single Tasks". I then use projects as single tasks. This way, They are ready to accept sub-tasks if the need arises and are unordered - all projects are next actions.

Alternatively, they could be sorted into one of my project folders. Folders are great! Project grouping without sub-projecting! It took a while for me to figure out the correct difference between contexts and project groups. Here is how I use contexts and project groups:

Context: the _place_ where the task can be done. I work at three different offices, but some of my tasks, I can do anywhere. At first had created @office1, @office2, and @office3 and put all @officeX related tasks in their related context. I found that my mistake was that I should have put some tasks in e.g. @mac or even @email since they were unrelated to the physical office.

Project groups: the _topic_ or _area_ which the task belongs to. I realized my context mistake when I found myself naming my project groups using the same names as I had used for my contexts. "This can't be right" I thought.

So now I have contexts such as @mac and @mac:internet, @officeX, @email/im/phone and @home. My project groups are called things like "OfficeX: Documentation", "People to contact" etc.

Hope this helps somebody.

[brab]

I just tried using projects as single tasks, but the problem is that they do not show up in the context view. Do you still do it this way?

[Ken Case]

I just tried using projects as single tasks, but the problem is that they do not show up in the context view. Do you still do it this way?

Single tasks can now be assigned directly to a context, without having to assign them to a project (or turn them into a project).

[eatmytag]

No, right now I have put my single tasks into a "single tasks" project for two reasons:

1. Projects not showing up in context view
2. Projects not being assignable a context.

It's a bit tricky though. For single tasks as projects I would like to assign projects a context, but when using projects as containers (sub-projects as containers as well), I do not assign sub-projects contexts as I do not want the containers to show up in the context view.

My current solution is to view context view showing all available tasks giving me an overview of my workspace.

[brab]

I now use the "official" approach to single tasks: tasks without a project. It works pretty well except that tasks whose start date is not due yet are shown.

[johnrover]

I now use the "official" approach to single tasks: tasks without a project. It works pretty well except that tasks whose start date is not due yet are shown.


Yes, I'm having the same issues. I have a lot of "projects" that are simple. They involve only 1 task, but might involve more later. I would like the "project" to also be a task, if the "project" has no sub-tasks assigned

Right now in order to get one of these simple project/task things to appear properly in the context view, I need to create a "project" with one "task" inside it and assign a context to the task. And, just in case more sub-tasks spring up, I should really assign a default context to the project.


This is a lot of extra keystrokes when all I need is a reminder to "call Karina and remind her to bring my jacket to the party".

I don't want to have a "shopping" project to contain my "pickup milk" task (context = errands –> grocery store, due date = today) and "pickup batteries" task (context = errands –>radio shack, due date = next week).

Extra projects clutter up my "project" view and over complicate the organization and make the experience cumbersome. I recognize, and need, the ability to use project heigherarchy to organize complex projects. But I want my little reminders in the same program without the added complexity.

Does anyone have a good workflow to address this? Am I missing something?

[johnrover]

Furthermore - In some of my bigger projects, Tasks have subtasks that have sub tasks. And some of them require that the actions be done in order and some don't.

I don't really see the need to differentiate between "projects" and "tasks". Wouldn't it be easier, simpler, and more flexible to have every "task" be a "sub-project" and every subtask be a "sub-sub-project" with all of the same options and metadata, including an "actions must be performed in order" true/false?

Why the disctinction? it seems to complicate things. What am I missing?

[AmberV]

While there is certainly a top-level distinction between the two, is not this how it already basically works? You can set a default context to tasks with sub-tasks, which its children will inherit, and you can set whether or not it is a parallel or sequential sub-project. And if I have a task that needs to be a full blown project, I can just drag it over to the shelf and it becomes one. If a project needs to be a task, I drag it out of the shelf into another project, and it becomes a task (with sub-tasks, if any exist). I don't know, this seems awfully flexible to me, and it helps keep things tidy.

[kmarkley]

It seems the disctions between 'full blown' projects and tasks-with-sub-tasks (or sub-projects) boil down to:

1. Projects appear on the left-hand pane (shelf)
2. Projects can be focused upon
3. Projects have a status (active, on-hold, etc.)
4. Projects never appear in context view, but tasks-with-sub-tasks do
5. The UI for for context, dates, sequential/parallel is different for the two.

I'm ok with 1 & 2 - they seem a useful distinction. I don't know quite how I feel about 3. 4 & 5 drive me crazy.

Re #4: I would like tasks-with-sub-tasks to NOT appear in context view until they have no remaining sub-tasks AND/OR they can be optionally set to automatically check themselves off when all sub-tasks are complete.

[AmberV]

I'm fine with 1-3, actually. I think if a task is growing complex enough to require its own status, it should probably be an actual project. Drag it over to the shelf. That's just the way I work, though.

#4 has been fixed in a recent build. I'm looking at it now. A sub-project acts just like a project in context view, it isn't there. Further, the sub-tasks that are available show the *sub-project* in the project column, not the parent project. Project assignment drop-down has sub-projects available as choices.

I hope they address #5, too. Not having an icon for sequential lends the assumption that it is parallel, since that is what parallel projects look like. And I'd prefer it if the context were not visible, too. Minor quibble though.

[kmarkley]

#4 has been fixed in a recent build. I'm looking at it now. A sub-project acts just like a project in context view, it isn't there. Further, the sub-tasks that are available show the *sub-project* in the project column, not the parent project. Project assignment drop-down has sub-projects available as choices.

So it has, mostly. The sub-project does appear in the project column, but I can't get it to appear in the drop-down or via auto-complete.

But the really big problem is: If the sub-project is part of a sequential project and you check off all it's subtasks, then you have to go back to project view to check off the sub-project itself before more next-actions become available.

Still drives me crazy.

I hope they address #5, too. Not having an icon for sequential lends the assumption that it is parallel, since that is what parallel projects look like. And I'd prefer it if the context were not visible, too. Minor quibble though.

Personally, I would prefer that the default context was visible in both projects and sub-projects. I would rather resort to the inspector as infrequently as possible.

[AmberV]

Weird, I could have sworn that I saw auto-complete/drop-downs on sub-projects working yesterday. But yes, not proceeding to the next action once all of a sub-project's children are checked off is definitely an over-sight. I don't think the sub-project should get automatically checked off, but the engine should definitely move on to the next.

Personally, I would prefer that the default context was visible in both projects and sub-projects. I would rather resort to the inspector as infrequently as possible.

Ah, see I've been using right-click to set and check that. I don't much care for palettes, either. My rationale for wanting it invisible is that it is not functionally applicable to that line; only the lines beneath it. The project's context does nothing to the project. Context does not actually mean anything, except when attached to a task.

Maybe if it showed up on mouse-over; I wouldn't mind that.

[johnrover]

Thanks guy. You've articulated this way better than I did.

I don't particularly mind the UI distinction (#5). In fact, the UI distinction might help some users with basic needs by helping the OmniFocus "Scale Down" to really simple needs. Maybe thats the logic....

The functionality differences kill me though. (#3, #4)

What does Omni have to say?

[kmarkley]

Ah, see I've been using right-click to set and check that. I don't much care for palettes, either. My rationale for wanting it invisible is that it is not functionally applicable to that line; only the lines beneath it. The project's context does nothing to the project. Context does not actually mean anything, except when attached to a task.

Maybe if it showed up on mouse-over; I wouldn't mind that.

I'm not that fond of using right-click either. It is still mouse work. I'd like to check/change the setting without resorting to the mouse at all.

But I understand your rationale. A sub-project is not itself an action, so it doesn't really have a context. Maybe if it were diplayed in parentheses and/or a much paler font one's eyes wouldn't be tricked into thinking it was an action.

[johnrover]

I'm not that fond of using right-click either. It is still mouse work. I'd like to check/change the setting without resorting to the mouse at all.

But I understand your rationale. A sub-project is not itself an action, so it doesn't really have a context. Maybe if it were diplayed in parentheses and/or a much paler font one's eyes wouldn't be tricked into thinking it was an action.


That's just it, a sub project IS an action – once all of the sub-sub projects in it are completed.

A project is an action once all of the tasks / sub-projects are completed.

One final click to confirm, "yes, this is finished" wouldn't be too much work. And it could allow projects to function as tasks when need be. And tasks to function as projects when they have no - sub tasks.

[kmarkley]

That's just it, a sub project IS an action – once all of the sub-sub projects in it are completed.

A project is an action once all of the tasks / sub-projects are completed.

One final click to confirm, "yes, this is finished" wouldn't be too much work. And it could allow projects to function as tasks when need be. And tasks to function as projects when they have no - sub tasks.

An action is something you can actually DO. A sub-project is often just a collection of actions grouped to accommodate sequential/parallel logic of a complex project.

I don't really mind that it might take one final click. My big objection is having to find and click the sub-project in project view in order for next actions to start showing up in context view again.

[Ken Case]

Thanks for bearing with our UI inconsistencies during this pre-beta period, and sorry for the confusion surrounding action groups! The current UI is the way it is because we only recently (late last week) came to a firm plan for exactly what they are and how they should work. (Your feedback has helped with that, thank you!)

So, what are they? They're groups of actions. That's it. They're not actions themselves (though they might have started life that way, before you realized they weren't actionable), and they're not projects (though you can promote them to a project or demote a project to an action group in another project).

They're not projects of their own, so they won't appear in the sidebar, you won't be able to focus on them, and they won't have project-only states like "on hold" (points 1-3 above).

They will no longer appear in Context view (point 4), which is a change we made last week.

The user interface for action groups (point 5) will change to be a little less like actions and a little more like projects, but not quite like either: we'll add the parallel/sequential control (so you can see its state without checking the contextual menu) and we might hide the default context (so that it's clear that it's not actionable itself).

The state of an action group will be derived from the state of its actions: it will automatically be marked complete when you complete all its actions (so you will no longer have to switch from context view back to project view to complete it before proceeding to a subsequent action), its estimated time will be the sum of the estimated time of its actions, etc.

Thanks again for your patience and your feedback!

[johnrover]

Thanks for the update Ken!

What is the best way to handle misc actions without projects?

[johnrover]

I'm having a hard time illustrating my issue, so fogive me for using an example:

I have a project called "Develop and perfect my organizational system" It has many actions including: "re-read GTD book", "skim 43 folders wiki" and "convert stuff from iGTD to Omnifocus". They each have different contexts, "on the subway", "laptop– online", and "laptop– offline", respectively.

I don't want to jump from iGRD to Omnifocus until it moves to "beta". Therefore, I want to put "convert stuff from iGTD to Omnifocus" somehow tagged as "on hold" or something similar. I don't want to create a project out of it. It's an actionable item that will take 30 min (if I'm lucky). I don't need to break it down any further because that's a waste of my time. When the product is ready, I just need to block out 30 min to make the switch.

Right now, I can't put that task "on hold". I can only put the project on hold. But if I put the project on hold, "re-read GTD book" and "skim 43 folders wiki" gets filtered out.

Perhaps my problem is a GTD methodology problem instead of a software problem. How would you guys adress this?

[Craig]

I have a project called "Develop and perfect my organizational system" It has many actions including: "re-read GTD book", "skim 43 folders wiki" and "convert stuff from iGTD to Omnifocus". They each have different contexts, "on the subway", "laptop– online", and "laptop– offline", respectively.

I don't want to jump from iGRD to Omnifocus until it moves to "beta". Therefore, I want to put "convert stuff from iGTD to Omnifocus" somehow tagged as "on hold" or something similar. I don't want to create a project out of it. It's an actionable item that will take 30 min (if I'm lucky). I don't need to break it down any further because that's a waste of my time. When the product is ready, I just need to block out 30 min to make the switch.


I would do this:

> Develop and perfect my organizational system [a parallel project]
-----------------------------------------------------------------
- re-read GTD book (c: on the subway) [a task]
- skim 43 folders wiki (c: laptop-online) [a task]
- convert from iGTD [a subproject/task-with-subtasks, marked not-parallel]
- - OmniFocus moves to beta (c: waitingfor)
- - convert stuff from iGTD to OmniFocus (c: laptop-offline)

[johnrover]

gotcha. That makes perfect sense. I guess this is the purest GTD method there is. It's a lot of extra tracking though. I need to make 3 items instead of one. Bummer. Is this really the best way?

Intuitively, here is the way I would think of it:
Initially "convert from iGTD" should be [a task] (c:laptop-offline) (status:waiting)

Then when Omnifocus beta come out, I would change "convert from iGTD" to [a task] (c:laptop-offline) (status: active)


I know the value in sticking to a GTD purist method, but for me, changing the status marking on 1 task from "waiting" to "active" is more intuitive, simpler, less time consuming, and requires less bloat than making a sub-project along with 2 tasks, then marking one of them complete.

GTD is great, but needing 3 items instead of 1 seems a little rigid. Am I crazy?


Followup 1:30PM:
I think I've figured it out. I made 1 sub project "convert from iGTD" [sub-project] (c:laptop-offline) with 1 action in it "wait for Omnifocus beta" [a task] (c:waiting). When I complete the "wait for Omnifocus beta" action, "convert from iGTD" becomes an active action. This way I have 2 items instead of 3, which is simpler and better.

Any pitfalls with this one?

[curt.clifton]

The state of an action group will be derived from the state of its actions: it will automatically be marked complete when you complete all its actions (so you will no longer have to switch from context view back to project view to complete it before proceeding to a subsequent action), its estimated time will be the sum of the estimated time of its actions, etc.

Thanks again for your patience and your feedback!

ACK! I missed the importance of this post when I first saw it, since I wasn't yet living in OmniFocus then. This planned behavior for completing action groups is horrific. It means that I have to think of every single action necessary to complete the action group at the time I create it. Otherwise the group will silently be marked complete when I finish the last action that I thought of. That's just not reasonable. Please, please, please reconsider this.

The auto-completion of an action group or project should be a piece of meta-data. If I know that I've identified all the steps necessary to complete an action group, then marking the group complete when the last action is complete is appropriate. But suppose I've only identified the next action or two for the group. When I check off the last identified action my next action becomes "Identify the next action for this action group". I could explicitly add that as the last action of every action group and project, but that seems like a kludge.

Applying GTD is not a process of identifying all the next actions and then doing them. To me, the "mind like water" power of GTD comes from getting things out of my head and into a trusted system. I can do that with a project by simply identifying the one next action to take to move it forward. Please don't build into OmniFocus the assumption that we can a priori determine every action necessary to complete a project or sub-project.

[johnrover]

ACK! I missed the importance of this post when I first saw it, since I wasn't yet living in OmniFocus then. This planned behavior for completing action groups is horrific. It means that I have to think of every single action necessary to complete the action group at the time I create it. Otherwise the group will silently be marked complete when I finish the last action that I thought of. That's just not reasonable. Please, please, please reconsider this.

Yes Yes Yes! Absolutely! Please!

....

I think most of these problems would go away if there was no distinction between "projects" and "actions groups" and "action sup groups" and "actions".

Projects should really just be "action groups" on the root level. "action groups" are just projects that are NOT on the root level.

This could make sooooo many issues go away, and is how most people think of things intuitively anyway. I can't think of a single drawback from this method. Someone please tell me why I'm wrong....

[brooce]

> It means that I have to think of every single action necessary
> to complete the action group at the time I create it

That doesn't necessarily follow. You still _have_ the project around, it's just done. Add more un-done crap, and the project would become un-done.

[curt.clifton]

> It means that I have to think of every single action necessary
> to complete the action group at the time I create it

That doesn't necessarily follow. You still _have_ the project around, it's just done. Add more un-done crap, and the project would become un-done.

Brooce (and Omni folks and others), please see my reply to your similar message here (http://forums.omnigroup.com/showthread.php?t=3649#post15108).

[taylorluker]

I agree totally with johnrover. This whole idea of projects and subprojects and sub-sub projects etc. just doesn't make sense. All the behavior of these items is one: to group ACTUAL tasks and actions. Thus, I think all three should behave and look the same. With the only difference being the root level. Or why no just have projects expandable from the sidebar as well. I also think you should be able to focus on subprojects and sub-sub projects as well. Again the only difference I think should be the default appearance. Projects should be bigger in text size than sub projects. The characteristics should be the same:
1. change parallel and sequential all in the same place visually on the actual title
2. set a due date
3. define a default context (however the big three don't get the context) it is only displayed visually maybe in really small words or something

[Ken Case]

This whole idea of projects and subprojects and sub-sub projects etc. just doesn't make sense. All the behavior of these items is one: to group ACTUAL tasks and actions.

It sounds like there's some misunderstanding about OmniFocus' design, so let me see if I can clear that up. (Whether or not it's a good design is another question, but let's start by getting on the same page about what the design actually is.)

OmniFocus doesn't have subprojects.

What OmniFocus does have is a list of projects, which you can organize into a hierarchy using folders. Each project has some unique project attributes, like its status and its next review date.

Each project also has a list of actions, which you can organize into a hierarchy using action groups. Action groups provide some flexibility with organization and scheduling (since groups can be sequential or parallel), but they don't have any of project-specific attributes. (For example, there's no notion of reviewing action groups separately from their containing projects, just as there is no notion of reviewing individual actions separately from their containing projects.) Action groups make it easy to break stuff down into smaller and smaller steps as you attempt to reach the stage of individual actions, i.e. things that are actionable in a context.

Backing up one step further:

The focus of OmniFocus is on acting, not planning. The expectation is that you should simply write down the things that are on your mind so you can stop worrying about them now, and start acting on them when the opportunity is available. (Of course, if every step is already on your mind you might write them all down to get them out of your head.) As long as you're acting and keeping your projects moving forward, you've done enough planning from OmniFocus' point of view. (We don't force you to plan out your entire project in advance with every possible step of every portion of the project.)

I should point out that some projects truly do require a lot of complex planning to determine the most efficient order in which to act. But that's really the domain of OmniPlan (http://www.omnigroup.com/applications/omniplan/) (with its visual timelines and dependencies), not the domain of OmniFocus (with its list of things I can do right now in this context).

[dhm2006]

I should point out that some projects truly do require a lot of complex planning to determine the most efficient order in which to act. But that's really the domain of OmniPlan (http://www.omnigroup.com/applications/omniplan/) (with its visual timelines and dependencies), not the domain of OmniFocus (with its list of things I can do right now in this context).

Are you planning to include an "Export to OmniFocus" command in Omniplan (or vice versa)?

[Ken Case]

Are you planning to include an "Export to OmniFocus" command in Omniplan (or vice versa)?

We're planning integration between the two apps, yes. This will probably be pretty basic for 1.0 (copy and paste?), but we have more ambitious goals for 2.0 (so you can distribute actions to team members who are using OmniFocus, and receive their status updates back in OmniPlan).

[dhm2006]

We're planning integration between the two apps, yes.

That sounds great!

[kmarkley]

It sounds like there's some misunderstanding about OmniFocus' design, so let me see if I can clear that up. (Whether or not it's a good design is another question, but let's start by getting on the same page about what the design actually is.)

OmniFocus doesn't have subprojects.

What OmniFocus does have is a list of projects, which you can organize into a hierarchy using folders. Each project has some unique project attributes, like its status and its next review date.

I actually completely agree with this general design philosophy. But what I really don't like is that there are some attributes that are NOT unique to projects but are handled differently for action group.

Chief among these is the parallel/series setting. It drives me crazy that on one hand projects: 1) default to series, 2) show a black icon for series, 3) show a gray mouse-over icon for parallel, and 4) can be change by clicking. But on the other hand action groups 1) default to parallel, 2) never show an icon, and 3) can only be seen/changed via context-menu. I would very much like a more unified UI on this.

Also, projects and actions groups can both have a default context, but they are only visible/editable for action groups.

Finally, I would also like better handling for action groups with no remaining actions. I frequently loose sight of a project because an un-checked action group is preventing other actions from becoming available. I usually catch it during my weekly review, but a week is a long time to forget about a project.

I submitted these thoughts as feedback some time ago. It would be nice hear what the omnians have planned for this.

[al_f]

3) show a gray mouse-over icon for parallel

The ninjas tell me this is confirmed as a bug and will be fixed in a future build.

[markbrown00]

Finally, I would also like better handling for action groups with no remaining actions. I frequently loose sight of a project because an un-checked action group is preventing other actions from becoming available. I usually catch it during my weekly review, but a week is a long time to forget about a project.


Yes. I agree. I think i've posted about this a while ago, but the way things are currently, you can't safely use action groups inside sequential projects.

[GeekLady]

With all due respect, this is silly.

I understand that OF doesn't require us to plan everything out in advance and that you want to differentiate OmniFu from OmniPlan, but those are poor reasons to exclude some proper subproject functionality from OF.

Just because we don't have to plan out our every move doesn't mean we won't sit down and completely flesh out a project to see exactly what it will require of us.

I don't care whether you call them action groups or subprojects, they lack some important project-like functionality.

1. You cannot drop an action into a subproject/action group, only into the top level project. I understand this magnifies autocomplete issues, but couldn't we select the top level project and then arrow over to the subprojects?
2. You cannot see the next actions for all subproject/action groups in a parallel project, only the next action from the first subproject in the list. This is counter-intuitive, they're all technically projects, and all have a next action, but there's no way to see all of these next actions... if you use available, you risk the filter showing a huge list of parallel actions instead of the next ones you can do to move each subproject/action group forward.
3. You can't put a subproject on hold. See Thomas's issue (http://forums.omnigroup.com/showpost.php?p=17198&postcount=1). This is probably more in the domain of OmniPlan, but the issue is still there. This could probably be fixed, by creating dependencies between projects: i.e. setting the start date on Project B to the completion date of Project A, even though Project A isn't complete yet.
4. Subprojects/actiongroups are not checked as complete when their tasks are completed AND they don't show up in context for you to check them complete. And if you do start autocompleting them, how are you going to differentiate between the subproject/action group that has been completely fleshed out and is complete versus the subproject/action group that only had 2 or 3 tasks dropped in it, but isn't complete yet?

(I'm sorry that this ends abruptly and if it sounds more combative that I really mean it to sound, but I don't have time for rewritting, I have to head to work.)


OmniFocus doesn't have subprojects.
...
The focus of OmniFocus is on acting, not planning. The expectation is that you should simply write down the things that are on your mind so you can stop worrying about them now, and start acting on them when the opportunity is available. (Of course, if every step is already on your mind you might write them all down to get them out of your head.) As long as you're acting and keeping your projects moving forward, you've done enough planning from OmniFocus' point of view. (We don't force you to plan out your entire project in advance with every possible step of every portion of the project.)

[pjb]

I think this has been a tough issue to discuss in this forum because everyone's interpretation of the interface is predicated on their actual use of the app. In one sense, the problem arises because the app allows the user to start making an outline in the task pane with indentations and subcategories but then doesn't behave like an outline. When I look at my OF task list, the sub-project/task groupings have words like "get" and "arrange" instead of action words like "buy" and "call") which make them sound like projects but they are really just undifferentiated task lists, some actually already have subtasks, but many don't yet have all the tasks needed to mark that sub-project/task grouping as fully planned. I am reluctant to make all these grouping separate projects in the left Projects pane because even with Folders there isn't enough room for organization and display but I would like to treat the groupings as sub-projects with more Project functionality. So, yes, I agree with GeekLady (no surprise there) and and would like to see sub-project functinality and not just task-groups because it would better reflect to the way I enter tasks into OF and get them out of my head.

[curt.clifton]

Finally, I would also like better handling for action groups with no remaining actions. I frequently loose sight of a project because an un-checked action group is preventing other actions from becoming available. I usually catch it during my weekly review, but a week is a long time to forget about a project.



I run my Verify Next Actions Exist (http://www.rose-hulman.edu/~clifton/software.html#VerifyNA) script as part of my evening and morning reviews for exactly this reason.* I think it would work to have the action group header show up as an action in the context view when all of its children were completed. Then I could either check it off, or else use Show in Project View to add another next action. The one significant drawback is that if the action group isn't legitimately actionable, then my context view is polluted with non-actionable items.

* Sorry to keep plugging my scripts. I'm starting to feel like I should get a plaid jacket. "Welcome to Crazy Eddies! What do I need to do to get you to download a new script today!"

[Ken Case]

I don't care whether you call them action groups or subprojects, they lack some important project-like functionality.

I understand—but it's not just a matter of not calling them subprojects; it's that we haven't implemented subprojects (and aren't trying to), which is why you can't do all the things you're talking about doing (such as assigning inbox items to subprojects or indicating each subproject's next actions).

Rather than trying to treat action groups as individual subprojects, my suggestion is to make each of your subprojects a separate project (possibly grouped in a folder if several are related); I think you'll find that eliminates most of the problems you're currently encountering while trying to treat action groups as subprojects. (Instead, I'm guessing you'll have some feedback for us about folders and dependencies between projects.)

3. You can't put a subproject on hold.

If you create a separate project for your subprojects this won't be an issue, but I thought I'd also point out that you can effectively put individual actions (and action groups) on hold by setting their start date to some date in the future.

4. Subprojects/actiongroups are not checked as complete when their tasks are completed AND they don't show up in context for you to check them complete.

We're planning to fix this: we agree that they should action groups should either show up in context view when their children are complete (but in what context, since they don't truly have one of their own?) or they shouldn't block the project (either by automatically marking them complete, or perhaps by just skipping past them so you still have the opportunity to decide whether they're really complete the next time you review your project).

[curt.clifton]

We're planning to fix this: we agree that they should action groups should either show up in context view when their children are complete (but in what context, since they don't truly have one of their own?) or they shouldn't block the project (either by automatically marking them complete, or perhaps by just skipping past them so you still have the opportunity to decide whether they're really complete the next time you review your project).

But action groups can have contexts; it's one of the ways in which they are more action-like than project-like.

As I've argued before, automatically marking action groups complete is a recipe for disaster. You've said that the philosophy of OmniFocus is that you don't assume that people are planning everything in advance. But autocompleting an action group when its children are complete makes just that assumption! In doing so, that design choice would keep me from trusting my system.

Skipping past an action group has a similar problem. Suppose I have an action group "Set Up MacBook Pro". It might have a bunch of actions in parallel. Following that action group might be a Sell PowerBook G4 action group. I don't want to move on to selling the PowerBook until I've manually confirmed that I have the MacBook Pro set up as desired.

Perhaps I'm constructing deeper hierarchies on projects than I should be. I suppose the Sell PowerBook G4 action group could be a separate On-Hold project that I activate when I finish the MacBook Pro set up project. But because I only review on-hold projects about once a month, setting up the projects like this would mean a month or more delay between setting up the MacBook Pro and selling the PowerBook.

The current behavior is preferable to both the autocompletion and skipping proposals. At least currently I can hack up the safe behavior with a script.

[markbrown00]

Curt,

couldn't you just make the last action of the task group something like: "verify that MacBook Pro is adequately set up"?

I really feel constrained by the current behaviour. It degrades the trustability of my system in a different way: tasks waiting for a task group to be completed are hidden until my weekly review. Skipping would be ok; autocompletion (perhaps with a preference to turn it off) would be the most intuitive.

[Craig]

couldn't you just make the last action of the task group something like: "verify that MacBook Pro is adequately set up"?

I really feel constrained by the current behaviour. It degrades the trustability of my system in a different way: tasks waiting for a task group to be completed are hidden until my weekly review. Skipping would be ok; autocompletion (perhaps with a preference to turn it off) would be the most intuitive.

I'm in complete agreement with this.

It seems like some alpha testers can't get comfortable with the neither-fish-nor-fowl nature of these "action groups" (and thus clamor for them to behave like subprojects, indistinguishable from projects except for their position in the hierarchy).

But I actually really appreciate this new invention. It seems to me - dare I say it - like an improvement on David Allen's system. As I understand him, Allen talks about projects as multi-step objectives that require planning and "staking." He describes some good methods for visualizing the end result, brainstorming, etc. to flesh out that planning. But he also states that any objective that requires more than one step is perforce a project. This is what I've struggled with in implementing GTD in the past: is

- look up movie showtimes @web
- call Mario re: movie tomorrow? @calls

really a project? I think it makes sense to call it something else, because it doesn't require any nontrivial visualizing of a successful outcome, brainstorming around how to get there, etc. It's just a group of actions - an action group!

By definition and in my practice, these action groups are complete when their component actions are complete. Assumption of the necessity of a review of their doneness seems like overkill to me. I'm glad to hear from Omni that the plan is to stick with action groups and to fix the problem of them holding up projects.

[jasong]

But [David Allen] also states that any objective that requires more than one step is perforce a project. This is what I've struggled with in implementing GTD in the past: is

- look up movie showtimes @web
- call Mario re: movie tomorrow? @calls

really a project?

It depends on how you got it into your system, and what you're focusing on. If it pops into your head "Oh, I need to call Mario about going to a movie tomorrow", you jot that down. Then you realize, "oh, wait, before I call Mario, I should have a few ideas about movies and times, so I need to 'look up movie show times'" and you jot that down.

Either you can then make "See movies with Mario" a project with two items (seemingly overkill here), or you can make "look up movie show times" an action item of "call mario".

Unfortunately, if you do the latter, you end up with the "action group" and once you've cleaned it up, that action group doesn't show up in the Projects list.

Worse yet, the action "look up movie show times" never shows up as a next action (it shows up as a "remaining" item), and even when you check it off, "call mario" never shows up as a next (or even remaining) action: it's (seemingly) lost for good.

This behavior might simply be a bug, but it underscores the importance of treating items with consistency.

(I suggest you try reproducing this yourself, as it wasn't the behavior I was expecting:

1. Create an action "Call mario about movies", context @calls
2. Create an action "Look up showtimes", context @computer

(use your own contexts, they aren't the important bit here.)

3. In your Inbox, move "Look up showtimes" under "Call mario..."
4. Clean up your Inbox
5. Find the "Call mario" or "look up showtimes" action as a "next" or "available" filter.)

[curt.clifton]

Mark,


couldn't you just make the last action of the task group something like: "verify that MacBook Pro is adequately set up"?

That's close, but not quite there. If I added that to the task group (recall it was parallel), then that action would show up before it was actionable. But I could add it as a subsequent action after the task group. If OF implements the proposed skipping behavior, then the action would be "Verify that MacBook Pro is adequately set up and, if so, check off the previous action group." (Not that I'd write all that, but it is what would practically need to happen.) If OF implements the auto-complete behavior for action groups, then the action would be "Verify that MacBook Pro is adequately set up and, if not, switch project view to all actions, add an action to the previous action group, uncheck the action group, and switch project view back to remaining actions." Whew.

I really feel constrained by the current behaviour. It degrades the trustability of my system in a different way: tasks waiting for a task group to be completed are hidden until my weekly review. Skipping would be ok; autocompletion (perhaps with a preference to turn it off) would be the most intuitive.

I'm not arguing for keeping the current behavior. I really want the top action of the action group to show up in context view when the children are complete. But I prefer the current behavior to autocompletion or skipping because the work-around is simpler. If someone can convince me that autocompletion doesn't require perfect planning, then I could be swayed that it's the right choice. Skipping action groups just seems bizarre.

Craig, I'm definitely not arguing for action groups to become full-fledged projects. If I need full-fledged project functionality, then I promote the action group.

[Craig]

Either you can then make "See movies with Mario" a project with two items (seemingly overkill here), or you can make "look up movie show times" an action item of "call mario".

Actually, what I would do would be to make a "See movies with Mario" task group with two items, within my Singletons project, and that seems to work.

[brianogilvie]

I'm not arguing for keeping the current behavior. I really want the top action of the action group to show up in context view when the children are complete. But I prefer the current behavior to autocompletion or skipping because the work-around is simpler. If someone can convince me that autocompletion doesn't require perfect planning, then I could be swayed that it's the right choice. Skipping action groups just seems bizarre.

I agree completely with Curt here, as I think I mentioned on another thread back in May or June. Autocompletion is, I think, a recipe for disaster except for those who plan every step of a project-like entity (which is, for better or worse, what an action group is). Since, as Curt pointed out earlier in this thread, you can assign contexts to action groups, why not have the group appear in its context once all the actions assigned to it are done? If it is truly done, you can just check it off to get rid of it.

Life Balance does this, and I thought it is one of the more elegant touches in that application.

[Craig]

I agree completely with Curt here, as I think I mentioned on another thread back in May or June. Autocompletion is, I think, a recipe for disaster except for those who plan every step of a project-like entity (which is, for better or worse, what an action group is). Since, as Curt pointed out earlier in this thread, you can assign contexts to action groups, why not have the group appear in its context once all the actions assigned to it are done? If it is truly done, you can just check it off to get rid of it.

Life Balance does this, and I thought it is one of the more elegant touches in that application.

I for one don't use the "default context" feature with action groups. (If the actions that follow would all have the same context, chances are pretty good I would just make them one action - "look up address, directions, and hours for frame shop" as one @web action, not three.) For that reason, I'd be happy if the context assigned to the action group heading defined not the default context for the subactions, but rather the context in which it should appear to verify that it's done (if OmniFocus goes that route).

Not only would that mean losing a feature I never use - it would also intuitively feel more right, since what you're assigning to the action group in the context column is the same kind of thing that you assign to individual actions in that same place.

Do the rest of you find the default context setting for action groups useful?

[sprugman]

As long as we're voting, I'm with Curt -- make the parent of a group of actions pop into context view when all of the children are complete. (And yes, I like my action groups to have a default context, if for no other reason than so I don't have to enter one for the children if they're the same.

[curt.clifton]

Do the rest of you find the default context setting for action groups useful?

I mostly stopped using default contexts after I got the wrong context on a few too many tasks.

Perhaps action groups could have a context-menu-accessible default context (making them slightly more project-like) and a regular context that is used for adding the group patriarch to the context list. Then my Update OF-Mail Scripts action group could have a default context of "Computer -> Problem Solving" and a regular context of "Computer -> Planning". After I complete the last action in the group, the next time I'm in planning mode I can decide if the scripts are completely finished, or else decide on the next action.

[GeekLady]

Well, could they assign the task-group/subproject/whatever entity to the same context as the last task to be completed in that group - that way, when the last task in it is completed, it would show up right after you check off that last task and in the same context and you don't have to go hunt it down?

Say you have the following action group and tasks (with context in parentheses):

Pack Carry-On Bag
- Buy duffle bag (Errands)
- Wash jeans (Home)
- Check TSA restrictions (Online)
- Write checklist (Computer)
- Pack items in duffle and check off list (Home)

So, you make this action group, as seen above, and it sets the context of the group to (Home) because that's the bottom item in the group. After you complete all the tasks, Pack Carry-On Bag will appear in the Home context, so you don't have to go looking for it, and you can decide whether you've completed the group or not.

At any point you could add a task to the bottom of the list like:
- Weigh bag, must be under 40 pounds (Work)

...and the context of Pack Carry-On Bag would switch to Work.

I mostly stopped using default contexts after I got the wrong context on a few too many tasks.

Perhaps action groups could have a context-menu-accessible default context (making them slightly more project-like) and a regular context that is used for adding the group patriarch to the context list. Then my Update OF-Mail Scripts action group could have a default context of "Computer -> Problem Solving" and a regular context of "Computer -> Planning". After I complete the last action in the group, the next time I'm in planning mode I can decide if the scripts are completely finished, or else decide on the next action.

(I still intend to comment on subprojects, but things have been busy.)

[anna]

This is causing problems with my workflow. I like action groups, and how they let me intermix parallel and sequential steps. But the fact that action groups hang around, invisible in the context view, blocking the next action of the project, is really causing problems. It's bad that a grouping mechanism causes my project to grind to a halt until I review all my projects. (Usually I'm working with a focussed enough view that I can say "Hey! Where did the rest of my 'register for conference' project go? *(#@% action groups." and fix it right away. But that's a problem.)

My request:
- action groups *can* be set to auto-complete when their children are checked off
- they are *not* forced to auto-complete
- if not on auto-complete, the action group heading appears with the context of the last child (maybe as long as the default category is not set), possibly in a different colour text, or with some way to distinguish it from actions

It seems to me this might satisfy everyone---those who want to use groupings transparently, and those who want to use action groupings to trigger planning. (But it can't be a global preference, because I use them both ways).

Will send this as formal feedback, unless people can convince me this is bad functionality.