Links / relations / dependencies between actions

Features
1

Hello there !

Recent new user of Everdo; I loved the privacy and offline aspects, loved the GTD integration, and I’m having a great time with Everdo. Thanks again for the project :grinning_face_with_smiling_eyes: !

I just wanted to propose a feature that I’ve seen, and that I think could have some great potential in everdo : Task/Actions relations or links.

I’ve been experimenting with different task-related software those past years, in parallel with note-taking software. One of the things that strikes me as a huge boost in productivity is the idea of relation and encapsulation, that allow us to make “paths” between precise units of information. This way, it’s really easy to find what we want : we just have to follow the path. No need to remember, and the mental load stays minimal when we’re being active.

In GTD, there is already a big part of encapsulation. Actions are supposed to be usable by themselves, without their broader context : we don’t need to re-read everything about a project when we want to act on it. we just need to find one of the next actions, and do it. This encapsulation is done when the action is noted, not after. At worst, a note associated to my action will just guide me toward a project resource, giving me everything I need to act.

But GTD - and Everdo as it is today - lacks the idea of relation in my point of view. That is, when we finish a task, or activate a task that was “Waiting” or “Someday”, we might need to activate others in return. This often happen in the case of projects : many projects are parallel in nature, but they have different “branches” of successive actions. We might have noted all of these actions; but we have no way of properly and quickly note their relations when I’m creating the actions, which is when those relations are clear in my mind. This forces me to re-read different lists when an action is done or when I want to start it, and look at each action one by one to think : is there something new I need to focus on now that this is action is done ?

And their can be many relations between actions or tasks; I think that Vikunja shows it well by having many different possible relations between them.

In addition, I’ve seen some debates on this forum about the possibility of “nested” lists of tasks, and the fact that this would break the kind of non-hierarchical way that GTD’s actions are made. I think that task relations would solve this issue too : tasks relations can imply a hierarchy, but it doesn’t have to be represented in the interface. Several tasks can have a relation with a “parent” task, and that’s it.

Interface-wise, or in practice, I imagine that there could be a “task relation” field when editing a task, maybe under the “tags/labels” field. There would be a search field where text would be entered to quickly find a task, by showing tasks in a dynamic list as the user types. Then, a list of relations could be chosen; the simplest would be something like “When this task is done, focus on this other task”, or “This action must be done before this one”, etc.

Now that I’ve written too much, what’s your opinion on such a feature ? Would it be useful to you ? Do you find yourself having to re-read action lists often to find relations again ? Do you write such relations already in your tasks notes ? Or do you solve this problem of relations with the structure of GTD (e.g. “Waiting” lists, etc.) ?

2

Hello Klemet. Thank you for your thoughtful post.

You are right that relationships are limited in in GTD/Everdo. You can relate an action to a project and also define a total order of actions in the project, but that’s all. A notable missing relationship as you pointed out is “depends on”. Also “is parent” is limited to just one level (project->action)

The problem is that the current data model and the UI are designed to merely support lists of actions. So adding any kind of deeper relationship-based features like dependency management requires fighting the design and potentially breaking many things. Not to mention the UI/UX challenge of editing the dependency graph, nested hierarchies and dealing with circular dependencies.

Personally, I can live without the dependency tracking between actions. I simply don’t create so many tasks in any given project at once that I would need to set dependencies between tasks. Another way I think of it, is that I work on one action at a time, so I will have to serialize the list of project actions anyway, that is assign a total order to the actions, taking into account all the interdependencies. When this is done (by making a sequential project), what is the value of tracking dependencies anymore?

As for nested projects - it’s sufficient for me to have one level of projects in Everdo - the projects that take on the order of several weeks. Anything with a greater scope I track in the big-picture context elsewhere.

3

Thank you for your reply, @Andrei !

It’s interesting to see that this might not be well integrated into the current design of the program. I thought that this might be added as a different field in the database (like a “DEPEND_ON” field relating to the unique ID of another task), but I’ll take your word that it’s not as simple as that. I don’t know if a dependency graph a la Obsidian would be needed, but I understand the challenge of putting this into the UI.

I understand your point of view; and it’s true that there already are some ways to imply the relations with sequential projects. Plus, relations could make us spend too much time writing and classifying the tasks/actions rather than doing them.

It was nice to have another view on this ! Thanks !

4

Yes, this is how project-action associations are implemented right not, but this would mean that a task cannot directly depend on more than one task.

If starting from scratch, I would definitely use an actual graph.

Yes, it’s definitely possible.

1 Like
5

I’ve been using Everdo since before version 0.0.1, and one of the inconveniences for me is the lack of support for making a project “blocked”. Another is that some actionable items in Sequential projects are hidden from Next. Both issues exist because the only relationship between project tasks Everdo can represent is sequential ordering. So the Next list can sometimes include actions that are not really actionable, which goes against the Getting Things Done (GTD) method.

With this post, I want to

  • consolidate the forum topics we have that are related to this into a single thread (the most recent one). I will close the others.
  • suggest some ideas that are feasible and ask for your feedback

To reiterate the previous discussions a bit, implementing full-blown dependency graph-style workflow is impractical for multiple reasons and doesn’t fit the product vision in terms of UX complexity and suitability in a “tactical” view of your tasks.

If I put my dreaming hat on, I can imagine Everdo having two modes: tactical (existing) and strategic where you can manage areas of focus and bigger milestones consisting of multiple projects. Dependencies between projects would make a lot of sense there. But the internals of a project would still be a purely tactical thing that is short enough that complex dependencies between tasks are not appropriate.

Anyway, back to Earth now.

A) Blocking Tags

Here’s what I do at the moment to prevent tasks from appearing in the Next list.
I created a special blocked tag that I put on the top-most Next action in a project that cannot move forward for some reason. Then I filter out such actions in the Next view.

This approach has some problems

  • Friction, so I don’t always do it
  • Very often a project is blocked by an action in Waiting and it should be unblocked as soon as the Waiting item is resolved. Again, inconvenient.

What could be done instead is supporting this workflow at the application level. For example

  • You designate a tag that will mark blocking actions, say blocked
  • There is a button/menu option/command to easily apply/remove this tag to/from any action
  • The effect of this tag depends on where it’s applied. If it’s on a sequential action, then this action or any of the following ones will be excluded from Next
  • If it’s applied to a Waiting action in a project, then all actions are blocked from Next
  • When you open Next, the blocking tag is automatically excluded

This benefit of this approach is that it uses the core functionality of the app for the most part, but I feel like it would cover a lot cases where dependency tracking is important, without a lot of UX/process burden on the user.

B) Make sequential and parallel be attributes of Actions, not Projects

This solve a different problem - sometimes you have actions that can be done at any time and some that must be done in sequence. All in the same project.

So instead of treating all actions the same, we have a project default + override at the action level. Here’s how it works

  • Any new action in a project is created Sequential, but you can set it Parallel manually
  • Both types are still mixed in one list at the project level. You can reorder tasks as before.
  • Because all tasks are on the same list, it’s important to see which is which kind. So there’s an icon, something like ->-> for sequential and ||| for parallel.
  • When the aggregated Next list is computed, Everdo will pick the appropriate actions based on your ordering.
  • If the top action is Sequential, it will appear and the rest are ignored
  • If the top action(s) are Parallel, they will appear + one of the sequential actions. The rest are ignored.

It seems to me that this way you can mix and match items into a single chain, again without much extra UX complexity and cover another big chunk of cases where you need dependencies between tasks.

A bonus is that both approaches outlines above can work together.

My questions:

  • Do you think this would work for your use cases?
  • Can you find any problems with it?
1 Like
6

If it’s applied to a Waiting action in a project, then all actions are blocked from Next

I like this idea: I have a project that, in reality, is blocked because a specific task is “waiting for”; however, the next action is shown on top as if I could/should act on it. Currently, I have to manually remember that actually, I can’t launch that procurement because I am still waiting for the last revision of the design. The approach described above would help me in that case.

However, there may be waiting for tasks that don’t block the entire project. Imagine this example project:

  1. finalize design
  2. procure equipment
  3. draft news article about equipment
  4. publish equipment

I’ve requested the design from one person and the news article from another. The procurement and the publication are now both waiting. In this case, I wouldn’t want the entire project to be blocked - the procurement should still go ahead even though the news articles isn’t written yet.

I think my underlying challenge is that not all projects are either parallel or sequential, but may be a mix of both. In the example above, 2 must happen after 1, and 4 after 3, but 1 and 3 can (and did) happen in parallel.

7

Thanks for the example, this is what I had in mind also.