Actiondependencies
This is meant to become a proposal for adding dependencies to Tracks. Please feel free to comment and update with your ideas.
Actions in Tracks are supposed to be next actions. In reality actions could become dependent on other actions to be finished first. Tracks need to be able to handle this. Please note that Tracks is not a planning tool. Tracks is a tool for managing GTD-like next actions
The scope of this proposal is dependencies between actions.
A pending state is added to the Todo state machine, and a new event block is introduced for switching from active to pending state.
This seem to be one of the main questions for debate, i.e. if an action should be able to depend on more than one action. Trying to summarize the discussion it boils down to the question:
Do the benefits of multiple dependencies outweigh the added complexity?
More on this under open issues below.
The dependency information is used in the GUI for displaying only actionable active actions. The views affected are: New/Edit Action, Home, Project, Tickler, Context, Tag and their mobile counterparts.
Use cases are:
1. Adding a predecessor to an existing action.
2. Adding a predecessor to a new action.
3. Removing a predecessor for an existing action.
4. Showing the predecessor of an action.
The add and edit action forms have an added field for adding predecessors named “Depends on”. Ideally, it would work as a Gmail-like multi value autocompletion field.
RB: I don’t know if the autocomplete will work. You need to know exactly the wording of the action. But other options are perhaps even more cumbersome to use (i.e. first select project and then the action)
HB: Advanced auto completion fields like Gmail’s and Firefox’s address field does not actually require exact wording. They start matching words inside sentences. Also, drag and drop as Yoichi mentioned may work to add dependencies, especially in project view.
Use cases are:
1. The user only wants to see the actionable actions.
2. If an action is completed, any pending actions should be displayed.
3. The user wants to add or delete dependencies and see pending actions.
In the Home and Context views, the GUI does not have to be visibly changed to implement a first version. The user will experience that only actionable actions are displayed.
In the Home, Context, Project and Tag views, if an action is completed any pending actions will become active.
The Project view is probably the best view to view and edit dependencies and pending actions.
Example project view:
Let’s say that we have the following actions in our Add dependencies to Tracks project:
1. Create GUI proposal
2. Collect opinions
3. Implement revised GUI proposal
4. Learn Ruby
5. Learn ORM
The second action is dependent on the first action. The third action is dependent on the second, fourth and fifth action.
Using dependencies when displaying Active actions we get 1, 4 and 5, since they are not dependent on other actions. So, what about 2 and 3? How shall we display them? We could use a new section called “Blocked actions in this project” or rename the Deferred section. After the Context link the > and < links represents unique successors and uncompleted predecessors respectively.
The Create GUI proposal action is placed on top because it has the greatest number of successors (unblocks largest number of actions).
The Collect opinions action is placed on top of the blocked actions because it has the least number of predecessors (most likely to be unblocked first).
RB: Why do you want to show < and the >. I think the depends-on relation is enough. How relevant is information on the > relation?
HB: Especially for the active actions I think it is relevant to see the number of pending actions for an action. For the pending actions, it may be more relevant to see the predecessors.
Today we use due date, show date and entry order for calculating the display order for actions in the Home, Tickler and Project page. The current display order in the project page is as follows (TBC):
RB: I was thinking of adding a plus to a next action that has one or more dependent actions
HB: You mean in order to be able to expand/collapse the “depends on”/“pending” actions? I am pretty ok with that also, but see that more as a generic way to display more information about an action. If it is simple to implement, go for it, otherwise I think it would be enough with the simple visual cues given by < and > symbols with tool tips.
RB: I think it could be a good way to start with the dependencies with a container with the ‘blocked’ actions and later-on bring the plus to it. Indeed to be able to hide the non-next actions in the view, but be able to show them for review / edit
HB: Is this related to your concern of showing actions more than once? Can this information be display in a tool tip or pop up instead?
RB: with n-m yes. With 1-n, the plus is not easy to implement. So, just phasing here…
Displayed in Home and project views.
Condition: show date=null or show date<=today.
Sort order: due date, entry order
Displayed in Tickler and project views.
Condition: show date > today.
Sort order: show date, due date, entry order
Dependencies gives us one further condition for displaying actions.
RB: this is the same heading as before. Is this the project view versus the home page view above?
HB; The intention was rather project page in “No dependencies” vs “Dependencies” view
RB: ok, changed the title
This is quite straightforward. Filter on uncompleted predecessor count.
Condition: (show date=null or show date=today) and uncompleted predecessors=0
Sort order: due date, descending number of successors, entry order
Treat a blocked action as having the latest show date of its predecessors. This makes the blocked action to be sorted into a place where it typically makes sense.
RB: I’m not sure what this means for the home page.
HB: The home page only displays active actions, so it will mostly affect the Project, Tickler and Tag views I guess?
Condition: show date > today or uncompleted predecessors > 0
Sort order: show date, due date, predecessor count, number of successors, entry order
RB: I’d like in a second phase
1. Create GUI proposal (+)
– Collect opinions
– Implement revised GUI proposal
2. Learn Ruby
3. Learn ORM
RB: I find this very complex. Can’t we just use < and > and use the tooltip to sum up the dependencies. This is probably why a favor the plus :-)
HB: For users or developers (or both)? I hate it when users don’t understand how user friendly my apps are :-). Ok, my intention with multiple < and > was except displaying the number of dependencies, also the possibility to link or display information on the different actions. What you’re after is perhaps something more along the Notes toggle icon? So, what about some sort of “link” icon instead of the plus sign?
RB: in this case both :-) I think it is to much information in a few icons.
- Do the benefits of multiple dependencies outweigh the added complexity?
Where do you see the most complexity in implementing a many-to-many relationship?
RB:
1. Technically: depending on how you show the relationships, it could mean that you display an action twice. All current views work on the assumption that an action is only shown once
2. Tracks is not a planning tool: the more complex relationships you allow, the more people expect Tracks to help plan a project. This is not what we want with Tracks.
3. I believe that in most (if not all) cases you can suffice with a 1-n relationship. This would mean changing Tracks minimally for dependencies. Less added complexity is always better imho
4. the gui would just get very complicated
HB:
1. Can you give me an example?
2. Ok, I trust your experience here.
3. I agree with less complexity. However, I think it is pretty common that an action can have multiple (independent) dependencies. Such as described in the example below, or let’s say “Buy bread”, “Buy butter”, which are independent actions doable in parallel, and “Make sandwich” which are dependent on both earlier actions.
4. Do you mean for the user or the developers? I think the most common use case would be to add a couple of actions to a project, in pretty much the order intended for execution, thus being able to add dependencies to existing actions. Without changing the GUI much (let’s say that we in the first step, skip any expandable sections, links to dependencies etc.), I still think most users would benefit from just using the dependency information when filtering out active next actions. The actual dependencies information would still be accessible and editable in the edit view.
RB:
1. I was thinking about a view with a plus to expand all dependent actions. If you have 1-n, the 1 will just expand the n actions. No problems here. If you have n-m, you can have action A which is dependent on actions B and C. On the home page, B and C will have a plus which will both show A when expanded.
2. Just trying to keep the scope (and be able to handle maintenance)
3. probably true, but let’s start simple. We can always enhance when the simple case works well
4. both, but again from the plus-point-of-view
- Is it common to have dependencies between projects?
RB: yes, but I think we should leave that out of scope. You can always realize this in a tree with a 1-n relation between one action from project A and all actions from project B.
- Naming
RB: I dislike the terms predecessor and successor. I find it very confusing looking at the action form in the mockup screen shot. Could we use “depends on”?
I also think we need to start this very simple, so a 1-n relation between predecessor and successor. Or an action depends on one other actions. That actions has zero or more actions that depend on it.
HB: I like “depends on” better in the GUI, but I think pred./succ. is sometimes more precise when discussing technical solutions.
RB: Ok, that sounds good
It is partly related to (at least) the following tickets:
#105
#300 (most activity in this one)
#721 (duplicate)
#475
#185
#360
Note: #903 tracks a GUI mockup suggestion.
Code at git://github.com/bohrax/tracks.git