The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus 1 for Mac
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Feature request: Checkbox for project Thread Tools Search this Thread Display Modes
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.

Last edited by eatmytag; 2007-05-27 at 12:44 AM..
 
I'm curious as to why you would use projects as tasks.
 
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
 
Quote:
Originally Posted by Athanasius
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.



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.
Attached Thumbnails
Click image for larger version

Name:	ishot-070527-1549561.jpg
Views:	1020
Size:	26.2 KB
ID:	195  
 
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.
 
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?
 
Quote:
Originally Posted by 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.
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.

Quote:
Originally Posted by rdjong
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?

Last edited by eatmytag; 2007-05-27 at 11:18 AM.. Reason: Changed URL
 
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).
 
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.
 
Quote:
Originally Posted by 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.
I agree. It is confusing.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
feature request: next project kasi OmniFocus for iPhone 1 2009-11-12 07:41 PM
Feature Request: Project Time Totalling Releaux OmniFocus 1 for Mac 2 2009-08-20 08:11 PM
Feature request: Project Colors remedy5 OmniFocus 1 for Mac 2 2009-04-10 06:12 AM
Feature request: bigger checkbox 'hot' area snarkyFish OmniFocus for iPhone 8 2008-10-20 05:15 PM
Feature Request - Delete Project Protection PattiBarcroft OmniFocus 1 for Mac 7 2008-06-18 02:57 PM


All times are GMT -8. The time now is 12:09 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.