[Ward]

I have two OmniFocus windows open all the time:

• Remaining Tasks -- Projects, grouped by Folder (Client), with unsorted tasks
• Due Soon -- active tasks grouped & sorted by due date

Within each Remaining Project, I manually organize the tasks as a hierarchical list. Most of the time I assign due dates to "leaf" (lowest level) tasks. Occasionally, when those leaf tasks are just details that will all be done at the same time, I'll put the due date on the parent of these leaf tasks. For example,

• Fix several related things: due Tomorrow
  • first thing
  • second thing
  • third
  • and so on

When I view these tasks in the Due Soon window, it's just a simple list for each due date group. Even though the related things have no explicit due date, they're in the list because they inherit their parent's due date. However, when OmniFocus sorts the list by due date, the leaf tasks appear before their parent:

• first thing
• second thing
• third
• and so on
• Fix several related things: due Tomorrow

It's as if OmniFocus is sorting blank due dates before actual due dates.

My wish is for OmniFocus to honor the parent/child relationship when sorting tasks with an inherited due date -- put the parent first, followed by the child tasks.

Even better, indent the child tasks so it's more obvious they have inherited a due date.

-- Ward

[submitted as formal feedback]

[whpalmer4]

What's going on here, I think, is simply the behavior of showing parents in context mode following the items which must be completed to make the parent available. You would get the same listing order sorting by a number of choices, viewed narrowly enough. No reason you can't wish for something else, of course, but there is a rationale to the behavior.

Seems to me that the graph viewed in context mode is similar to what you'd see in an RPN version of OmniFocus :-)

[DrJJWMac]

I actually wish for the current behavior in some cases but with a smarter behavior in others ...

* When a group "action" is a checked to be marked complete by completing the last action item, that group action would not even appear in a list of all actions needed (why should it, it is NOT a true action of its own). Nor would its count be included in the badge count.

* When a group is NOT checked to be marked complete by completing the last item, the group would appear as an action in the way that it is shown now.

So ....

My Group (complete when last action is completed)
- action 1
- action 2

... would tally a badge count of 2 ACTIONS (rather than 3 "items") for its project and would show only ...

action 1
action 2

in a project list, whereas ...

My Group (uncheck complete when last action is completed)
- action 1
- action 2

... would tally a badge count of 3 ACTIONS for its project and would show ...

action 1
action 2
My Group

in a project list.

[whpalmer4]

Originally Posted by DrJJWMac

* When a group "action" is a checked to be marked complete by completing the last action item, that group action would not even appear in a list of all actions needed (why should it, it is NOT a true action of its own). Nor would its count be included in the badge count.

Some people rely on the group name to figure out just which similarly named action it is. This would do them a disservice.

My Group (complete when last action is completed)
- action 1
- action 2

... would tally a badge count of 2 ACTIONS (rather than 3 "items") for its project and would show only ...

action 1
action 2

in a project list

If it doesn't show up in the project list, how do you propose to manipulate it? What will it look like? How will one know where the group ends and other actions or groups begin/end?

How does this make your life any better, if implemented as requested? I could see an argument being made for not counting the group if the auto-complete bit is turned on, but given that most actions come in widely differing sizes, it is difficult to get too worked up that one collection of actions might show up as a "7" instead of a "5" due to the counting of the groups when the total amount of work to be done might be dwarfed by a "2" or even a "1" in another project. I can also see an argument for not showing the group "header" in a context mode view if the auto-complete bit is on (though that loses you the chance to complete them all with one click), but you specifically mentioned "in a project list"...

[DrJJWMac]

Life with GTD is far better when I look at a badge count on a project and know that it shows solely the true number of action steps that I have to complete for that project rather than the number of "items" (actions and groups of actions) that are "in" that project. The latter is more of a database management approach to "stuff to do", and for GTD, I hate having to interrupt my thought processes to remind myself of such possible exceptions.

As for showing, manipulating, and hiding action groups in lists, GTD life is again far better for me when a list of actions at certain levels shows only the true actions, especially excluding action groups that are marked as "complete at last step".

So, in summary, IMHO the power of OF to set action groups as "complete at last step" or not is washed out when that setting is not taken to its full, principled approach at [edit]the time when tasks are viewed in context to be ACTED ON[/edit]. Pardon me otherwise and no dis-respect to the approach taken, but marking special names on action groups to show them as "complete at last step" versus "open for continuation" is otherwise a kludge for me. I am actually using this suggestion as such by marking action groups with "Capital Letter Titles" versus actions with small letter "verb noun statement" formats, and it helps. It still however leaves me the confusion on action groups being "complete with last step" versus "stay open for editing" at [edit] the time I am ready to DO my actions[/edit].

This is all especially true on the iPhone version, which is to be my central tool.

[Ward]

I understand DrJJWMac's preference for only "true actions" in lists and task counts. That would work for me if the name of each task is self-explanatory.

However, in the actual case that prompted my creating this thread, the group name is essential to understand the true actions:

• Remove obsolete file references from FileMaker files:
  • filename1.fp7
  • filename2.fp7
  • filename3.fp7
  • ...

I prefer entering the task description just once, followed by concise references to the specific instances.

-- Ward

[DrJJWMac]

Originally Posted by Ward

... However, in the actual case that prompted my creating this thread, the group name is essential to understand the true actions:

• Remove obsolete file references from FileMaker files:
  • filename1.fp7
  • filename2.fp7
  • filename3.fp7
  • ...

I prefer entering the task description just once, followed by concise references to the specific instances.

I can see what you mean, especially when the group action changes for example from "Remove ..." to "Copy ...". Simply put just the requisite verb in the group action than with each "sub-action".

It is a philosophical discussion on MO in OF then. In reference to this, as my SO asked me recently ... "why the heck are you needing to put the details of each and every sub-step in a simple statement `finish the report'" ... leading to a rather insightful discussion along just this line.

Anyway, an alternative that would work for your case with a change to a more principled approach to handling groups as "closed" versus "open" is to mark the group as "open" --> "do NOT complete when last action completed" and have the group name remain in the list to be checked off when all file names are done.

In any event, for me, badge counts and the occasional list of actions with group names are ambiguous as they stand. I've reverted to mostly ignoring the details of the former at the project level (using the presence of any badge count as just a marking that some actions are there to be done) and setting up perspectives in ways to minimize the confusion for me by the latter.

Thanks.

[DrJJWMac]

Originally Posted by Ward

...
My wish is for OmniFocus to honor the parent/child relationship when sorting tasks with an inherited due date -- put the parent first, followed by the child tasks. ...

Actually, now that I understand what you're asking, I vote against this idea. In a context view, where one is showing steps to act on, the LAST thing in the list should in principle be the last action one needs to complete on a given project, not the first, regardless of that action being a "parent" to the "children" above it. I'd also warrant that having a group action as the first in a list on a context view would lead more often than not to the general user making the mistake of inadvertently checking off that group action even though some action in the entire list for that group is still explicitly incomplete.

Otherwise, what you want is already shown in a Project view for planning purposes.

[psidnell]

Originally Posted by Ward

My wish is for OmniFocus to honor the parent/child relationship when sorting tasks with an inherited due date -- put the parent first, followed by the child tasks.

This is actually related to my question in this thread:

<tumbleweed>Visibility of Groups in Contexts - useful?</tumbleweed>

I think it depends on circumstance.

I mostly don't want to see the group in context mode at all.

If it's a task group I want to see the group as the last completable task.

If I've been using OF as an outliner for gathering task trees I want to see the group first.

But this would add another bag of settings to OF that would further confuse new arrivals.

[Ward]

In my Project view, the vast majority of my groups are simply containers for individual tasks that share some common property. For example, I group my FileMaker database development tasks by table name. Although the specific tasks do not necessary relate to each other, it's nice to see them together because I'll often schedule several tasks when I'm working on a specific database table.

Thus, when I schedule database development, I assign dates to the individual tasks and leave the group dates empty.

The development work that prompted this thread was a database-wide cleanup task ("Remove obsolete file references"). In this special case, I assigned a due date to the group because I intended to work on all files in a single session. The sub-tasks in this group are simply a list of files that I can check off as I do each one.

I could have created a single cleanup task and put the list of files as a note. But a note does have the handy checkboxes.

Reprise of my ideal wish: When a group has a due date, and the sub-tasks have no date, show the group line first, followed by an indented list of the sub-tasks (just like it shows in the Project view).

-- Ward