i noticed that two of my sequential projects doesn’t work as I expected it would do. I created a project with two next actions. Both next action have two different areas (action1 = Area1 and action2 = Area2). In the next action view with All areas selected in the filter only the first next action shows up, what I expected. But when I us the global filter “Area 2” the second next Action from the sequential project shows up! Is this behavior intended? Because I can’t do this action without the first one, no matter if it is a different area.
Here is how sequential next actions currently work.
The next action is defined as the top action out of all project actions filtered by the current set of filters. So for example if you somehow filter-out the top-most action, then the second one becomes the next action. This works well in situations where the next actions don’t strictly block each other.
Instead of the current approach, we could define the next action to be strictly the upper-most action of the project. This would avoid the confusion, however it would sometimes hide actions that could be done in the current context (because they are not strictly next actions).
Thanks for the explanation…It is very difficult to define a working hierarchy… Often there are project that are not 100% parallel but also not 100% sequential… Maybe I try to put the next action that are blocked by others, in waiting for or someday/maybe…
Yes, either way is not ideal. For some reason, the scenario that you have described doesn’t bother me when I use the app. I think this this might be because my project actions often have the same context and area, inherited from the project, so they are rarely partially filtered.
The only real solution that I see is real dependency tracking between actions, but that is problematic in other ways, to say the least. So far, any UI I can think of to configure a dependency graph makes me cringe a little:)
Sorry to bring this back up, but I find this to be a common problem for me.
I often have sequential projects with actions that are in different areas / contexts. For example, a project might require that I make a phone call (phone context), then run an errand (errands context), then do something at home (home context), etc.
When I’m in any given context, and filter by that context (using either context filter, or global area filter), I see actions that I currently can’t do (just as OP mentioned). That adds a lot of extra mental effort to sort through what I see to figure out what I actually CAN do in that context, which I believe is counter to the ethos of GTD.
I think that if you had to choose one, defining the next action to be strictly the upper-most action of the project (as @Andrei mentioned above) would be more in line with what the GTD method aims to achieve with the concept of contexts.
Alternatively, adding an option to the settings menu to choose between this behaviour and the current behaviour could be a compromise that avoids the complication of implementing action dependencies.