[tacartwright]

Originally Posted by Tim Wood

We've talked about this issue a fair bit and so far we are (guardedly) on the side of not having task dependencies more than sequential vs. parallel within a group (and a few other odds and ends).

We certainly don't want to add a full DAG of tasks since then we have to actually start doing cycle detection, violation alerts and various sundry other things that OmniPlan already does; this is supposed to be somewhat simpler than OmniPlan :)

One last comment on the DAG model, and then I will let it be.

I think my suggestion for a simple DAG model is just that: simple. DAG algorithms like cycle detection, DAG-based partial ordering, and so forth are well established and easy to implement. I really believe my proposal is simpler, a lot simpler, than OmniPlan. Further, it fits my mental model of tasks, instead of making me fit an arbitrarily simplified model. Thus, I disagree with your conclusion that a DAG model is inappropriate for OmniFocus.

HOWEVER, I admire Omni applications and your dedication to the Mac platform and I trust you guys to make good decisions for the rest of us. Let’s move on!

— Tim

[tacartwright]

Originally Posted by Tim Wood

We've talked about this issue a fair bit and so far we are (guardedly) on the side of not having task dependencies more than sequential vs. parallel within a group (and a few other odds and ends).

OK, so I’m trying hard to be happy with sequential vs. parallel tasks now! :)

Could you please explain more about how this will work and what it will mean for the Next Actions view?

Here’s what I’m guessing you mean. Each project can be marked as having either sequential tasks or parallel tasks. But, a project can have a sub-project, and a sub-project can be marked as sequential or parallel independently of its parent.

To finish beating to death my poor painting example:

1. Prepare to paint
   • Measure walls
   • Pick color
   • Buy tools
2. Buy paint
3. Paint
4. Clean up

The numbered tasks are part of the “Paint room” project, which is sequential. The bulleted tasks are part of the “Prepare to paint” sub-project, which is parallel — they can happen in any order.

Is that what you’re thinking?

Now, here’s the crux of the matter: When I start this project, which task or tasks from it will be “next actions”? To me, all three bulleted tasks are next actions — any one of them is appropriate to do next. If this is not the case, then I do not understand the distinction between sequential and parallel.

Originally Posted by Tim Wood

As far as having multiple next actions, that also seems to boil down to fiddling. As long as your actions are in rough sequential order, you'll see a next action and either it will really be actionable or you'll think about it and decide that you need to do a 15 second review of your project to reorder the next couple actions.

Agreed — “As long as your actions are in rough sequential order”! But when my actions are in parallel?

Originally Posted by duodecad

Personally, I don't want to see more than one next action per project. But clearly, from the responses here, some other folks do. I can think of cases where both options could be useful. … Would it be possible to make it a preferences option, so you can choose how many NAs you want to see per project?

Yes! Why not provide options? And furthermore, there seem to be two relevant options here:

• View only next actions? (checkbox)
• How many actions to view from one project? (number)

As it stands, kGTD shows both next actions (purple) and subsequent actions (black) in the “Actions” view. Sometimes, I have so many next actions that I want to see only those and not the subsequent ones. Hence the first option.

I want to see all next actions from each project (assuming parallel tasks mean multiple next actions); duodecad wants to see only one next action from a project. The second option above would let us select.

— Tim

[SpiralOcean]

Originally Posted by michelle

I understand your concern with having parallel and sequential tasks in the same project. We are working on that and we may be able to solve it through task groups and hierarchies.

Do you think we should allow more than one "next action" for a particular project? We've talked about it, but I don't think it's true GTD.

Michelle
The Omni Group

Some great discussion in this thread.

If you can only see the next action, how would you work with a project that has three tasks inside and the third task is dependant on being done by a date?

projectA
-task1
-task2
-task3 due in 7 days

Task 1 & 2 need to be done to complete task 3, or might even be the next action, but task3 must be done by day 7.

If the first two tasks aren't done by day 7, you'll miss task 3.

And would task 1 & task 2 be bumped up in priority because 3 is due in 7 days?

[SpiralOcean]

Originally Posted by duodecad

I totally agree. I'd much prefer manually rearranging tasks as needed. This isn't project management software, after all; we have OmniPlan for that :)

hmm... manually rearranging tasks as needed seems like fiddling.

And OmniPlan looks great for one huge project. But GTD is about multiple projects... 100 to 200 for a person.

In fiddling with OmniPlan, it felt too cumbersome. Especially with updating the time. I'm hoping that the two will work well together. Even if they aren't connected, there's always applescript! ;-)

I was even thinking of attempting to put a GTD system using OmniPlan, but the amount of work it takes to get tasks in and set was too much.

Maybe I didn't give it the proper testing.

[SpiralOcean]

Originally Posted by michelle

I understand your concern with having parallel and sequential tasks in the same project. We are working on that and we may be able to solve it through task groups and hierarchies.

Do you think we should allow more than one "next action" for a particular project? We've talked about it, but I don't think it's true GTD.

Michelle
The Omni Group

If you go back to the roots of GTD, it was just pieces of paper in a folder. I guess that could be considered only see the next action.

But in the book, Allen talks about making a list of tasks in a memopad context on the palm. That is definately seeing all the actions.

[SpiralOcean]

Originally Posted by michelle

I understand your concern with having parallel and sequential tasks in the same project. We are working on that and we may be able to solve it through task groups and hierarchies.

Do you think we should allow more than one "next action" for a particular project? We've talked about it, but I don't think it's true GTD.

Michelle
The Omni Group

Another consideration is how the next items for a project will show up?

If you are working on 50 different projects, each with 20 tasks in them, and you only see the next action for a project, what happens when you complete the first task at the top? Will the program automatically update, and show you the next task in project A? Or will it leave it as checked, forcing you to go to project B?

If the latter, this could be counterproductive, forcing a user to work on one task for a project, then another task for another project.

What happens when a user has a big deadline for one of the projects and just needs to focus on that one project? Will the software force the user to refresh to see the next task and then hunt for the next task? or will the task stay in the same place in the task list.

[Tim Wood]

Originally Posted by tacartwright

Now, here’s the crux of the matter: When I start this project, which task or tasks from it will be “next actions”? To me, all three bulleted tasks are next actions — any one of them is appropriate to do next. If this is not the case, then I do not understand the distinction between sequential and parallel.

All three would be actionable. The first of the three would be the next action.

Originally Posted by tacartwright

Yes! Why not provide options? And furthermore, there seem to be two relevant options here:
View only next actions? (checkbox)
How many actions to view from one project? (number)

Agreed — “As long as your actions are in rough sequential order”! But when my actions are in parallel?

We will have some options in this area, but fewer is better -- fewer bugs, less confusion, etc. Really I think this discussion centers around the distinction between next action and actionable. If your actions are in parallel, then you can certainly have multiple actionable tasks. But still, one of them will be picked as 'the' next action.

If you choose to view the actionable tasks, you'll see all the actionable ones. If you choose to view the next actions, you'll see at most one task per project. At least that's our thinking right now :)

Originally Posted by tacartwright

I think my suggestion for a simple DAG model is just that: simple. DAG algorithms like cycle detection, DAG-based partial ordering, and so forth are well established and easy to implement. I really believe my proposal is simpler, a lot simpler, than OmniPlan.

Sure; we here can all write cycle detection in our sleep. The UI is what would take up a bunch of design, testing, redesign, retesting, icon design, etc... We could finish the graph algorithms in minutes to an hour... the UI could take weeks to get right. I wouldn't rule out having this appear in OmniFocus at some point, but the payoff (which might be negative, see "fiddling" :) ) balanced against the work to make this understandable to humans ("see, Mom, your task graph is no longer a true DAG!") argues for something other than 1.0.

Originally Posted by tacartwright

HOWEVER, I admire Omni applications and your dedication to the Mac platform and I trust you guys to make good decisions for the rest of us. Let’s move on!

Ah, shucks... :o

Originally Posted by SpiralOcean

If you can only see the next action....

If we weren't being so cagey with screen shots and feature descriptions this would be more clear. Sorry about that :)

But, as above, I think some of this the concerns will be helped by knowing that we'd like to you be able to see either next actions or all actionable items. As to priority inheritance, that's a complex question. We'll have some tools that will help with the problem, but every time we make tools "smart", we run the risk of making them wrong and annoying some of the time. Regarding your example (task due in 7 days with two undated prereqs), I definitely agree that this is a problem we need to address somehow/someday.

[tacartwright]

Originally Posted by Tim Wood

If you choose to view the actionable tasks, you'll see all the actionable ones. If you choose to view the next actions, you'll see at most one task per project. At least that's our thinking right now :)

Ah, OK, this statement helps enormously. So, for a given project, each task falls into one of three buckets:

• Next action
• Actionable
• Non-Actionable

In a parallel project (or sub-project?), many tasks could be actionable. Exactly one actionable task will be promoted to the next action. (Based on what? Whatever is topmost in the list?) All other tasks are non-actionable. Did I get this right?

Will I be able to elect to see the non-actionable tasks in my next actions list, too? Effectively, this is what kGTD does. Or, I suppose one could say that kGTD treats all tasks with a context as actionable.

Can someone from Omni please give one concrete example that mixes sequential and parallel tasks as well as actionable and non-actionable tasks, and explain what will appear in the next actions list under various option settings? Please?

— Tim

[michelle]

Originally Posted by tacartwright

Can someone from Omni please give one concrete example that mixes sequential and parallel tasks as well as actionable and non-actionable tasks, and explain what will appear in the next actions list under various option settings? Please?

Tim,
I don't think we are ready to give a concrete example because the application is still under development and there are still some things we are trying to figure out. Also, the UI mock-ups aren't quite ready for public viewing (but trust me, they're cool!). The feedback in this thread has been very helpful and has spurred continued discussion at Omni. I originally posted on the thread because I was excited to get more customer feedback on something we were talking about internally. It's great to have so many people involved in the development process. We promise you that your feedback is being taken into account and we think you will be pleased with the end result :)

Michelle

[duodecad]

[QUOTE=Tim Wood]If you choose to view the actionable tasks, you'll see all the actionable ones. If you choose to view the next actions, you'll see at most one task per project. At least that's our thinking right now :)

This makes me so very, very happy. It sounds perfect. I hope your thinking stays there :)

Also, I think SpiralOcean's point is hugely important: say you've got 50 projects and you're working on one, and you complete the very next action and check it off. As soon as you check off one action, does the next one slide right into its place? (or if there's no next action defined, the next one that slides in is a default "Define next action" note?)

I have to say, as soon as I started trying to implement GTD, even before I discovered Kinkless, this one function is what I was wishing for. It would be wonderful: you could view your next actions by context and blow through a bunch in one context that aren't related to each other, or you could view them by project and just work on a single project, and every time you check off the current NA, a new one (the next for that same project) slides into its place.

For me these two points-- how many NAs do you see, and how do they behave when you check them off-- are related because they go to the heart of the simplicity issue. The whole point of GTD is to help me focus on getting work done, so as I said before, personally I only want to see one NA per project. But I also want it to be painless to see what the *next* NA is once I'm done with this one. The "check-one-off-and-the-next-one-slides-into-its-place" thing is behavior that's perfect on both counts. Hoo boy, I would just LOVE it if that's what OmniFocus will be able to do...!