The Omni Group Forums

The Omni Group Forums (http://forums.omnigroup.com/index.php)
-   OmniFocus 1 for Mac (http://forums.omnigroup.com/forumdisplay.php?f=38)
-   -   Single Actions ? (http://forums.omnigroup.com/showthread.php?t=4098)

MEP 2007-07-08 07:58 AM

[QUOTE=pvonk]From what I've read in those threads concerning single actions, the Religion of GTD permits only one next action per project, regardless of the sequential or parallel setting.
[/QUOTE]

Actually, no. In the strictest GTD sense, every single action in your currently active list of actions is a "next action". Those next actions which are also the next logical step in a sequence of actions are highlighted purple, but they're not "more next" than the other "next actions"; they're simply the next step in a sequence. The use of the term "next action" to differentiate between those actions and any other currently active action is arbitrary at best (but an established habit in many GTD apps for some reason). The only thing the highlighting really indicates is that completing that action will result in another action being added to your currently active list of actions (unless it's the last action in the sequence).

A project can have many next actions associated with it, provided that those actions don't have to be completed in any particular order. When you view your list of actions in context view with the "active" filter enabled, you are looking at all of your next actions regardless of what is and isn't highlighted purple. In a pure GTD implementation, that's what next action means; it's any action that can be done right now, and if it can't be done right now it shouldn't be active.

It sounds like what you guys are using the highlight for is to prioritize your actions. It's like the first action in a sequence takes precedence over parallel actions (and is therefore "next" in your terminology) unless you have consciously decided (before looking at your context view) to assign the "next" state to one or more of those parallel actions (or arbitrarily assigned that state to all singleton actions). That's not the GTD way.

In GTD, the prioritization of actions occurs when looking at the action list for the currently appropriate context (whatever context you're in right now or will be in soon). You decide [I]right at the moment of action execution[/I] which action needs to be done right now. Complete that action and then look at the list [i]and decide again[/i]. One of the main points of GTD is to free the user from arbitrary prioritization schemes which have to be hierarchically assigned prior to the actual moment of action execution; schemes which require us to predict what will and won't be important at some time in the future rather than allowing us to decide in the moment what is important right now.

The purple highlight currently used for "next actions" (still an overloaded term, I hope Omni calls the style "next steps" or something else in their final build) only indicates the next step of a sequence. Every active action is a next action in GTD sense and has equal precedence on the list. If OF is to be a GTD app, that's really how it should be used. Any other behavior is acceptable if that works for you (hell I do tons of things that aren't in David Allen's book that work for me), but let's not fundamentally alter OF's functionality in any way that breaks it as a GTD app.

SpiralOcean 2007-07-08 11:15 AM

For single actions...

I create a project with a context name...

-Project Errands - default context Errands

Then when I need to do an errand that is a single action, I'll just add a task to it.

LizPf 2007-07-09 05:14 AM

[QUOTE=brooce]If they're ALL next actions, then NONE of them are next actions. [/QUOTE]

True, but beside the point.

The issue is, SOME projects have actions that can truly be carried out in parallel. Think of cooking a meal of stir-fried beef and peppers. We can do the prep work for the stir-fry in any order -- it doesn't matter whether we cut the red pepper first or the green, or whether we do the garlic before the ginger. So, under the "knife work" sub project, [B]any[/B] task can be the next step, and we might do them in different orders on different days.

However, in the "cook" sub-project, we do have to follow a series of steps in exact order. If we try to cook the peppers first, they will overcook in the time it takes to cook the beef.

Now, if we were to enter this in OF, we'd have, in Project View:

Project: Cook Pepper Beef
Sub-P: Prep Work
Task: cut red pepper Context: Knife
Task: cut green pepper Context: Knife
Task: cut beef Context: Knife
....
Sub-P: Stir-Fry
Task: Cook beef Context: Wok
Task: Cook peppers Context: Wok
Task: add ginger & garlic Context: Wok
....

In Context View, the one we'll see during cooking:

Context: Knife
[COLOR="Purple"]Task: cut red pepper[/COLOR]
Task: cut green pepper
Task: cut beef
...
Context: Wok
[COLOR="Purple"]Task: Cook beef[/COLOR]
Task: Cook peppers
Task: add ginger & garlic
....

Note the purple Next Actions.

If we set the filter to Show next actions, we can't see all the knife tasks, though we want to. But if we set Available Actions, we'd see the Knife tasks for several other meals as well. What we want (well, what I want) is to set ALL the knife work tasks in this project to Next Actions, so I could see them all at once.

[No, I don't plan out my cooking — but this is an example most people can understand.]

--Liz

Craig 2007-07-09 06:10 AM

[QUOTE=LizPf]
If we set the filter to Show next actions, we can't see all the knife tasks, though we want to. But if we set Available Actions, we'd see the Knife tasks for several other meals as well. What we want (well, what I want) is to set ALL the knife work tasks in this project to Next Actions, so I could see them all at once.
[/QUOTE]

If you want to see all those tasks but exclude those for other meals, couldn't you Focus on this project and then view Available?

pjc 2007-07-10 12:48 PM

[QUOTE=brooce]If they're ALL next actions, then NONE of them are next actions.[/QUOTE]

This isn't quite right, though, for reasons others (MEP, LizPf) have articulated. The clearest counter-example to your assertion, though, is the following:

I may have 3 "available" actions (in OF parlance) in a project, each in a different context. [B]Each[/B] one of those actions would be the "next" action for that project in its particular context.

So the current notion of "next" action in a parallel project seems like it will in fact hide the next action in that project that [I]I could be doing[/I] in my current context, if it just so happens that the "next" action is assigned to a different context.

A lot of the current work-arounds discussed above require focusing on a project, which kind of breaks the GTD context model (i.e. what's the entire set of things I could be doing right now?).

Maybe "next" should mean something different in Project vs. Context view? In "Project" it might be the next available task (to your point), but in "Context" it might be the next available task (if any) in the selected context.

Maybe OF already behaves this way? I'm still anxiously awaiting entry into the alpha club.

jelmore 2007-07-11 12:01 PM

[QUOTE=pvonk]Yes, that's what I do as well; however, GTD does not require all actions to be in projects. It's only those actions that are part of several others, making up some... project. I think we all understand this, but OF seems to be mainly project-focused at this point.[/QUOTE]

I'm not sure I agree with this assessment. I have plenty of single actions in my context lists, and work just fine out of them.

Ethan Schoonover, in one of his marvelous screencasts, said that the easiest way he found to use OmniFocus is to use the Project view for planning (figuring out what the next actions are, etc.) and the Context view for actually working out of.

If I understand the "canonical" GTD system correctly, the primary focus should be on your Next Actions and Next Action lists; that is the "horizontal view" he describes, where you see where you are in all of your projects so you can decide which NA to do, as opposed to looking the "vertical view" of the breadth of a single project (or group of projects) in Projects view.

(Of course, none of this should be construed as how you [i]must[/i] use OF; I'm speculating on some of the design decisions that have been made.)

pvonk 2007-07-11 12:17 PM

[QUOTE=jelmore] the easiest way he found to use OmniFocus is to use the Project view for planning (figuring out what the next actions are, etc.) and the Context view for actually working out of.
[/QUOTE]

Yes, I use the project view to plan and for maintenance. I also like the overview of all projects currently active. But that's the problem. Theoretically, single actions don't belong to a project, hence they shouldn't show up in any project view, which means I'm not getting an overview of everything. We need a more general "view" in place of the projects, or, within the choices of projects, we need an "all projects and singletons".

- Pierre

Terry 2007-07-11 01:59 PM

[QUOTE=pvonk] We need a more general "view" in place of the projects, or, within the choices of projects, we need an "all projects and singletons".

- Pierre[/QUOTE]

I brought this up a while ago.

[URL="http://forums.omnigroup.com/showpost.php?p=15904&postcount=46"]Change Project Name[/URL]

However, it seems difficult because this would be a major change now since everyone is used to having a view called [B]Project[/B].

Paul Hoadley 2007-07-11 11:56 PM

[QUOTE=Terry]I brought this up a while ago.

[URL="http://forums.omnigroup.com/showpost.php?p=15904&postcount=46"]Change Project Name[/URL]

However, it seems difficult because this would be a major change now since everyone is used to having a view called [B]Project[/B].[/QUOTE]
I agree with Terry's observations in the post he links above. I've also brought this up:

[URL="http://forums.omnigroup.com/showthread.php?t=3774"]Showing tasks with "No Project"[/URL]

Specifically, I wrote:

[QUOTE=Paul Hoadley]Calling it "project view" is somewhat arbitrary---it could just as well be called "task view", and projects just happen to be the way we group sets of related tasks.[/QUOTE]

Just today I've hit another wall with singleton tasks: you can't search for them in Project View—they're completely invisible in this view. I don't want to get into another argument about whether this is somehow the canonical behaviour for something called "Project View", because as several of us have noted now, that's pretty much an arbitrary name for that view. In my opinion, at least, it's certainly [I]unexpected[/I] behaviour from a general UI point of view. I can enter a singleton task via the Inbox while in Project View, but after cleanup, it becomes invisible and is unsearchable. It certainly caused some wasted time for me this afternoon—I ended up creating some duplicates of tasks I couldn't find, but which turned up later when I was in Context View.

Ken Case 2007-07-12 01:56 AM

[QUOTE=Paul Hoadley]Just today I've hit another wall with singleton tasks: you can't search for them in Project View—they're completely invisible in this view.[/QUOTE]

We're planning to make every action be visible in both project and context view, rather than only having them be visible in*the corresponding view when they have an assigned project or context.

Actions with no project (aka singleton actions) will go into some sort of "quick list" smart group in project view, and single actions will probably have their own style (colored blue?) in both project and context view.

Actions with no context will go into a smart group in the context view (perhaps the "Unassigned" context, or maybe just the "No context" context?).

Does that help?


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

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