[kmarkley]

Originally Posted by AmberV

#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]

Originally Posted by AmberV

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]

Originally Posted by kmarkley

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]

Originally Posted by johnrover

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]

Originally Posted by johnrover

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)