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

 
Should sub-projects work like projects? Thread Tools Search this Thread Display Modes
I find some of the UI differences between projects and sub-projects to be confusing, specifically because they have similar functions implemented in differing ways. Let me explain.

Projects and sub-projects can both:
  • be marked as parallel or sequential
  • have a default context

But the method of changing and viewing these attributes is completely different between projects and sub-projects.

To change the parallel/sequential attribute:

Project
  • click the parallel/sequential icon on the project entry in the outline
  • click the "actions must be performed in order" checkbox in the project inspector

Sub-project
  • right click on the sub-project entry in the outline, and click "Parallel"

For the project, I can see an indication of this state by hovering over the project's outline entry, or glancing at the project inspector. While for the sub-project, I have to right-click on it to see the "Parallel" menu item checkmark.

To change the default context

Project
  • Right-click on the project and choose the default context from the "Default Context" sub-menu. The only way to know what the default context is is by viewing this menu.

Sub-project
  • Right-click on the sub-project and choose the default context from the "Context" sub-menu. The default context is directly visible on the sub-project entry, as well as through the "Context" sub-menu.

Why the differences? When a task is promoted to a sub-project, shouldn't all references to "Context" be changed to "Default Context"? (As I was typing this, I discovered the "Action" inspector, which is a consistent place to change the context for projects, sub-projects, and tasks. But I still think the terminology should be kept consistent.)

Last edited by dmw; 2007-07-03 at 06:02 AM..
 
I have a related issue. I have a sequential sub-project under a parrallel project. The first item in the sub-project is not highlighted purple as a next action even though it is one. I'm sure Omni plans to address this one already, but I'll let them know by report anyway.
 
Similar problem here:

I have sequential projects which have sub-projects that are parallel. To achieve this status, I have to switch the project to parallel, make the sub-projects parallel and put the mother project back to sequential. Just selecting "parallel" doesn't work.
 
Quote:
Originally Posted by MEP
I have a related issue. I have a sequential sub-project under a parrallel project. The first item in the sub-project is not highlighted purple as a next action even though it is one. I'm sure Omni plans to address this one already, but I'll let them know by report anyway.
The current definition of next action allows only a single next action in a project. For example:

Code:
 - Parallel parent project 1
    - Sequential subproject
        - Action 1 (<-- single next action for project 1)
        - Action 2
    - Action 3 (<-- available action, but not the next one)

 - Parallel parent project 2
    - Action 4 (<-- single next action for project 2)
    - Sequential subproject
        - Action 5 (<-- available action, but not the next one)
        - Action 6
    - Action 7 (<-- available action, but not the next one)
If I understand correctly, you would like Action 5 above to be marked as a next action also. I wouldn't be so sure that Omni plans to address this. The current definition of a single next action per project is clean. I haven't seen a better definition of next action that would work consistently.

I argued elsewhere that all children of a parallel project should be Next Actions. In my example, that would be actions 1, 3, 4, 5, and 7. But it turns out that is actually the definition of Available Actions, so it doesn't make sense for that to be used as the rule for Next Actions. So I just use the Available Actions filter and ignore the style difference between purple and black.
__________________
Cheers,

Curt
 
Quote:
Originally Posted by curt.clifton
So I just use the Available Actions filter and ignore the style difference between purple and black.
By the way, if you are (or anyone else is) wholly uninterested in this distinction, it's easy to remove the style difference between purple and black. Put the cursor within a purple next action, hit Cmd-T to show the font selector, hit the text color box (it's light green in the toolbar area), and select black.
 
I've got to be honest, I don't think any action in a parrallel project should be marked as "next" (purple highlight) except for the first action in a sequential sub-project. To my way of thinking (and way of using GTD), every single currently active action on my action list is technically a "next" action by David Allen's definition of the term. The purple-highlighted next actions only indicate next actions that are part of some greater sequence of events and therefore could be seen as triggers that alter the next action list (since the following action will become active when they are clicked).

I can't imagine any other reason why the distinction between purple next actions and every other next action would exist. They're all "next actions". That's why they're active on the list. If they can't be done "next", meaning right now, they have no business showing up as active actions in the Context view.

Last edited by MEP; 2007-07-03 at 04:27 PM..
 
Quote:
Originally Posted by MEP
I can't imagine any other reason why the distinction between purple next actions and every other next action would exist. They're all "next actions". That's why they're active on the list. If they can't be done "next", meaning right now, they have no business showing up as active actions in the Context view.
As I mentioned in a thread back in May, they may all be logical next actions (i.e. you could do any of them next, in terms of workflow), they may not all be semantic next actions, i.e. the one you think you want to get done more than the rest. Otherwise the distinction between "next" and "available" simply collapses. Since you can drag actions to reorder them in a parallel project, it might be useful to have the first action distinguished from the others. (It's useful for me, at least.) If the distinction doesn't matter, then you can just change the style for next action to make it identical to available actions (since, in a sequential project, only one action at a time is available).
 
But the distinction does matter. A purple action will alter my list of actions (by adding whatever comes next after I complete it), a grey one will not. The inability to highlight the next step in a sequential list of actions just because they're a sub-project seems arbitrary to me.
 
MEP,

Your definition of a next action as one that, when completed, makes another action available is logically consistent, but I'm not sure that the name "next action" really describes this idea. It certainly isn't what first comes to mind to me when I read "next action".

Your idea seems to be related to the idea of "critical paths" in Gantt charts. A critical path is essentially the sequence of dependent actions where the delay of any one of them delays the completion of the project. I wonder if there is a better name for such actions in a GTD context. Maybe "critical actions"?
__________________
Cheers,

Curt
 
I can definitely agree with that. I think the term "next action" is overloaded at this point. Even in Kinkless, I didn't think that was the best term since every action tracked in Kinkless should be a "next action" by the GTD definition.

Even changing the name of those actions to "next step" would make more sense to me in the context of a sequential set of actions, but I'm sure there are better terms than that too. "Critical action" sounds too much like "high priority" action to me, but I do get the relation to Gantt charts there. I think maybe Omni should consider changing the name of that style (if it is named at all that is, I haven't dug that deep yet) to better reflect what the distinction really means.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to make OmniFocus work for complex projects? Indyprint OmniFocus 1 for Mac 11 2011-12-12 11:15 PM
Context Help : Work Projects sootylad OmniFocus 1 for Mac 3 2011-01-24 01:41 PM
Workflow for Freelance work projects? robrecord Applying OmniFocus 2 2010-10-19 04:46 PM
Autocomplete projects doesn´t work? Nicolas_Thomsen OmniFocus for iPhone 5 2009-03-16 10:28 AM
How projects and parent/child actions SHOULD work Chris OmniFocus 1 for Mac 36 2007-09-21 08:19 PM


All times are GMT -8. The time now is 10:11 PM.


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