Questions/Feature Requests for Action Groups

[Chris]

So I understand how action groups are designed to work a bit better now. I'm still undecided about where they fall on the continuum from elegant design to clever hack to unspeakable kludge, but I'll let that go for now.

BTW, on the question of whether the "parent" action of a group should ever appear in context mode, put me squarely in the "No" camp. I agree with Ken that action groups are purely a planning-mode scaffolding that allows for various dependencies for the actions themselves, so I don't ever want to see the "parent" action in context mode.

Some questions/requests:

(1) Is there a keyboard shortcut for turning an action into an action group? My current method for making a group is to make two actions, then drag the second one on top of the first one. For a variety of reasons, I find that awkward.

If there's not, I have a suggestion. One possibility would be to allow cmd-Return (when editing the action name) to turn an action into the head of a group. Then Return would create a second action (either parallel or sequential to the first action depending on the settings of the current project/group) and cmd-Return would change the current action into the parent of the group and create a new child action. Please, please, please!

(2) I would like a preference to auto-complete action groups when all the actions they contain are completed. That would eliminate some of the overhead of action groups and give me some of the behavior I was looking for in my parent/child model, without breaking the current model.

(3) If the head of an existing action group is given a start or due date, any existing actions in that group without a start or due date are given that date. (That may be how things actually work when in context mode, but I don't think the interface in planning mode fully reflects it.)

[jasong]

(1) Is there a keyboard shortcut for turning an action into an action group? My current method for making a group is to make two actions, then drag the second one on top of the first one. For a variety of reasons, I find that awkward.


Yep, take a look at the Structure menu. Command [ and Command ], plus adding aunts and children.

[jasong]

(2) I would like a preference to auto-complete action groups when all the actions they contain are completed. That would eliminate some of the overhead of action groups and give me some of the behavior I was looking for in my parent/child model, without breaking the current model.


Gotta disagree. If I have more actions to do, I'd like the chance to plan them. If you have a standing project/action group that never changes, it might work for you, and perhaps an option to "autocomplete when all actions are done" would work, but gosh, how many options are we going to have? That's the sign of an undecided application.


(3) If the head of an existing action group is given a start or due date, any existing actions in that group without a start or due date are given that date. (That may be how things actually work when in context mode, but I don't think the interface in planning mode fully reflects it.)

That could be helpful.

[Chris]

Yep, take a look at the Structure menu. Command [ and Command ], plus adding aunts and children.

All I can seem to get out of "Add Child" is a system beep.

[Chris]

Gotta disagree. If I have more actions to do, I'd like the chance to plan them. If you have a standing project/action group that never changes, it might work for you, and perhaps an option to "autocomplete when all actions are done" would work, but gosh, how many options are we going to have? That's the sign of an undecided application.


Disagree right back atcha :-). I don't think it's so much a sign of an undecided application as a reflection that users want to use action groups for different things. That's why different users have different ideas on whether the parent of an action group should show up in context mode or not.

Let me put it this way: users should never be forced to click complete on things that don't show up in context mode. In GTD, completing actions is something that happens in context mode, not planning mode, so clicking the complete button in OF is something that should generally be done in context mode, not planning mode. Since the parent actions of action groups don't appear in context mode, the user shouldn't be forced to switch back to planning mode to click them complete. Hence they should autocomplete. (If they did show up in context mode---which I don't think they should!---I would switch sides on the autocompletion question.)

Of course, that probably won't work for everyone; that's why we need a preference. I think the current default behavior is backward; the preference should be for those who want to preserve the current behavior.

If the issue is too much clutter in the preferences, I'd be happy with a hidden preference accessible through the "write defaults" mechanism from the terminal.

[Ken Case]

(1) Is there a keyboard shortcut for turning an action into an action group? My current method for making a group is to make two actions, then drag the second one on top of the first one.

That's definitely awkward! If you have two actions already you can indent the second using Command-]. Or you can directly create a child action of the current action using Command-}.

(2) I would like a preference to auto-complete action groups when all the actions they contain are completed.

There's no need to complete action groups as you're acting; the only effect of completing an action group is to hide it from your remaining list in Planning mode, and in that mode it's as simple as clicking on a checkbox. (If you'd like to check off a bunch of items at once, you can select them all and press the space bar.)

(3) If the head of an existing action group is given a start or due date, any existing actions in that group without a start or due date are given that date. (That may be how things actually work when in context mode, but I don't think the interface in planning mode fully reflects it.)

This is actually how things work behind-the-scenes now (in all modes), but you're right that the interface doesn't indicate this clearly.

The effective due date of an action is the earlier of its assigned due date and its container's effective due date. You might have an individual action that's due in November, but if you decide the whole project is due in October that action is now effectively due in October as well. If you later decide the project is delayed until December, the action's individual due date kicks in and says it's due in November (unless you update its individual due date).

Similarly, the effective start date of an action is the later of its assigned start date and its container's effective start date. If you decide to defer an individual action until November, then decide to defer the entire project until December, everything in that project including that action will be deferred to December. If you change your mind and move the start date back to October, that action will still be deferred to November (unless you update its individual start date).

Hope this helps!

[Ken Case]

All I can seem to get out of "Add Child" is a system beep.

Hmm. What item in the outline do you have selected when do this?

[jasong]

Disagree right back atcha :-). I don't think it's so much a sign of an undecided application as a reflection that users want to use action groups for different things. That's why different users have different ideas on whether the parent of an action group should show up in context mode or not.

I certainly agree a preference is needed, as there is a split on how this should work. It's just from an application development perspective, someone needs to take a stand, and a preference can be seen as a copout if it's about fundamental behavior.

I won't argue not to have the preference, but I'd much rather understand the differences in approach and build a system that doesn't require a preference.


Let me put it this way: users should never be forced to click complete on things that don't show up in context mode. In GTD, completing actions is something that happens in context mode, not planning mode, so clicking the complete button in OF is something that should generally be done in context mode, not planning mode. Since the parent actions of action groups don't appear in context mode, the user shouldn't be forced to switch back to planning mode to click them complete. Hence they should autocomplete. (If they did show up in context mode---which I don't think they should!---I would switch sides on the autocompletion question.)


Alas, again, I disagree. As part of my review to ensure that the project is really complete, I need to return to project/planning mode anyway. If, during my review I find that it's really done, I mark it as "complete" otherwise I add another action or what have you. I can't (and shouldn't) do that in context mode.

I think the current default behavior is backward; the preference should be for those who want to preserve the current behavior.

Wait a minute! I think the proposed behavior is backwards! I don't think I can be convinced that denying me the ability to review my projects by default is a wise idea.

[Chris]

Hmm. What item in the outline do you have selected when do this?

Operator error. Note to self, cmd-} requires use of the shift key.

With that said, a three-finger shortcut is a bit awkward. Would it be possible to have cmd-Return also be a shortcut for "Create Child" when the specific focus is editing an action name? This would be somewhat analogous to cmd-Return creating a new context in the context entry box. It would also be easier for me to remember, since Return would create a new non-child action and cmd-Return would create a new child action. It's also easier on my pinkie :-).

[Ken Case]

Operator error. Note to self, cmd-} requires use of the shift key. With that said, a three-finger shortcut is a bit awkward. Would it be possible to have cmd-Return also be a shortcut for "Create Child" when the specific focus is editing an action name?

You can currently use Return followed by Command-] to accomplish the same end (insert a new action and indent it) without having to hold down three keys at once. Or you can assign your own keyboard shortcut to that menu item using System Preferences.

If you'd prefer a context-sensitive Command-Return over the options I just suggested, please send us feedback (by selecting Send Feedback from the Help menu): it's probably not going to change for 1.0 (we're trying to finish the features we've already committed to doing!), but we'll consider it for future releases.

[curt.clifton]

It should also be mentioned in this thread that if you have an action or actions that you wish to group under a new common action group, you can select the actions and press Shift-g. (Cmd-opt-L also does the trick, but requires three keys and two hands the way I type.) Another extraordinarily cool thing: the actions to be grouped don't have to be contiguous! Try using Cmd-click to select every other item in a list. The Group command will pull them together under a single action group.

[brianogilvie]

Let me put it this way: users should never be forced to click complete on things that don't show up in context mode.

I must respectfully disagree, and agree with jasong. In GTD's back of the envelope planning style, an important part of the review process is determining whether an open loop has been closed or is still open. If an action group or project were automatically marked complete when all its children were completed, that important stage of the review would be bypassed.

I can see wanting the parent (action group or project) to appear in a context when all its children were completed, but I can't see autocompletion making sense in a GTD app. Maybe in a full-fledged project management app, but not a personal GTD app.

My 2 cents (US or Canadian, today anyway!)