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

 
How projects and parent/child actions SHOULD work Thread Tools Search this Thread Display Modes
Here's how I think projects and parent/child actions should work.

(1) There should be subprojects.

(2) There should only be parallel projects; there is no need for sequential projects.

(3) Parent actions should be able to have multiple children.

(4) When a parent action is completed, all its children are promoted one level, similar to the way sequential projects work now.

Here's an example. I'll use "->" to denote different generations, then explain the structure below.

-> Action 1.
->-> Action 1A.
->->-> Action 1Aa.
->->-> Action 1Ab.
->-> Action 1B.
->-> Action 1C.

Action 1 is the parent action. It needs to be completed before any children can be completed, but it is not dependent on any children.

Action 1A is the first child. It can't be completed until Action 1 is.

Action 1Aa is the grandchild of Action 1. It can't be completed until Action 1A is. Similarly, Action 1Ab depends on Action 1A, but NOT on Action 1Aa.

Action 1B is the second child. It can be completed as soon as Action 1 is. Same for Action 1C.

So, once you completed Action 1, you would then have:

-> Action 1A.
->->Action 1Aa.
->->Action 1Ab.
->Action 1B.
->Action 1C.

Now you have three parallel actions in your project, one of which has two children.

This setup preserves the distinction between actions and projects that is now confused in OF. Actions should be atomic---they should be things that you can do as soon as you've completed the prerequisite actions. They shouldn't be sets of multiple actions, which is what parents actions are now. That's what projects are.

Furthermore, with this setup, you wouldn't need sequential projects. A sequential project would now be a project with one action that has several children.

I'll probably send this directly to OG. Thoughts?
 
Thanks for the thoughts Chris.

Can you post a real world project?

Specific examples can be helpful. And the goal of OF is to help us in the real world, not with theories.

Thanks.
 
When you post your real world project, please include some examples of how your method deals with waiting for items.
 
Quote:
Originally Posted by SpiralOcean View Post
When you post your real world project, please include some examples of how your method deals with waiting for items.
I think that's a separate question, but I'll tell you what I do now, which wouldn't change. When I complete an action that results in me waiting for something, I just change the context of the action to "Delegated" and set a start and due date for when I want to bug whoever it is that I'm waiting for. If they respond before the due date, then I just check the item as completed, and go onto whatever action is next. If they don't, I bug them on the appropriate date and give myself a new start/due date on the action, which remains delegated.
 
You parent-child relationship seems backwards from most/all GTD implementations I've seen. An action (or the project itself) that is dependent of one or more other actions is usually listed above the other actions.

Your theory implies each action is only dependent on one immediate (previous) action. If you have to perform A, B, and C (in any order) before Z, can you explain how your tree structure would be defined?

Also, I'm not sure I follow your "only parallel projects" idea. If I have to do A, then B, then C, your tree would look like:

A
>B
>>C

This is a sequential project that is defined by the tree organization. Then a parallel project (where B or C can be done in any order, before A) would look like:

A
>B
>C

But the problem (as I mentioned above) is what if A or B can be done in any order and C done last. By your definition, A and B would be at the same level. Where do you put C?
 
Ok, so here's an example. I have a project for the current course I am teaching. I'd like to have a "Prepare for class" subproject that holds all the actions I need to do to prepare for a given class. Here's how the actions might look in that subproject, given the system above:

-> Review notes for today's class.
->-> Edit notes as necessary.
->-> Prepare in-class slides.
->-> Prepare in-class handouts.
->->-> Photocopy handouts.
->-> Prepare homework assignment.
->->-> Photocopy homework assignment.
->-> Make list of demonstration equipment needed.
->->-> Locate demonstration equipment.
->->->-> Setup and test demostrations.

-> Grade papers.
->-> Record grades in roster.

This subproject has two independent actions, reviewing my notes for that day, and grading the papers I'm handing back. Reviewing notes has five children and several grandchildren, while grading papers has only one child (one I often forget until the last minute). Once I review my notes and remind myself what I'm doing in class, I can then proceed to those child actions in any order I want. Of course reviewing notes and its children is independent from grading papers.

I could also have an "After class" subproject, which might have the following actions:

-> Make notes on what worked/didn't work.
->-> Incorporate any needed changes into class notes.
-> Post in-class slides/handouts to Blackboard.
-> Put demonstration equipment away.
 
Chris,

Your suggestion is interesting. It prompts several questions for me.

Currently the outline in OF indicates containment: a folder contains a number of projects and other folders; a project contains actions; and action groups contain substeps. Your suggestion is to make the hierarchy within projects indicate dependencies. So, "parent-of" is equal to "prerequisite". Do I assume correctly that you would still consider projects and folders to indicate containment? That seems like an abrupt discontinuity in the design. (Perhaps even more abrupt than that between projects and action groups currently.)

Also, currently the full containment hierarchy of a project is maintained even as I check off actions. That is, if I filter for All Actions, I can see the original hierarchy. With your proposal for promoting the children, would that hierarchy be maintained? That is, do you see the promotion to just be a rendering issue or is it actually a change to the data structure? If it is really just a rendering issue, what happens when I decide I need to add a new prerequisite to an action? Now the data structure needs to reflect multiple parents for a single action. If the promotion is actually a change to the stored data, how does one review completed projects? They would be collapsed into a single level of single actions with all dependency information lost. And what happens with repeating projects where the dependency information has to be recovered?

Finally, Suppose I have a sequential project with 20 steps. (This isn't hypothetical; my daily course prep is approximately that.) In your proposal that would be 20 outline levels deep.

I don't mean to suggest that the current design is ideal, but a simple represention of dependencies that supports all the other features we want is a very difficult design problem.
__________________
Cheers,

Curt
 
Quote:
Originally Posted by pvonk View Post
You parent-child relationship seems backwards from most/all GTD implementations I've seen. An action (or the project itself) that is dependent of one or more other actions is usually listed above the other actions.
I don't understand; in sequential projects in OF, the order is as I have it; actions that must be done first are at the top.

Quote:
Your theory implies each action is only dependent on one immediate (previous) action. If you have to perform A, B, and C (in any order) before Z, can you explain how your tree structure would be defined?
You're right, my model doesn't capture this sort of dependency. But neither does the current model.

Quote:
Also, I'm not sure I follow your "only parallel projects" idea. If I have to do A, then B, then C, your tree would look like:

A
>B
>>C
Yes.

Quote:
But the problem (as I mentioned above) is what if A or B can be done in any order and C done last. By your definition, A and B would be at the same level. Where do you put C?
That's right, my model allows multiple children, but not multiple parents. You'd have to make C be a child of either A or B.

Last edited by Chris; 2007-09-19 at 08:55 AM..
 
Quote:
Originally Posted by curt.clifton View Post

Currently the outline in OF indicates containment: a folder contains a number of projects and other folders; a project contains actions; and action groups contain substeps. Your suggestion is to make the hierarchy within projects indicate dependencies. So, "parent-of" is equal to "prerequisite". Do I assume correctly that you would still consider projects and folders to indicate containment? That seems like an abrupt discontinuity in the design. (Perhaps even more abrupt than that between projects and action groups currently.)
Yes, hierarchy would denote containment for projects/folders and dependency for actions. That's because projects and folders are by definition containers (of actions and projects respectively), but actions are not containers. I can see how there is potential user confusion, but for myself, I find the current "Action Group" paradigm extremely confusing and not useful.

Of course, how the two different hierarchies are displayed to the user is a separate matter. Right now, OF uses the same visual cues for both hierarchies. That's not necessarily the only way to do things, of course. I haven't thought about that, though.

Quote:
Also, currently the full containment hierarchy of a project is maintained even as I check off actions. That is, if I filter for All Actions, I can see the original hierarchy. With your proposal for promoting the children, would that hierarchy be maintained? That is, do you see the promotion to just be a rendering issue or is it actually a change to the data structure? If it is really just a rendering issue, what happens when I decide I need to add a new prerequisite to an action? Now the data structure needs to reflect multiple parents for a single action.
I hadn't thought of this, but it seems clear that it's just rendering. I don't see the problem you are thinking about in your last two sentences. My structure doesn't allow for multiple parents, so that's something you could never do. (Current structure doesn't allow that either, I don't think.)

Quote:
Finally, Suppose I have a sequential project with 20 steps. (This isn't hypothetical; my daily course prep is approximately that.) In your proposal that would be 20 outline levels deep.
Yes, that might be a problem if the interface for the action hierarchy used indentation. But, it would only be a problem in some views (All, Remaining, maybe Completed). Second, I wonder if your actions are truly sequential, or if you have just chosen them to be so (due perhaps to current OF limitations?). Is your prep list similar to my example above? I'd be curious what the 20 sequential step prepartion really is, and if there aren't some parallel steps in it.
 
Quote:
Originally Posted by Chris View Post
Quote:
Originally Posted by curt.clifton View Post
Also, currently the full containment hierarchy of a project is maintained even as I check off actions. That is, if I filter for All Actions, I can see the original hierarchy. With your proposal for promoting the children, would that hierarchy be maintained? That is, do you see the promotion to just be a rendering issue or is it actually a change to the data structure? If it is really just a rendering issue, what happens when I decide I need to add a new prerequisite to an action? Now the data structure needs to reflect multiple parents for a single action.


I hadn't thought of this, but it seems clear that it's just rendering. I don't see the problem you are thinking about in your last two sentences. My structure doesn't allow for multiple parents, so that's something you could never do. (Current structure doesn't allow that either, I don't think.)
Sure it does, with an additional group:

--> Parallel prereq group
----> Prereq 1
----> Prereq 2
--> Subsequent action

Or to use the naming scheme Pierre suggested above:

--> Parallel prereq group
----> A
----> B
----> C
--> Z

Quote:
Originally Posted by Chris View Post
Quote:
Originally Posted by curt.clifton View Post
Finally, Suppose I have a sequential project with 20 steps. (This isn't hypothetical; my daily course prep is approximately that.) In your proposal that would be 20 outline levels deep.
Yes, that might be a problem if the interface for the action hierarchy used indentation. But, it would only be a problem in some views (All, Remaining, maybe Completed). Second, I wonder if your actions are truly sequential, or if you have just chosen them to be so (due perhaps to current OF limitations?). Is your prep list similar to my example above? I'd be curious what the 20 sequential step prepartion really is, and if there aren't some parallel steps in it.
Here it is. Fifteen sequential actions, one of which is an action group with 5 sequential actions inside it. I'm team teaching with 2 colleagues and we're developing the materials for a course that is designed to be taught in the future by anyone in the department. Synchronizing prep is vital.
  • Create slides
  • Write in-class quiz
  • Develop in-class exercises
  • Write HW
    • Write written HW problems
    • Write programming problems
    • Set up Angel gradebook entries for HW problems and Angel quiz
    • Add a software in the real world link
    • Ask TA to do the HW
  • From Delvin, daily Angel quiz, link to gradebook
  • Add quiz question numbers to slides
  • Update course schedule
  • Move materials to Public folder
  • Update Angel page
  • Publish to web
  • Print quiz for everyone
  • Print slides, annotate with target times
  • Identify assistant tasks
  • Grade Session 3, week 3 quiz
  • Post transcript of Session 1, week 4

Not included are several "Waiting For" items that I insert as I go based on whether colleagues are providing feedback in meetings or electronically. How would that be represented in your proposed system?
__________________
Cheers,

Curt
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Keep Child from inheriting from Parent joeworkman OmniOutliner 3 for Mac 0 2011-08-03 05:03 PM
child tab after parent, not end of all? dru OmniWeb General 6 2011-04-21 01:44 PM
Parent/child question peterlemer OmniFocus 1 for Mac 3 2008-10-11 09:20 AM
THE MISSING CHILD... Losing the Parent|Child|Grandchild relationship in Context View smiggles OmniFocus 1 for Mac 26 2008-05-27 09:20 AM
I don't get the parent/child task behavior in OF wfiveash OmniFocus 1 for Mac 8 2008-01-29 11:14 PM


All times are GMT -8. The time now is 01:53 PM.


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