[brooce]

At what point do you distinguish a "sub-project" from a "sub-task?"

Maybe sub-projects and tasks with sub-tasks don't carry their own "Done" state, but rely on all their constituent sub-tasks?

[pvonk]

Originally Posted by matt1

Well, then I'm confused. The way it looks to me is that folders can containg projects, and folders, but not just tasks. Only a project can hold a task. Thats why there's a need to have a 'singles' project. Other wise I could just stuff single tasks in the folder.

I guess it's a matter of definition. Here' what I've discovered by experimenting (5-25-07 rev 87440):

The left panel (project view mode) only displayes Inbox, folders and projects. You can have a folder and/or a project inside a folder. If you drag a project inside a project, the new child becomes a task (judging from its icon and the fact that it doesn't appear in the left panel).

My conclusion:

From the top level, you can have projects and folders only (tasks must be inside something, Inbox is a special folder, I think).

[rule 1] Once you have a project along some branch of the tree, you can't have a subproject or folder. You can only have "tasks" and "subtasks".

[rule 2] If you have a folder somewhere along a branch of the tree, you can have subfolders, but if you add a task directly inside the folder, it becomes a project.

If you have a project (call it A) and place a project (B) inside A using dragging for example, then B becomes a "task". (This adheres to rule 1)

I say "task" or "subtask" above, because projects and folders are the only things in the left panel. A former project (B) that is moved inside a project (A) no longer appears in the left panel, but in the main window, B now appears with a check box, not the project icon.

[jdrummey]

[I just sent this to OF Feedback, I figured it's probably worth posting here.]

One of the things I love about the OmniApps is all the hard work Omni does to figure out what I might want to do, so when I go to do something the application just does what I expect.

A place where OF is not behaving the way I expect is with regards to projects, sub-projects, project folders, and next actions:

Issue 1 - It's not necessarily clear what should be a project (perhaps with nested subprojects) and what should go in a project folder. Project folders are created in one pane using one set of mouse controls (with some access to keyboard controls), while projects, subprojects and tasks are created in the outliner view using primarily keyboard controls. Tasks and projects can be promoted & demoted via the keyboard, but not moved into folders (so far as I can tell). The distinctions seem a little confusing, especially given Issue 2 & 3.

Issue 2 - Parallel/sequential projects and next actions. When I create a sequential project, the first task on the list is marked as the next action. When I create a parallel project, again the first task on the list is marked as the next action. It seems to me that in a parallel project any & every task is a potential next action, so all should be marked as next actions or none.

Issue 3 - Parallel projects, next actions, & subprojects. When I create subprojects of a parallel project, I assumed that each subproject would then have its own next action. OF doesn't do this, instead leaving only the first task in the project as the next action. This seems to remove some of the functionality of a parallel project for me. I did a workaround by creating a project folder with a project for each of the original subprojects, and now I'm able to see the next action for each project. However, since project folders have a different life than projects (see Issue 1), this required a bunch of dragging&dropping.

Jonathan

[brianogilvie]

Originally Posted by jdrummey

[I just sent this to OF Feedback, I figured it's probably worth posting here.]

Thanks!

Originally Posted by jdrummey

Issue 1 - It's not necessarily clear what should be a project (perhaps with nested subprojects) and what should go in a project folder. Project folders are created in one pane using one set of mouse controls (with some access to keyboard controls), while projects, subprojects and tasks are created in the outliner view using primarily keyboard controls. Tasks and projects can be promoted & demoted via the keyboard, but not moved into folders (so far as I can tell). The distinctions seem a little confusing, especially given Issue 2 & 3.

As I see it, folders are a way of organizing independent projects into broader "areas of responsibility." For instance, right now I have folders with the following names: Scholarship, Book Reviews, Teaching, Service, Personnel Committee, Organizing, and Home. (I am a university teacher and three of those correspond to the three main areas of our professional activity.) Each of the items in the folders is an independent project, whether that be reviewing a book, writing an article, teaching a course, or putting roof vents in my garage. When it's done, it's done. The folders, which represent broader responsibilities, will only be "done" if I undergo a significant life change.

Because the project list can be grouped in many different ways, including by folder, it seems to be a useful aspect of the UI. If you don't find it helpful to group projects by area of responsibility, you don't need to use them.

Originally Posted by jdrummey

Issue 2 - Parallel/sequential projects and next actions. When I create a sequential project, the first task on the list is marked as the next action. When I create a parallel project, again the first task on the list is marked as the next action. It seems to me that in a parallel project any & every task is a potential next action, so all should be marked as next actions or none.

This was discussed in an earlier thread. Basically, some of us (including me!) think that in a parallel project, every task is a potential next action, but in real life some of them are more important. Because the "available" filter gives you every action that can be done (which means, for a sequential project, only the next action), if you think all your sequential project actions should be "next," you can just use the "available" filter. You could even change the style for available actions to match the next action style, so that there was no visual cue to distinguish them.

One of the great things about Omni apps is their flexibility!