[rdjong]

There are some similarities and differences between folders, projects, tasks, and end-tasks without children in the current OF.

My guess when I restrict myself to Projects and non-end Tasks.

Some similarities:
- both can have children
- both can be set to have their children parallel and sequential
- both can have a context, meaning a default context for their children

Some differences:
- a Project can be set to "Active" "On hold" "Completed" "Dropped" while a Task can only be completed.
- a Project can be displayed in the Project list panel; a Task cannot.
- a Project cannot be related sequential or parallel w.r.t. another, while Tasks can.

More guessing:
A project seems to me like a basic "unit" of focus: either the entire project is in focus, or it is not. A Task cannot be set individually in or out of focus: this makes sense because it would break the consistency when viewing a project. E.g. what would happen if you drag a Task up or down over invisible (out of focus) Tasks.
If Tasks were the same as Projects, then they would need the same icon, and people would automatically start asking (voting!) for a multi-level outline in the Project list panel, rendering the focus mechanism messy, increasing the screen area requirements, and breaking the structure of the filter ribbon.
Also, i suspect the distinct concepts of Project and Task offer good prospects for future features that require different behavior between top-level and intermediate "nodes" of the hierarchy.

Anyway I like this the choices that Omni have taken so-far.

[pjb]

Originally Posted by rdjong

...

My guess when I restrict myself to Projects and non-end Tasks.

Some similarities:
- both can have children
- both can be set to have their children parallel and sequential
- both can have a context, meaning a default context for their children
...

Maybe we're not talking about the same things. As I see the interface:

- A Project does not have children, it has tasks.
- Only Projects have a sequential/parallel switch.
+ The default Context for a Project can be set, it just does not appear in line like it does for Tasks.

I'm not sure why I should be able to have families of subtasks who's parent cannot be treated like a project (with sequential/parallel switch, for example). Should the software restrict the Tasks from having subtasks the way it restricts the Projects from having sub-projects? Or should it provide for sub-Projects as it provides for sub-Tasks? I would vote for a third option by keeping projects distinct but having parent tasks behave somewhat like projects for organizational purposes which would still allow for next action processing. As it is now, I can see why someone would be tempted to make many one-task projects as they are sorting through their stuff or one catch-all project with cascading lists of tasks. Since we're not working with paper folders we can really make an organizational mess if give the freedom to do so.

[Hoff]

Originally Posted by pjb

I'm not sure why I should be able to have families of subtasks who's parent cannot be treated like a project (with sequential/parallel switch, for example).

If I'm following you - this feature is already implemented. If you select a parent task, and right click, the context menu has a "parallel" option. Toggling this sets the group of tasks to be either parallel or sequential.

I have several projects that have sub-projects that can all be worked on at the same time. Each of the sub-projects, however, are series of tasks. The main project is marked "parallel" and the sub-projects are "serial" (parallel is unchecked).

So if I use the "next" view, only the first task in the sub-project at the top of the list appears. If I use the "available" view, I see the first task in each of the sub-projects.

I didn't find the context menu item until told about it, and would suggest using the same UI as for projects (lined up, or side by side arrows in the task line), but the functionality works great for me.

[kmarkley]

I agree that the structure hierarchy is a little confusing. But I think it may be the best we can hope for.

One of the coolest things about kGTD was that it was, for lack of a better term, "zoom insensitive". No matter how shallow or deep you might be in the hierarchy, items could have children and be "projects" or not and be "tasks". The trouble was with next actions. Every item in the outline that had children generated next actions which tended to proliferate to the point of not being very GTD (for me at least).

OF draws a bright line between projects (outline items with children that generate next actions) and sub-projects (outline items with children that do not generate next actions, but otherwise are pretty similar to projects).

I think this is ok and makes sense. But I, too, would like to see a more unified UI that at least looks and feels more "zoom insensitive". Changing default context and sequential/parallel state should look and work the same at all levels.

For the same reasons, I think projects shoud have checkboxes as the first post suggested.

This would also probably mean that sub-projects (or tasks-that-have-sub-tasks, or whatever you call them) do not appear themselves in context view. Only (childless) tasks appear there.

[brianogilvie]

Originally Posted by kmarkley

This would also probably mean that sub-projects (or tasks-that-have-sub-tasks, or whatever you call them) do not appear themselves in context view. Only (childless) tasks appear there.

Life Balance handles this by including subprojects (at any level of the hierarchy) in the context view (to-do list) only when all of the tasks associated with them have been completed.

For instance, if I had a project or subproject like this:

Fix lawnmower
--sharpen blades
--replace belts

then the task list would have only "sharpen blades" and "replace belts." But once those two were checked off, "Fix lawnmower" would appear as a task that could, itself, be checked off if it was in fact done. If it wasn't then you could enter the next action.

If the user interface of Life Balance weren't so awful I would probably still be using it.

[curt.clifton]

Originally Posted by brianogilvie

Life Balance handles this by including subprojects (at any level of the hierarchy) in the context view (to-do list) only when all of the tasks associated with them have been completed.

For instance, if I had a project or subproject like this:

Fix lawnmower
--sharpen blades
--replace belts

then the task list would have only "sharpen blades" and "replace belts." But once those two were checked off, "Fix lawnmower" would appear as a task that could, itself, be checked off if it was in fact done. If it wasn't then you could enter the next action.

If the user interface of Life Balance weren't so awful I would probably still be using it.

I really need something like this functionality. In my daily reviews one of the things I need to verify is that every project has a next action identified. I'm experimenting with writing a script that checks for this, which is what I did in OmniOutliner. But it seems like the concept of identifying a next action for every project is so central to GTD that it should be built in. Somehow I want to filter the Project View to show every project and subproject that lacks a next action.

Intuitively, this is like having a "last action" under each project and subproject that says "Determine next action or mark this (sub)project as completed". Hmm, perhaps that action belongs in my @Reviews context (a sub-context of @Computer for me). Maybe I'll try explicitly adding such last actions.

[Weasel]

Originally Posted by brianogilvie

Life Balance handles this by including subprojects (at any level of the hierarchy) in the context view (to-do list) only when all of the tasks associated with them have been completed.

For instance, if I had a project or subproject like this:

Fix lawnmower
--sharpen blades
--replace belts

then the task list would have only "sharpen blades" and "replace belts." But once those two were checked off, "Fix lawnmower" would appear as a task that could, itself, be checked off if it was in fact done. If it wasn't then you could enter the next action.

If the user interface of Life Balance weren't so awful I would probably still be using it.

I'm a long-suffering user of LifeBalance too... ;-)

I'm extensively using the system as lined out by Brian, just for academic stuff mostly. I am having structures of tasks many levels deep (never counted them).

Eg: in the 7 top level items is 'Study' and I can drill down like this:

Study

Math

Calculus

Course #

Lesson #

Chapter # (<- study this)

Assignment #

The 'Lesson' level is set as consecutive, thus when I finish the study and assignment, the 'Lesson' shows up in the to-do list, I tick that off and get a new lesson, respectively the content in it, listed.

This is a very nice way to work, and I hope (haven't yet been invited to OF) that I can somehow reproduce a system like this.

[brooce]

As posted elsewhere, I assert that Projects should NOT have their own "done-ness"; instead, a Project shall be "done" when all tasks and sub-project tasks are done.

What say you, Omnifolks? Care to share the "Has-A" and "Is-A" diagrams I'll wager someone there has prepared (in OmniGraffle, of course)?

[curt.clifton]

Originally Posted by brooce

As posted elsewhere, I assert that Projects should NOT have their own "done-ness"; instead, a Project shall be "done" when all tasks and sub-project tasks are done.

But that assumes that every task and subproject has been identified. I'm not prescient enough to be sure of that in every case. Simply because every task that I've captured in my system is complete does not necessarily mean that the project is complete. There are two possibilities: the project is complete or I need to think of the next action.

I need to have the option to choose which of those possibilities applies to each project and sub-project. Ideally that would be a check-box in the Project inspector (Auto-complete when sub-tasks are completed), with a preference to control the default value.

[brooce]

> But that assumes that every task and subproject has been identified.

Nope! Add a new un-done task, presto! The project is un-done again.

One would NEVER want the state wherein all subprojects & tasks are done, but the project remains undone. That's the only behavior 'enabled' by having projects maintain their own done-ness, rather than adopting.