[tacartwright]

One cloud of features I’d like to see might be lumped into a group called “task relationships” or something like that.

Here are some observations from my own planning and attempts at getting things done (both lower- and uppercase). Some tasks depend on the completion of other tasks before they can be started. This sort of dependency is a staple of project management software, but is rarely modeled in personal productivity software. Nevertheless, it’s important. Frankly, when scanning for tasks to do Right Now, I don’t even want to see the tasks that cannot be done yet due to a dependency. Show me what I can do now.

On the flip side, there are times in most projects when there are many next actions that can be done Right Now, because they don’t depend on each other. In this case, I want to see all of them. Again: Show me what I can do now. How I select a task in this case — at least within a project — will depend on things like priority, effort involved, context, due dates (and do dates), etc.

For your inner geek, let me propose the following model for tasks. Within a project, tasks can be organized as a Directed Acyclic Graph (DAG). Maybe all tasks can be organized this way, even across projects, with the default case that cross-project tasks are independent. I think a DAG is sufficient to describe the sorts of dependency relationships that tasks have.

In any case, the real question is how to add this sort of functionality without destroying the interface and without complicating it unnecessarily for people who don’t want to use it. I haven’t looked at OmniPlan, but clearly the Omni folks have some thoughts about task relationships and user interfaces.

[michelle]

We're experimenting with the idea of parallel vs. sequential projects. If a project is marked parallel, the actions can be done in any order. If a project is marked sequential, the actions must be done in a specific order. Regardless, your next action will always be the action at the top of the list (and you can reorder the list manually at anytime) Sound good?

Michelle
Omni Group

[tacartwright]

Hm, yes and no. I am pleased that you’re trying to address the issue, and recognizing the sequential and parallel aspects of projects is good. However, I’m concerned that tagging whole projects as one or the other might be too simplistic.

Let me offer a contrived but realistic example. I decide to paint a room in my house. Right now, I can do certain tasks: estimate the square footage to paint, buy tools, pick the paint color, and so forth. But until I estimate the square footage AND pick the paint color, I cannot buy the paint, and until I buy the paint, I cannot do the painting. This painting project is neither strictly sequential nor parallel, but rather has elements of both. And note how some tasks (e.g., buying paint) may depend on more than one prior task being completed.

Also, when a project has parallel tasks, there is no one “next action”. At the beginning of my painting project, I have three next actions: estimate, buy tools, pick color. Why should one of those actions be privileged over the others (unless I set different priorities, or some tasks are out-of-context, or some other factor tips the balance)?

Now, please understand me, I realize that this is a complex model to build an interface for. I am a software developer myself and I recognize pain when I see it!

But just because it’s complex doesn’t mean it isn’t a key part of the problem domain. Almost every real project that I do has both sequential and parallel elements to it, just like my painting example.

So, I will try to think of interface ideas for dealing with a true DAG model of tasks. First, I need to look at what you (collectively) have done with OmniPlan! And if you guys want to talk about it more, we could arrange a phone call or something; email/forums are handy but sometimes tedious to discuss design ideas.

— Tim

[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

[tacartwright]

Originally Posted by michelle

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.

Yes, I think that having more than one “next action” for a project should be allowed. If it was an optional feature, then purists could have it their way, too.

I’d be really interested to know what David Allen thinks about more than one “next action” — while not mentioned in GTD (I think, but then I loaned out my copy), it certainly seems to fit the spirit of it. Perhaps it’s not in the book because it’s hard enough to do all the bookkeeping even with one next action per project, if you’re using paper and pen.

Again, I’m convinced that a simple interface to a DAG model of task dependencies would cover nearly all the cases that most people would care about. Anything fancier could be deferred to OmniPlan… But, see my next post…

— Tim

[duodecad]

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

Michelle-- funny, I was just thinking about this issue last night. 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.

I've purchased OOP and have been trying to learn Kinkless recently, and one of the things that frustrates me is that I can see more than one next action at a time. Yes, the very next one is color-coded purple and all those that follow it are black, but the color coding is not enough of a differentiation for me. I just don't want to see multiple NAs -- even if they can be done in parallel, no dependencies. Maybe as I get better at GTD this will change, but I'm still pretty new, and find that keeping it simple is important for now.

One of the challenges, for me, with GTD is that for some projects, you don't plan them all out because they may be subject to change. For others, however, like the painting example in this thread, the steps aren't going to change. Thus I can parse them all out ahead of time, get them into my trusted system in one fell swoop, but that doesn't mean I want to *see* them all at once from then on. One NA at a time works best for me.

Would it be possible to make it a preferences option, so you can choose how many NAs you want to see per project? That would be so helpful!

[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 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.

[tacartwright]

Originally Posted by tacartwright

I will try to think of interface ideas for dealing with a true DAG model of tasks.

OK, here goes!

First, I did look at OmniPlan. It allows one to specify both prerequisites and (follow-on) dependencies for every task. And then, there are four different kinds of relationships for each, to capture how the dependencies interact with timing. This level of detail is too complicated for OmniFocus, IMO.

I remembered that one can describe a task DAG purely in terms of task prerequisites. Using my painting example:

Decide to paint: no prereqs
Measure walls: prereqs = Decide to paint
Pick color: prereqs = Decide to paint
Buy tools: prereqs = Decide to paint
Buy paint: prereqs = Measure walls, Pick color
Paint: prereqs = Buy tools, Buy paint

Thus, once “Decide to paint” is done, there are three “next actions”: Measure walls, Pick color, and Buy tools. “Buy paint” doesn’t become a next action until “Measure walls” AND “Pick color” are complete.

In this way of thinking, all the interface has to let you do is add, review, and delete prereqs for each task.

Here’s a crude mock-up of my interface idea:



This is a fragment of an OmniOutliner/kGTD document (as a base). I added an extra column for prerequisites. If a task has prereqs, then it gets a “prereq icon” to its left: a blue curvy arrow with red circle that tells how many prereqs there are. So, Task 3 has 2 prereqs, Task B has 1, and Task 1 has none.

The mock-up shows a prereq being added: You drag the prerequisite task over the prereq column for the dependent task. In this case, we’re making Task B a prereq of Task C — a blue arrow appears next to a task with no prereqs to provide a target for dragging. Once this drag is released, Task C will have a blue arrow with a red circle and the number 1.

Here’s another mock-up to show how to review the prereqs for a task:



Here, we have clicked the prereq icon next to Task F. Task F itself is highlighted in one color — probably the default highlight color — and its prereqs (Task A and Task E) are highlighted in another color. I think something like this satisfies the “review prereqs” use case.

When a prereq icon is selected, I think hitting the “delete” key (or picking a menu item) would be sufficient to delete all of the prereqs associated with the task. I’m not sure how to delete just one prereq from the list. Contextual menu on the prereq icon? Not sure.

That’s about it for a basic interface.

Now, I think the entire prereq system should be optional — some users might be intimidated by even this much. No problem, just leave out the extra prereq column. Then, all tasks are considered sequential (or parallel, or leave the choice as an option).

And even when the prereqs are being used, I think it should be optional whether the “Next Action” view lets you see tasks that do not have prereqs met yet. I don’t want to see them, but others might.

Finally, just to make sure there are no legal issues here, I place all of these ideas into the public domain. May the best GTD system win! :D

— Tim