Feature request: Checkbox for project

[eatmytag]

Hi, I would like to ask for a checkbox at project level. This request comes from the following need/usage scenario:

I use projects with no tasks to represent single tasks. However to complete such a single task I have to use the contextual menu and select complete. Can you make a checkbox for this as well?

Edit: It would be nice if projects and tasks were the same thing. A task with sub-tasks becomes a project. A task with no sub-tasks is a single task. Also, this would enable "projects" to be contained by a context. It is a bit strange as sub-projects have all the functionality of tasks, but "real" projects don't.

[Athanasius]

I'm curious as to why you would use projects as tasks.

[BwanaZulia]

I think you might be trying to make something work the way you want as opposed to trying to see how it was built to work. It is pretty flexible, so if you give it a try it might just fit your needs.

BZ

[eatmytag]

I'm curious as to why you would use projects as tasks.

Well, according to David Allen, a task that has more than one step is a project - So essentially, a task with a subtask is a project.

http://forums.omnigroup.com/attachment.php?attachmentid=195&stc=1&d=1180273827

Creating subtasks (sub-projects) is implemented very nicely. However, my question is why are the main projects not like sub-projects?

E.g.: I have a single task - lets say "Call John and catch up on old times". It clearly belongs into my @calls context, but is a single task. I might have it in a project group called "Social stuff" but it does not belong into a project - a sub-task of a task with many steps.

Instead of classifying it as a sub-task, I would like to classify it as a main task - a "project" (as in "project level in the sidebar hierarchy". I can then put the "project" into a group called single tasks if I want.

[rdjong]

Why doesn't it belong in a project, say "social stuff"? You can make that a parallel project with its tasks ordered by importance, priority or urgency.

The big advantage of limiting the number of *projects* is that it guarantees that you will not be swamped by endlessly many next actions. There can be no more next actions than projects. Note that "folders" or "project groups" don't do this for you.

An effective way to restrict the amount of projects is to make them not too small compared to other projects. If you allow 10 minute tasks to become top level goals (projects), you easily may become overwhelmed by next actions, and the method degrades worst case to a plain todo list.

[pjb]

For the sake of simplicity and flexibility, I do wonder if projects and tasks should be similar in nearly all respects. A task with a subtask should be treated as a project and be able to set the sequential/parallel flag until it's sub-projects have been completed.

As it stands now, I find it confusing why I can create a sub-task to a task but not a sub-project to a project. Creating a sub-task changes the execution order with the given top-bottom sort but nothing else. I've not found a use for this kind of complexity, but if the sub-task turned it's parent into a sub-project which could be set to utilize a different execution pattern than its parent, that would be a useful form of complexity.

Got that?

[eatmytag]

Why doesn't it belong in a project, say "social stuff"? You can make that a parallel project with its tasks ordered by importance, priority or urgency.

There is a thread in this forum where single projects are discussed (http://forums.omnigroup.com/showthread.php?t=3548) and there are both voices in favor of having ordered tasks, and having tasks unordered (all equal priority) as they can truly be done in any order.

The big advantage of limiting the number of *projects* is that it guarantees that you will not be swamped by endlessly many next actions. There can be no more next actions than projects. Note that "folders" or "project groups" don't do this for you.

An effective way to restrict the amount of projects is to make them not too small compared to other projects. If you allow 10 minute tasks to become top level goals (projects), you easily may become overwhelmed by next actions, and the method degrades worst case to a plain todo list.

I can see the point of reducing the number of choices when viewing my next actions. But I still find myself not trusting my ordering/wanting to get an overview of what I have to do. This might not be GTD, but this is where I am now and I believe others with me. I think such a level of freedom is not outside the scope of the current feature set provided by omnifocus?

[rdjong]

pjb i don't get your post and can't relate it to this thread. A sub-project of a project has no meaning in OF. I think the basic concepts have been chosen by experts, and as far as I can judge from using the alpha they have done a *very* good job.

I thought the original poster proposed to group unrelated "tasks" as projects in a folder, and from that usage he feels the need for an easy checkbox to mark the "project" done.
I'm saying (at least tried) that he should consider grouping his - even if unrelated - tasks as tasks in a project, and prioritize (order) them.

The difference: if you have 10 projects in a folder, it typically generates 10 next actions. One for each project.
Alternatively, if you have 10 tasks in a project (no matter if that project is in a folder or not), that generates 1 next action, which is nice if you are ready to focus on something.

Part of the "power" of the algorithms behind this wonderful application is that it shows you (if you select viewing next actions) only very *few* task to do next, and that these tasks are the right ones to do now. Even if the total database contains a huge amount of tasks and subtasks.
By using a folder with many small task-less projects, instead of using a project with small tasks, you bypass the algorithm's function (reducing the amount of tasks you can pick from).

[rdjong]

eatmytag, I agree that we sometimes want to see more actions than only the next action, especially if you cannot (or didn't care to) prioritize them well. The view option "Available" tasks is there for such cases I believe.
I can even imagine that for some users this could be the main viewing option, depending on the amount of tasks.
I think there is no good reason to resort to using folders with task-less projects. There isn't any obligation to use folders anyway. I have some of my projects in folders and some others not.

[Athanasius]

For the sake of simplicity and flexibility, I do wonder if projects and tasks should be similar in nearly all respects. A task with a subtask should be treated as a project and be able to set the sequential/parallel flag until it's sub-projects have been completed.

As it stands now, I find it confusing why I can create a sub-task to a task but not a sub-project to a project.

I agree. It is confusing.

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

...

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]

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]

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]

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]

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]

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.

[curt.clifton]

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.

Right, but how do you differentiate between projects that are really done and those where you have to think of a next action? Once I decide that a project is done, I don't want to see it again (unless I'm reviewing completed projects to celebrate my successes). Do you seriously intend to review every one of your completed projects to see if it is really done or if it actually needs a next action? That's just not reasonable, especially in a system like OmniFocus that retains a complete history.

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.

I agree in principle. But there is a huge difference between every subproject and task entered in the program being done and every subproject and task needed being done. I sometimes want the program to specifically call out the state where the entered tasks are done but I haven't marked the project as done. In this state my next action is "Determine the Next Action for this project".

I also sometimes want the behavior that you are requesting. For example, for many of my projects I actually do know every step. So when I complete the last task, the project should be marked as done.

So, I need the functionality I'm asking for. I would also like the functionality that you're asking for. I think a single bit of additional data on each project and sub-project would accommodate both of us. If the bit is preset based on a preference, then you can happily ignore the bit.

If only one of the functionalities is included, then we need to consider how the other would be simulated.

If the auto-completion functionality is included, then I need to explicitly create a last action "Determine the Next Action for this project" whenever I create a project where I don't know all the actions. This is extra work that interferes with the flow of project planning, that I could accidentally forget to do, and that would not be detected automatically by the system. Thus, this decreases my faith in the system and interupts my "mind like water".

On the other hand, if auto-completion is not included, then when I check off the last action on a project I'm automatically reminded to determine the next action for the project. If the project is really done I get another little endorphin rush by making one last check-mark. If the project is not done, then my trusted system reminds me to think of the next action.

In summary, I strongly advocate for including both functionalities. But if a choice needs to be made, then the program should choose the one that minimizes the chance of information loss.

[Craig]

This is an interesting thread and I appreciate the thought put into it - I think it is a dilemma.

The recent posts seem to be addressing this as an either-or setting. I hope brianogilvie's post about how Life Balance works (about six up in this thread) doesn't get lost in the shuffle - it might be the most likely way to satisfy the most users.

[Weasel]

I agree in principle. But there is a huge difference between every subproject and task entered in the program being done and every subproject and task needed being done. I sometimes want the program to specifically call out the state where the entered tasks are done but I haven't marked the project as done. In this state my next action is "Determine the Next Action for this project".

I also sometimes want the behavior that you are requesting. For example, for many of my projects I actually do know every step. So when I complete the last task, the project should be marked as done.

So, I need the functionality I'm asking for. I would also like the functionality that you're asking for. I think a single bit of additional data on each project and sub-project would accommodate both of us. If the bit is preset based on a preference, then you can happily ignore the bit.

If only one of the functionalities is included, then we need to consider how the other would be simulated.

If the auto-completion functionality is included, then I need to explicitly create a last action "Determine the Next Action for this project" whenever I create a project where I don't know all the actions. This is extra work that interferes with the flow of project planning, that I could accidentally forget to do, and that would not be detected automatically by the system. Thus, this decreases my faith in the system and interupts my "mind like water".

On the other hand, if auto-completion is not included, then when I check off the last action on a project I'm automatically reminded to determine the next action for the project. If the project is really done I get another little endorphin rush by making one last check-mark. If the project is not done, then my trusted system reminds me to think of the next action.

In summary, I strongly advocate for including both functionalities. But if a choice needs to be made, then the program should choose the one that minimizes the chance of information loss.

This sounds quite reasonable to me, I would like to have the option to set this parameter on a project-by-project base. And maybe have an option to 'apply to all subprojects'?

I have a bunch of 'projects' that never end, e.g. 'books to read', not that this project is ever going to be out of tasks, but in case that occurs I'd not like it to disappear as done.

[brooce]

> Right, but how do you differentiate between projects that are really done and those where you have to think of a next action?

You don't; you have a computer to think for you!

You think your project is done, and you move on. One sad day, you realize there's another task (or even sub-project) to be handled. Add it, and the containing project would instantly be reactivated.

> Once I decide that a project is done, I don't want to see it again

Agreed! But, if you realize you have another task to complete before the project is done, you'll probably want it to reactivate.

> In this state my next action is "Determine the Next Action for this project".

Good point.

[johnrover]

I agree. It is confusing.

Yes. Absolutely so. This thread is practically identical to this one:
http://forums.omnigroup.com/showthread.php?t=3642


I can't quite see what the advantage of making distinctions between projects, task/action groups, task/actions, and sub-tasks/actions. Everything would be much easier and simpler if they were just "objects" with a parent/child structure.

Every object should have every property start / due / context(s) / state / repeat, etc. Every object should have a checkbox. New child objects should inherit properties from parent objects automatically. If the properties of a parent object are changed, the user should have an option to "propagate" that change down to the child objects.

Why not?
Simple. Intuitive. Flexible.
I dare you Omni – make my dream app.
.
.
.
please?

[curt.clifton]

I'll post this to OmniFocus extras, since that's where this stuff belongs. But I thought for the sake of completeness, it also belongs in this thread.

I've posted a "Verify Next Actions Exist" script to my software downloads (http://www.rose-hulman.edu/~clifton/software.html#VerifyNA) page. This scripts scans all projects and action groups to identify those without an identified next action.

[pvonk]

Mathematically speaking, a project is a set, a container for things. What can these things be? Again, from a mathematical point of view, things can be more sets (subsets) or atomic items. In GTD, the atomic items are actions or tasks. When you group several of these together, you have a project.

OF introduces the concept of a subset. Thus this subset lies between a project and a task. In GTD, it could only be a project (thus a subproject of the parent project) or a task (which then contains subtasks). While this structure is not pure GTD, we have it in OF, thus we must accomodate it. So which is it? A subproject or a task containing subtasks?

I believe a task is an atomic item, anything else is a container class, thus a project. However, OF seems to treat this "in-between" object as a task. At least by its icon and its presentation in the views. This is the confusion we have. On top of that, we also have folders and subfolders. Not very Zen-like if you ask me.