Task relationships

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

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

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

http://cat.brunchboy.com/task-mock-up-a.gif

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:

http://cat.brunchboy.com/task-mock-up-b.gif

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

[duodecad]

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!

[Tim Wood]

One question to answer with this conversation is "how does this make you more productive?"

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 :)

Really the question boils down to how having detailed explicit dependencies will make you more productive. Sure, we can all construct cases where it would be minorly useful, but should you as the user really be spending your time here charting out dependencies on each task or should you just get back to work?

One of the real driving concerns in OmniFocus is that we don't want to add a feature if its major use it to tempt people into fiddling with it. We've toyed with the idea of adding some UI for these features and then having the app yell at you to get back to work when you try to use them ... :) :)

Still, if you have ideas about how this would make you more productive day in and day out, keep 'em coming. We've certainly thought about this a fair bit, but we may have missed something.

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.

In the first case, you should just get back to work and do/defer/delegate it. Having multiple next actions would just make you think about the issue longer, "do I really feel like doing A or maybe B... hrm... A would be fun, but ...". If you are going to do both, just do whatever comes to the top of the list next. If you aren't, defer or delegate it to get it off your list.

In the second case, I feel like there will be less overall futzing time by rearranging tasks as actually needed instead of trying to preemptively get the dependency graph absolutely correct (which you'll invariably screw up sometimes and then you'll be back in the same boat of having to dynamically reorder things as needed).

[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 :)

[tacartwright]

(FWIW, I seem to be losing posts to this forum. I swear that I replied to Tim Wood’s post this afternoon and even saw it posted on the site, but now… nothing. :( )

One question to answer with this conversation is "how does this make you more productive?"

I agree, that is a useful analytic question. But it’s not the only question. That is, the GTD system is both about productivity AND about clearing one’s mind of little details, thereby creating space for higher-level thinking. Mind like water.

If enough users find it helpful to get task-to-task dependency information out of their heads and into OmniFocus, then making the feature available (optionally) seems worthwhile.

— Tim

[tacartwright]

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]

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:


Prepare to paint

Measure walls
Pick color
Buy tools

Buy paint
Paint
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.

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?

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]

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]

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]

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]

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]

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.


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 :)

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.


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



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]

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]

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

[michelle]

duodecad, you bring up an interesting question that we have been discussing at Omni. Our plan all along has been to automatically choose your next action once you complete the current action. We recently had someone disagree with this concept. He feels that manually going through your projects and choosing your next action is part of the GTD process and it should not be automated. We feel this takes time away from actually doing actions. Are there others that have a strong opinion on this?

Michelle

[duodecad]

I'm sure other folks will chime in here, but for me, that's something that's done at the weekly review. Having to think of what the next action is every single time I finish one, for every single project, would be totally painful.

At my weekly review, I'm thinking at a higher level, looking at one project at a time and thinking through what the next several NAs will be, then moving on to the next project, until I end up with a grasp of what I want to accomplish during the coming week. If I can get those several NAs per project into my trusted system, then during the week I can just rock right through them without having to think about it too much. The weekly review is for higher-level thinking; my regular work during the week is pretty down-in-the-trenches. Having to switch back and forth between those two levels of thinking every time I finish a NA is just not feasible.

This is why I like the idea of the next action, if defined, sliding into place when you check off the current one; or, if you haven't defined one, "Define next action" sliding into place as the NA. That way you can either define a bunch of NAs ahead of time or not, depending on the nature of your project and/or your personal preference. That would be *awesome*.

[imdat]

As far as it's (a) not on by default or (b) can be switched off easily and does not interfere with my intentions, it's ok to have.

Life for me is a balancing of between 6-8 company building- and acquisition projects. Then there are the standard, recurring events/actions, communication requirements and such, which are not part of a project but nevertheless required to get all projects and the main program going well.

And for me, it's more important to have the list of actions/tasks and decide myself, based on the current context, what I'll do next.

[rickla]

I've been reading this thread with intense interest. I really don't know, even for myself, what the best way to go would be, but have a few thoughts related to the issues discussed.

Sometimes, it's great to have your software say, in effect, "Do this now", just to get some things done quickly without having to think too much. Other times, this can be dangerous, because, unless you always do your weekly review with the utmost thoroughness and great foresight, there are going to be gaps in your mastery of your situation.

A whole load of lists are of only limited help for really getting a firm grip on your situation. Some kind of graphical view is going to be essential, I think. Although Eastgate's Tinderbox sucks in some significant ways, its map view is invaluable, and I'm surprised that more software developers haven't found inspiration there. It leverages relative position and colour to render a more complete picture than lists alone can.

It's clear from the blog that Omni people involved with Focus have been thinking about leveraging Omni's graphic expertise in interesting ways. I hope this isn't put aside in the desire to make things simple. No reason why it can't be simple on the surface and by default, but also include hidden depths.

[LizPf]

One question to answer with this conversation is "how does this make you more productive?"

Really the question boils down to how having detailed explicit dependencies will make you more productive. Sure, we can all construct cases where it would be minorly useful, but should you as the user really be spending your time here charting out dependencies on each task or should you just get back to work?...
Still, if you have ideas about how this would make you more productive day in and day out, keep 'em coming. We've certainly thought about this a fair bit, but we may have missed something.


I would really like the DAG model. This is how my work life operates.

I'm a high tech person in a Luddite job -- I'm a housewife and stay at home mom. I have a vast array of different types of actions I need to do, and the context / single next action for each project doesn't work well. [I tried, KGTD is great, but just didn't work out.]

I'll take one "project" -- my child's birthday party. There are lots of sub projects: food, entertainment, decorations, guest list, birthday presents, ... There are dependencies all over: my son and I have to decide on the guest list before I plan the menu (I cook differently for 3 kids vs. 13). I can buy some things at any time; others have to wait until I have the Rsvp's and know how many guests there will be. When I do shop, since the party store, crafts store, and supermarket are in the same place, I won't shop until I have to go to all three.

Now, I've done enough parties that I can schedule a lot of this mentally -- but I'm not planning one party in a vacuum. I have two kids with birthdays 5 days apart, in late October -- so I have to coordinate 2 parties and Halloween at once. And I only want to go to that craft store once for all three projects. I need to set up both Do and due dates (to borrow from another thread) so I'm not making 2 cakes and sewing a wizard robe, all in one day. Plus, there's the standard cooking, cleaning, running kids to activities, etc. {Hmm ... anyone want to trade for a nice, simple desk job, like office manager at Omni?:D }

I *need* a GTD program that lets me plan everything out, including all the dependencies. Then it needs to hide things I can't do yet, so I don't see hundreds of actions. I need to be able to easily find out "What else can I do when I go to the craft store?" I don't see any way of setting up all this without some form of DAG system.

[tacartwright]

Our plan all along has been to automatically choose your next action once you complete the current action. We recently had someone disagree with this concept. He feels that manually going through your projects and choosing your next action is part of the GTD process and it should not be automated. We feel this takes time away from actually doing actions. Are there others that have a strong opinion on this?

Yes, I believe that there is a human element to selecting one next action from a list of possible next actions that cannot be automated, at least not always. The GTD book even talks about scanning your list for a next action that fits your time available, priorities, energy level, mood, interests, etc.

And stepping back just a bit, GTD is more than a productivity-enhancing system. Forcing all feature discussions to be measured on the productivity scale seems to miss something essential about the GTD system. Yes, it helps with productivity. But it’s also about getting little details out of your head into a trusted system so that (a) you remember and can intelligently manage your work to fit your life and (b) you can spend time thinking about higher-level things more often. IMO, discussions about OmniFocus features should treat these goals as being equally important as productivity and time-savings.

Now, having said all that, I think it would be a fine OPTIONAL feature to have automated next-action selection. It should come with a simple switch to bias it toward depth-first or breadth-first selection: that is, to prefer taking as many tasks as possible from a single project or to prefer taking one task from as many different projects as possible. Not only do I think that this should be an optional feature, but I think it should be easy to toggle between using it and not.

To put it a different way, there are times when I know that my tasks are all about equal and I’m fine being fed an automated stream of tasks. And just as often, there are times when I want to use my brain to pick the most appropriate tasks. This, I believe, is consistent with the word and spirit of GTD.

— Tim

[tacartwright]

I would really like the DAG model. This is how my work life operates.

And what better method for designing software than, “This is how my life/brain/job operates”?

LizPf: Great examples, especially from a work domain traditionally underserved by software!

Once again, let me say that I think a full DAG model and its required interface would make a great OPTIONAL feature. If it must wait for version 2.0, I understand.

— Tim

[tacartwright]

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 :)

Really the question boils down to how having detailed explicit dependencies will make you more productive. Sure, we can all construct cases where it would be minorly useful, but should you as the user really be spending your time here charting out dependencies on each task or should you just get back to work?

I have another data point on the value of the DAG model. After reading LizPf’s comments yesterday, I told my wife about the debate in this thread. I wanted her feedback, because she’s in a similar position as LizPf — very busy stay-at-home mom. I tried to present both the DAG model and the sequential/parallel task groups models as neutrally as possible. My wife’s basic response was to say that the sequential/parallel system made no sense to her at all, but that the DAG model (specifically, declaring prerequisites where needed), would be very helpful.

Now, I generally categorize my wife as being technically non-savvy. Technophobe might be more accurate. So I fully expected her to say that both prerequisites and sequential/parallel groups were all nonsense. Instead, she agreed with LizPf and said that recording some task dependencies would in fact help get some noise out of her head. It’s one of the things that makes her life hard — remembering what depends on what — and that becomes critical to her when she has only a brief time between childcare duties to get things done.

Version 1.5? :)

— Tim

[Ken Case]

I *need* a GTD program that lets me plan everything out, including all the dependencies. Then it needs to hide things I can't do yet, so I don't see hundreds of actions. I need to be able to easily find out "What else can I do when I go to the craft store?" I don't see any way of setting up all this without some form of DAG system.

It sounds like what's needed is good integration between OmniPlan (which is the right tool for planning out a complex project with lots of dependencies) and OmniFocus (which is the right tool for showing you what you can do now). This is part of the roadmap for both products, though not for version 1.0.

[tacartwright]

It sounds like what's needed is good integration between OmniPlan (which is the right tool for planning out a complex project with lots of dependencies) and OmniFocus (which is the right tool for showing you what you can do now).

I disagree that this is a solution to my request. OmniPlan is overkill for what I want, and I have no intention of buying it. Even if I did, my wife would never use it.

IMO, adding prerequisites to tasks would not make OmniFocus too complex, especially as an optional feature. I do not understand the apparently deep objection to this feature at Omni.

— Tim

[Ken Case]

Hmm. There isn't a deep philosophical objection to the notion of dependencies, but I think the easiest interface to a set of tasks and their dependencies would be a graph, and we've already built a tool for editing such graphs.

Would you mind if I reverse your question? I guess I'm not sure I understand what the objection is to using OmniPlan. We've designed OmniPlan to be very approachable, so you can quickly enter a list of tasks (in a simple outline) and then indicate their relationships by dragging between them on the graph. (You can ignore all the rest of the complexity in OmniPlan until you need it.)

I thought there might be an issue with using OmniPlan due to its cost (which would certainly be an understandable factor), but since you just indicated that your wife would never use it even if you did buy it perhaps I'm missing some other concern?

[SpiralOcean]

There isn't a deep philosophical objection to the notion of dependencies, but I think the easiest interface to a set of tasks and their dependencies would be a graph, and we've already built a tool for editing such graphs.


I think for much of this conversation, it's difficult to talk about because we don't have something to refer to. So much of it is brainstorming and speaking from what we already know from applications out there.

There is probably some resistance to the notion of dependencies with Omni because they have a product called OmniPlan which they have put a lot of work into and they don't want to have their products compete with each other.

So much of this depends on how well the two will work together. But OmniPlan does seem like too much work to get your tasks into.

When it first came out I was salivating over it, but the more I used it the more I began to think it was too much work for managing... 2000 tasks. Which I have in my current system.

To manage that kind of tasks, an application needs to be fluid and quick. Entering and then dragging creates a lot of upkeep with the tasks.

Maybe I'll give it a try again, but to commit to an application, a user needs to feel when they spend 8 hours entering data, that they won't be locked into a nightmare of upkeep and still don't trust the system and end up abandoning it.

Another large reason for not adopting OmniPlan is each document is a plan. I want one software, where I can put everything into. My hub. A GTD definition of a plan is anything that takes more than one task.

I couldn't figure out how to work that out in OmniPlan. And I don't want to have 200 documents that I have to sort through.

OmniPlan would be excellent for reporting and visualizing... that's for sure.

I wonder how many people at Omni use GTD to it's full extent and have done the full sweep of putting everything into it... everything. Not just one or two projects, but everything in your world.

[SpiralOcean]

Just looked at OmniPlan again... and it has some great things in it.

I can include more than one context (if I use resources as contexts), but a simple checkbox for when the item is done was a big deterrent for me.

It doesn't allow me to drill down into contexts, like show me all the calls at work. I would have to create a home calls resource & work calls resource.

I like setting the hours, especially by typing, but trying to complete a task... well it's hard to see what's completed. I like how you can see how much of the task is there to complete and how much has been done, but to drag the mouse over is too much time. Unless it was a huge project I was working on. Checkboxes to complete at 100% would be nice.

Also, completing items in the resources area would be cool.

The scheduling around times is a great idea. But I have two different time blocks... work & home. Those are the big ones. If there could be multiple projects in one document and allow projects to reside in different time blocks... I may just switch over just for that. :-)

I love the idea of auto scheduling. One of my most difficult tasks is judging how much time I have to work on something and how much time it's going to take, and setting a realistic deadline with a client. This is soo close to be able to let me do that, but it doesn't take into account all the other things I am doing. Hmm... something like this with iCal may be nice. If it could read my appointments in iCal and schedule around that.

I'm very excited to see how OmniFocus & OmniPlan will work together. OmniPlan almost changed my world, I'm hoping OmniFocus & OmniPlan together will do just that. :-)

[tacartwright]

There isn't a deep philosophical objection to the notion of dependencies, but I think the easiest interface to a set of tasks and their dependencies would be a graph, and we've already built a tool for editing such graphs.

I disagree. I presented an interface suggestion in this thread that I think is far simpler than a graph. I have shown these interface ideas to people, and they (plural!) have gotten it immediately.

Remember, I’m not talking about the same degree of dependency tracking that OmniPlan has; in particular, I think the dependency type information is too complicated for OmniFocus.

So, I’m looking for a middle ground between no dependencies and OmniPlan, which has a great interface for what it does.

Would you mind if I reverse your question? I guess I'm not sure I understand what the objection is to using OmniPlan.

Fair question! Cost is definitely a factor. However, for my work projects, it is conceivable that I would use OmniPlan for some projects.

But frankly, I think complexity is a factor, even for me. Especially for my non-work projects, I do not need the extra features of OmniPlan and thus do not want the added burden of using two separate applications to track what, in my mind, is a single entity.

And getting my wife to use OmniPlan is even less likely. Remember, she’s the technophobe. I can barely sell her on using a computer and a few basic apps, let alone a pair of apps for a single purpose.

However, I firmly believe in getting real user feedback when designing interfaces, so I pledge to show OmniPlan to my wife and see what she thinks about setting up tasks and dependencies in it. I will report back.

But again, I want to stress that I’m looking for the simplest possible solution to get OmniFocus to address my needs. And I think a bare-bones way of tracking prerequisites — without a fancy graph view! — would do the trick and would be simple. For that matter, I can think of even simpler graphical representations of my interface proposal. If you’re interested, I’ll try to mock something up.

— Tim

[bluebaltic]

I'm pretty new to the GTD system, but it fits better with me than other systems I've attempted to implement in my 15+ years of interest in personal productivity. I am beginning to use it with OmniOutliner, DevonThink, iCal and a Palm T/X. Time and time again, the biggest issue has been -- for me -- keeping the tools simple. For me, simple is superior.

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

This sounds very good to me. OmniPlan is an option if I need to deal with greater complexity.

NOW FOR SOMETHING (ALMOST) COMPLETELY DIFFERENT

My only "NEED" not discussed in any of the threads is having OmniFocus implement, in some form, a feature of a (cludgy) product that I hate to love (called Life Balance). It isn't GTD, so it isn't really on task to bring it up. However, one feature in Life Balance is nice and doesn't necessarily conflict with GTD.

Specifically, I find it really useful to have my system (tasks/Life Balance) warn me that I'm losing track of some personal priorities (life balance) due to external urgencies/priorities. Is there any strategy inside of current plans for OmniFocus that might allow me to have the software suggest re-prioritizing based on personal values as Life Balance does? To me this makes a lot of sense, even though it would probably be a hybrid approach.

Does it make sense, at all-to anyone, to make this a separate thread, i.e. Life Balance strategy within GTD?

[Ken Case]

And I think a bare-bones way of tracking prerequisites — without a fancy graph view! — would do the trick and would be simple.

OK, that seems reasonable enough. It won't be in 1.0 (we're trying to ship as soon as possible), but we'll definitely take a look at this afterwards.

[tacartwright]

OK, that seems reasonable enough. It won't be in 1.0 (we're trying to ship as soon as possible), but we'll definitely take a look at this afterwards.

Yay! Thanks. And will you consider having the prerequisities affect the definitions of actionable? That would totally make my day, whenever it shows up.

[Added after first post:] And let me say on this thread, too, that I think it’s great that the Omni staff are listening to our discussions and taking them seriously — thanks, folks!

— Tim