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

 
Single tasks as project groups & context vs project group Thread Tools Search this Thread Display Modes
gotcha. That makes perfect sense. I guess this is the purest GTD method there is. It's a lot of extra tracking though. I need to make 3 items instead of one. Bummer. Is this really the best way?

Intuitively, here is the way I would think of it:
Initially "convert from iGTD" should be [a task] (c:laptop-offline) (status:waiting)

Then when Omnifocus beta come out, I would change "convert from iGTD" to [a task] (c:laptop-offline) (status: active)


I know the value in sticking to a GTD purist method, but for me, changing the status marking on 1 task from "waiting" to "active" is more intuitive, simpler, less time consuming, and requires less bloat than making a sub-project along with 2 tasks, then marking one of them complete.

GTD is great, but needing 3 items instead of 1 seems a little rigid. Am I crazy?


Followup 1:30PM:
I think I've figured it out. I made 1 sub project "convert from iGTD" [sub-project] (c:laptop-offline) with 1 action in it "wait for Omnifocus beta" [a task] (c:waiting). When I complete the "wait for Omnifocus beta" action, "convert from iGTD" becomes an active action. This way I have 2 items instead of 3, which is simpler and better.

Any pitfalls with this one?

Last edited by johnrover; 2007-06-06 at 10:51 AM.. Reason: Revision
 
Quote:
Originally Posted by Ken Case
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!
ACK! I missed the importance of this post when I first saw it, since I wasn't yet living in OmniFocus then. This planned behavior for completing action groups is horrific. It means that I have to think of every single action necessary to complete the action group at the time I create it. Otherwise the group will silently be marked complete when I finish the last action that I thought of. That's just not reasonable. Please, please, please reconsider this.

The auto-completion of an action group or project should be a piece of meta-data. If I know that I've identified all the steps necessary to complete an action group, then marking the group complete when the last action is complete is appropriate. But suppose I've only identified the next action or two for the group. When I check off the last identified action my next action becomes "Identify the next action for this action group". I could explicitly add that as the last action of every action group and project, but that seems like a kludge.

Applying GTD is not a process of identifying all the next actions and then doing them. To me, the "mind like water" power of GTD comes from getting things out of my head and into a trusted system. I can do that with a project by simply identifying the one next action to take to move it forward. Please don't build into OmniFocus the assumption that we can a priori determine every action necessary to complete a project or sub-project.
 
Quote:
Originally Posted by curt.clifton
ACK! I missed the importance of this post when I first saw it, since I wasn't yet living in OmniFocus then. This planned behavior for completing action groups is horrific. It means that I have to think of every single action necessary to complete the action group at the time I create it. Otherwise the group will silently be marked complete when I finish the last action that I thought of. That's just not reasonable. Please, please, please reconsider this.
Yes Yes Yes! Absolutely! Please!

....

I think most of these problems would go away if there was no distinction between "projects" and "actions groups" and "action sup groups" and "actions".

Projects should really just be "action groups" on the root level. "action groups" are just projects that are NOT on the root level.

This could make sooooo many issues go away, and is how most people think of things intuitively anyway. I can't think of a single drawback from this method. Someone please tell me why I'm wrong....
 
> It means that I have to think of every single action necessary
> to complete the action group at the time I create it

That doesn't necessarily follow. You still _have_ the project around, it's just done. Add more un-done crap, and the project would become un-done.
 
Quote:
Originally Posted by brooce
> It means that I have to think of every single action necessary
> to complete the action group at the time I create it

That doesn't necessarily follow. You still _have_ the project around, it's just done. Add more un-done crap, and the project would become un-done.
Brooce (and Omni folks and others), please see my reply to your similar message here.
 
I agree totally with johnrover. This whole idea of projects and subprojects and sub-sub projects etc. just doesn't make sense. All the behavior of these items is one: to group ACTUAL tasks and actions. Thus, I think all three should behave and look the same. With the only difference being the root level. Or why no just have projects expandable from the sidebar as well. I also think you should be able to focus on subprojects and sub-sub projects as well. Again the only difference I think should be the default appearance. Projects should be bigger in text size than sub projects. The characteristics should be the same:
1. change parallel and sequential all in the same place visually on the actual title
2. set a due date
3. define a default context (however the big three don't get the context) it is only displayed visually maybe in really small words or something
 
Quote:
Originally Posted by taylorluker
This whole idea of projects and subprojects and sub-sub projects etc. just doesn't make sense. All the behavior of these items is one: to group ACTUAL tasks and actions.
It sounds like there's some misunderstanding about OmniFocus' design, so let me see if I can clear that up. (Whether or not it's a good design is another question, but let's start by getting on the same page about what the design actually is.)

OmniFocus doesn't have subprojects.

What OmniFocus does have is a list of projects, which you can organize into a hierarchy using folders. Each project has some unique project attributes, like its status and its next review date.

Each project also has a list of actions, which you can organize into a hierarchy using action groups. Action groups provide some flexibility with organization and scheduling (since groups can be sequential or parallel), but they don't have any of project-specific attributes. (For example, there's no notion of reviewing action groups separately from their containing projects, just as there is no notion of reviewing individual actions separately from their containing projects.) Action groups make it easy to break stuff down into smaller and smaller steps as you attempt to reach the stage of individual actions, i.e. things that are actionable in a context.

Backing up one step further:

The focus of OmniFocus is on acting, not planning. The expectation is that you should simply write down the things that are on your mind so you can stop worrying about them now, and start acting on them when the opportunity is available. (Of course, if every step is already on your mind you might write them all down to get them out of your head.) As long as you're acting and keeping your projects moving forward, you've done enough planning from OmniFocus' point of view. (We don't force you to plan out your entire project in advance with every possible step of every portion of the project.)

I should point out that some projects truly do require a lot of complex planning to determine the most efficient order in which to act. But that's really the domain of OmniPlan (with its visual timelines and dependencies), not the domain of OmniFocus (with its list of things I can do right now in this context).
 
Quote:
Originally Posted by Ken Case
I should point out that some projects truly do require a lot of complex planning to determine the most efficient order in which to act. But that's really the domain of OmniPlan (with its visual timelines and dependencies), not the domain of OmniFocus (with its list of things I can do right now in this context).
Are you planning to include an "Export to OmniFocus" command in Omniplan (or vice versa)?
 
Quote:
Originally Posted by dhm2006
Are you planning to include an "Export to OmniFocus" command in Omniplan (or vice versa)?
We're planning integration between the two apps, yes. This will probably be pretty basic for 1.0 (copy and paste?), but we have more ambitious goals for 2.0 (so you can distribute actions to team members who are using OmniFocus, and receive their status updates back in OmniPlan).
 
Quote:
Originally Posted by Ken Case
We're planning integration between the two apps, yes.
That sounds great!
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Task Groups (and their Tasks) don't show up in Project view Rockyroad OmniFocus for iPhone 15 2010-07-12 02:34 AM
Tags, Aliases, Folders, Context, Project, Groups, etc.. dancingbrook OmniFocus 1 for Mac 1 2009-07-20 02:00 PM
Group by context within a project nestorph OmniFocus 1 for Mac 2 2009-04-08 08:24 AM
View All Tasks Regardless of Context, Project, etc rwoodruf OmniFocus 1 for Mac 1 2009-04-07 05:51 PM
Cleanup not assigning project-less action to my 'single actions' project bongoman OmniFocus 1 for Mac 0 2007-12-11 03:04 PM


All times are GMT -8. The time now is 08:46 AM.


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