Discussion: New plugin view - "Next Actions"

[Brendan T]

Hi guys,

From the Kanban window there is a nice option to hide the parent tasks.  I like this as I get the lowest level subtasks which are the items that need to be done to closer the higher level objectives.

Next actions.  This would only give the highest position subtask for any branch and the one that needs to be completed to enable progression to it's siblings.  In TDL the position is easily changed Ctrl+Up/down so it seems a fast and easy way to create an informal dependency without making links or entering task dependencies field.  So, would just need a view to give the *.*.*.1 positions for example.  This would ultimately tell you what are the tasks that are limiting progress on any given branch.


Brendan

[Keith Collyer]

Ooh, I like this idea. This would help support Getting Things Done. Even better if "Next Action" were to be (optionally) dependent on some other field (Category, Tag?) used as a GtD Context. Effectively, filter first (on whatever is being used as context?), then choose which action to display as Next Action. Thinking about it, this could also apply to the List view (probably not Tree).

[Brendan T]

Hi Keith,

yes, you are correct for GTD next actions and how it could be filtered for context etc.
I came across another post on reddit which I think could be addressed by such a method.  In reddit, the poster requests reminders for a task when it's predecessors have been completed.

https://www.reddit.com/r/productivity/comments/4me01w/are_they_any_good_appswebapps_out_there_for_todo/

[.dan.g.]

TDL currently doesn't support filtering by position, but I've looked at the code and it's a 5 minute job (via Find Tasks dialog).

I'll add it to the next update of 7.1 so that you can play with it and tell me whether it goes far enough.

[.dan.g.]

Hi Brendan

7.1.A3 includes the option to search/filter by position.

On Saturday, 28 May 2016 17:51:26 UTC+10, Brendan T wrote:

[Brendan T]

Thanks Dan, will have a look!
Looks like the features are coming thick and fast these days.

Brendan

[John Smith]

Hello

I am new here and am trying to apply the GTD method. 

I have been desperate to get a view showing just the Next [n] Tasks per project.

I have downloaded ToDoList "7.1.B1(Beta)" and have managed to save a search/filter for the next [n] tasks in each project - brilliant!

For example I can now create a view which shows just the  tasks for each project to show up.

My feeling is that the ability to have great than and less than etc logic is more complex that it needs to be, as all I think that most of us need is to be able to set the number of Next Tasks per project as an integer (between 1 and say 9).

What does "is set" and "is not set" mean?

Either way, given that (for some reason) the user can not change the filtering of a saved view, it would be nice to have the number of Next Tasks per project visible on the Filters bar - ideally listed as a simple drop down list ==> i.e. showing how many Next Actions you want. (There would be no real benefit of including "greater than" etc functionality.)  

Many thanks

J

[simplenuity]

Hi John,

May I please ask to share how you have set up the filter for the next [n] tasks?

Thanks,
Ryan

[John Smith]

Hi Ryan

Sure. You'll need the Beta version (I am running "7.1.B1 (Beta)" )

For example to just show the first 3 tasks per project: 

Control+F  ==> New search ==> "For tasks matching the following rules"

Column1 ==> Position

Column2 ==> "is less than (<)"

Column3 ==> 3

then "Apply as filter",  Save the new name (etc). 

What is clever is that in order to decide what is "a project" in a hierarchical tree, it goes to the youngest child tasks and find's it's parent - and that is "a Project"

There is arguably a slight bug because if we define "Less than or equal to" say 2, it will in fact show 3 child tasks not 2.  And "Less than" 2 shows 2 tasks not 1, like in theory it should. 

Like I say, personally I would love to see a simplified version of Position (i.e. in effect restricted to just "Position equals...")  on the Filters tab, so that we can add & remove other filters to this at will.

Either that or re-activate the filters tab even when a Saved search filter is active.

J  

[John Smith]

Oh dear....

On closer inspection, there are unintended consequences of using Position.

The bad news is that, because the user has no formal way of defining which tasks are "Projects" and which are not Projects (let alone defining which Projects are "in series" and which are "in parallel"), quite a lot of stuff that you may wish to show is filtered out.

e.g. On my setup I need 4 Areas of Responsibility (AoR). I am storing AoR for each task in the Category field. In order to get my new (child) tasks to default to having the correct AoR, I have set up 4 (parent) tasks in the root level, which I am using as in effect like folders, in that they are not 'executable' and so they never get deleted. These 'folder' tasks also contain the appropriate Category so that any new child task will take on the correct AoR.  [Hard to explain in words but not that complex in reality!]

Anyhow, this means that due to these 'folder' tasks, all my tasks already has a parent. In effect this means that all my tasks are part of what you might call projects. And this means that if I set my filter to "Position is less than 2", then TDL will only show 2 tasks within each my Folders tasks - i.e. just 2 tasks withing each of my Areas of Responsibility. Not good!

[Note: The exception to the above is that if you are in Task Tree view, then any task which itself has at least one child task will also be visible. (In fact giving something a child task, is rather a good way of forcing a task that is not in the top 2 task to appear. This is a bit messy but is a way to get "Forced Next" to work - in Tree view at least)]

All this is a huge problem for me. Over the last couple of days I had been getting increasingly optimistic that finally, after many months of asking around & searching I had finally found a task manager that allows me to implement the GTD method properly. 

I now think that this issue is pretty much a deal-breaker for me.

You see, the lesson that I have learned the hard way on powerful but at core incorrectly structured software like MLO, is that, in the end all workarounds tend to have terrible unintended consequences. The thing is that I tend to have about 400 to 500 tasks in my system and with such a large number of task (and even though many are in the "Someday" status)  things need to be designed for purpose, or clutter and confusion breaks out all around!

...and to be honest it is quicker and more efficient to just use pen & paper. 

But trying to stay constructive... in this case I think the only way forward is to have a field in the database that defines a parent task as actually being "a Project" (i.e. something from which we only want to see a limited number of children at once.).

From first principles if a task is a parent (i.e. it has 1 or more 'child' tasks) then we need a way to define the task as:

- a Folder

- a Series Project (default for any parent)

- a Parallel Project 

Also, if the task has a Series Project as a parent, then there needs to be some way to of "forcing" the task onto the Next [n] Actions per project view. 

Overall not good news I'm afraid, but trying to help.

 

1.

2.

3.

3.1

3.2.

3.3

3.4

3.5

[simplenuity]

Thanks, John, for sharing all this!

I still haven't played around with the filter yet. I just wonder how that will affect the List View as in there parent folders (= projects) can be hidden, while a single task on basically the same level still shows up? The List View used to be my real next action list in my GTD setup. To cut down the tasks I saw I used a Tag for today and the Priority field (I only used one differentiation: normal=default (5)l, important (10)). I rather would leave the importance to the intuition of the moment if I could shrink the list in a much smarter way, for example with your approach.

Best,
Ryan

[Smith, John]

OK now I understand what's going on. 

What was causing confusion was the showing of the tree in Task Tree view.

Things are much simpler in List view

Postion is a numbering system that starts with the integer 1 and increments. If there is a child relationship a "." is inserted.

For example "5.6.3" is the 5th task's 6th child's 3rd child.

OK, suppose we have a structure like this, and are filtering on "Position is less than 3", then only the tasks I have highlighted in bold green are visible in List View

1

2

3

4

5

   5.1

   5.2

   5.3

   5.4

   5.5

   5.6

      5.6.1

      5.6.2

      5.6.3

      5.6.4

      5.6.5

6

   6.1

   6.2

   6.3

   6.4

   6.5

7

8

9

 

i.e. All the filter is doing is taking the last number (the bit to the right of the last "." if there is one)  and only showing those tasks that match the filter condition. 

To get clear in Task Tree view the tasks listed below (5 , 5.6, 6) are also visible but they are only there in order to show the "tree" for the benefit of the task on the next line. 

1

2

3

4

5    (tree)

   5.1

   5.2

   5.3

   5.4

   5.5

   5.6   (tree)

      5.6.1

      5.6.2

      5.6.3

      5.6.4

      5.6.5

6  (tree)

   6.1

   6.2

   6.3

   6.4

   6.5

7

8

9

...And the task that remain black disappear from view.

It is in fact quite irritating that task "4, 7, 8 & 9 " have all now disappeared from both views, as would 5 and 6 if they had no children.

Back to first (GTD) principles, if we argue that only tasks that have a child can be considered to be "a project", surely we want those "stand alone" tasks (i.e. tasks with no children and no parents) to be included in this view.

i.e. In programmatic terms, any position without a "." in it should also be shown.

However although this simple tweak to the algorithm would allow standalone tasks to be viewed at the same time as "Next [n] Actions in each Project", I still have the problem that when I am working in a given Category (i.e. Area of Life) I want all new tasks to default to get that Category.

I can't emphasize enough how important these subtleties of user interface are. Having to manually enter things like Category for each task is very close to being a deal breaker for me.

I mean in a paper based system, one would just find the right bit of paper and write the task on it, and stuff like Area of Life and even Context-tag are both implied.

When working fast with lots of tasks coming in an out of the system, these subtleties are absolutely crucial to the usability of the entire system.

So we need to find some way to get certain fields particularly Context and Tag to default in accordance with the user's current mode.

I suggest that rather than inherit attributes from a task's parent, that we should be given the opportunity to inherit the properties of the lot immediately above them in the current view.

To be honest, as things stand TDL is not really usable for me.

J

--
Download Latest Version: http://abstractspoon.pbworks.com/f/todolist_exe.zip
Wiki and other resources: https://github.com/abstractspoon/ToDoList_Wiki/wiki
---
You received this message because you are subscribed to a topic in the Google Groups "ToDoList (AbstractSpoon) Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/abstractspoon-todolist-support/zMWPPpXi9H0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to abstractspoon-todolist-support+unsubscribe@googlegroups.com.
To post to this group, send email to abstractspoon-todolist-sup...@googlegroups.com.
Visit this group at https://groups.google.com/group/abstractspoon-todolist-support.
To view this discussion on the web, visit https://groups.google.com/d/msgid/abstractspoon-todolist-support/1f16f366-18df-4297-ae8a-2297042a3210%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[simplenuity]

AHHH!

I couldn't resist having a go ... :)
Was actually quite satisfied with the List View - except that I also stumbled over the behavior that - to stay in your example - tasks "4, 7, 8 & 9 " disappeared.
Even if I'm tempted to consider this a bug, Dan might have another reason I'm not aware of why they should not show up?

New tasks Inheriting certain features is a completely different story. Good you've opened another thread for this. I would suggest, not to discuss it further here but over there.

[simplenuity]

Hi Dan,

Am not sure whether you've followed this discussion in detail here.

Have you seen my question whether we are dealing with a bug in the case of applying a filter with "Position" defined and having tasks not being shown that should(?) be?

Would be great to get some clarity on this.
Thanks,
Ryan

[.dan.g.]

Hi Ryan

Can you give me a specific set of steps to reproduce the issue on a tasklist you can share here pls?

[Ryan]

Hi Dan,

Please find the tasklist test.xml attached which is reflecting exactly John's example (https://groups.google.com/d/msg/abstractspoon-todolist-support/zMWPPpXi9H0/NPW_hyU2BAAJ).

My setup:

• OS: Linux/Wine
• TDL version: 7.1.B
• starting from scratch, creating tasklist as attached, creating and applying filter (position is less than 3)

See also screenshots attached.

Questions/issues, as John pointed out:

• Filter is actually reflecting "equal or less than 3", although chosen only: "less than 3"
• Tasks 4, 7, 8 & 9 have disappeared with the filter active.

I have also attached an extended tasklist test2.xml with more tasks on the second level.

The behavior described by John (certain tasks disappearing that would be "good" to be seen) obviously applies also to lower levels.

It's a tricky situation the more I think about it. Beside the Because the current behavior does makes sense in its own rights.

We might need to discuss use cases and how certain behaviors of this feature would be beneficial? Maybe it needs to depend also on the sorting of the tasks? Really don't know at the moment...

In the given case it definitely would be necessary to see Tasks 4, 7, 8 & 9 in tasklist test.xml.

Similar in tasklist test2.xml where in addition to first level tasks 4, 7, 8 & 9 also subtasks 5.4, 5.5, 5.7. 5.8. & 5.9 needed to show up.

Hope that helps for a start...

Ryan

To unsubscribe from this group and all its topics, send an email to abstractspoon-todolist-support+unsub...@googlegroups.com.
To post to this group, send email to abstractspoon-todolist-support@googlegroups.com.

Visit this group at https://groups.google.com/group/abstractspoon-todolist-support.
To view this discussion on the web, visit https://groups.google.com/d/msgid/abstractspoon-todolist-support/1f16f366-18df-4297-ae8a-2297042a3210%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Download Latest Version: http://abstractspoon.pbworks.com/f/todolist_exe.zip
Wiki and other resources: https://github.com/abstractspoon/ToDoList_Wiki/wiki
---
You received this message because you are subscribed to a topic in the Google Groups "ToDoList (AbstractSpoon) Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/abstractspoon-todolist-support/zMWPPpXi9H0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to abstractspoon-todolist-support+unsubscribe@googlegroups.com.
To post to this group, send email to abstractspoon-todolist-sup...@googlegroups.com.
Visit this group at https://groups.google.com/group/abstractspoon-todolist-support.

To view this discussion on the web, visit https://groups.google.com/d/msgid/abstractspoon-todolist-support/3ee81fd3-d850-4ced-8b6c-d6ee6a088b81%40googlegroups.com.

[.dan.g.]

Many thx Ryan.

>> Filter is actually reflecting "equal or less than 3", although chosen only: "less than 3"

This is simply because TDL is using zero-based indices internally, and is easy for me to fix.

>> Tasks 4, 7, 8 & 9 have disappeared with the filter active.

This can be handled by including 'or Parent Task ID equals 0' meaning that the task has no parent.

>> The behavior described by John (certain tasks disappearing that would be "good" to be seen) obviously applies also to lower levels.

Not quite sure what you mean by this.

On Wednesday, 7 September 2016 11:32:55 UTC+10, simplenuity wrote:

[Ryan]

Hi Dan,

Thanks for looking into it! Highly appreciated.

I usually use TDL on a very basic level, so am always blown away to get a glimpse now and then of the extremely well thought through, powerful and flexible software you have created! :)

Thanks for pointing out the Position variable for adjusting the filter. It works - of course - as described.

The following picture hopefully will show what I mean.

These are the filters used:

And this is the result:

To be honest, I still can't get my head around it how the tasks "should be" filtered/shown!

Of course the filters do work as intended. What I meant with my last sentence is the difference between level 1 tasks and level 2 (and lower) tasks when the filter including the position = 0 gets applied. The green marked tasks (level 1) get shown as "we" thought it "should" happen. But it made me think... what about level 2 (and below)? In terms of the workflow, i.e. reducing the tasks to be shown, would it be also desirable to actually see the red marked tasks? Purely looking at level 2 they are basically comparable to the red marked level 1 tasks.

I really don't know! And also, where does it end? Should all the levels be treated like the level 1 tasks EXCEPT the last one?

I'm not expecting answers to all these questions! :)

They are only symbolizing my spinning head :)

It is obvious, the desire to reduce the visible tasks in a smart - and useful! - way is not that easily done, maybe even can't be done by one static filter as soon as we include subtasks. The sorting of the tasks will also play a vital part in applying any filter while expecting useful results. And then we also have dependencies and time factors.... and most probably other attributes/factors I didn't think of right now.

Maybe John has some ideas/ experience how this can be done?

I'm a bit lost at the moment....

Ryan

--
Download Latest Version: http://abstractspoon.pbworks.com/f/todolist_exe.zip
Wiki and other resources: https://github.com/abstractspoon/ToDoList_Wiki/wiki
---
You received this message because you are subscribed to a topic in the Google Groups "ToDoList (AbstractSpoon) Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/abstractspoon-todolist-support/zMWPPpXi9H0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to abstractspoon-todolist-support+unsub...@googlegroups.com.
To post to this group, send email to abstractspoon-todolist-support@googlegroups.com.
Visit this group at https://groups.google.com/group/abstractspoon-todolist-support.

To view this discussion on the web, visit https://groups.google.com/d/msgid/abstractspoon-todolist-support/a2db650c-f23e-4472-a8c6-52f460b3a979%40googlegroups.com.

[John Smith]

Hi Dan & Simplenuity 

I find myself smiling at the shear difficulty of the problem.

Intuitively Simplenuity and I both know that there has to be a better way of handling larger more complex projects, so that we only see a manageable, filtered selection of them... but what?

First-up, simplest thing to do would be not to filter out any tasks that have no children. That would instantly make the whole view much more useful. Hopefully we all agree about that.

For a deeper solution I think yes it would be useful to see those red tasks (e.g. "5.4"), but not to show "5.6.4". But how can one achieve this?

 
My suggestions are: 

(A) "Only trim the longest branch of the tree"

The algorithm for this would be: Take each task in the root level (i.e level 1) and go down the tree/hierarchy of children of for each task and work out what is the maximum number of levels it has. (i.e. what is the longer branch of the tree).  Then apply the First [n] Tasks... only to tasks that are at that level. 

In the above example, the tree below "5" would have 3 levels. So "5.6.4" and it's younger siblings would get filtered out. But your red tasks would be visible.

It may be a slightly nasty algorithm but it makes sense to me at least.  :^)


(B) "Filter all trees at a globally specified level"
i.e. We could have a global variable located somewhere in Settings where the user can set field whose value determines at what level the Next [n] Tasks filter starts to work. 

I find it very unlikely that this number would ever be useful to start at level 1, as this would give us the results simplenuity is getting from "Filter 0)" - which clearly filters too much! 
Much more useful would be to start at level 2 - and I suggest that should be the default. However different users may have very diverse setups and equally diverse needs, so I suggest that Level 3 or above should be possible levels at which point the filtering should start. 

Some users (I would be one) would like the Next [n] Tasks to only kick in at Level 3, but others may have different requirements. 

(C) "Use a Project field"

I slightly shudder at the complexity of this suggestion... but for completeness here goes: 
So what some other applications (e.g. MLO) do is allow the user to explicitly define what is and is not a "Project". This allows the user to have task hierarchies that are not filtered to show Next [n] Tasks, and have other task hierarchies which include "Projects", where thee Next [n] Tasks filter kicks in.

"Sub-projects" 
The way MLO works is that where there is a project defined somewhere within a project, that the next [n] tasks are always forced into view for each such sub-project.  Fwiw, in MLO the [n] is always "1" which I feel is extremely limiting. 

It may well be that (B) is the easiest to code and the easiest for other users to understand, but personally I would absolutely love any of the above!

Trying to help

J

[.dan.g.]

Thx for both your comments. I'll look at this issue further for 7.2.

[Tony G]

Without having read through every detail tail (though I usually do) it seems the challenge is solved using tags. Manually tag tasks that you want to view in a specific filter. Use something like F1 to F9 for Filter1-9. I personally don't shuffle the order of tasks That much where this would be a huge concern. If I shuffle tasks I know that I need to tweak subtasks occasionally to achieve specific results. And as I've suggested elsewhere, you can re-tag all tasks to your liking using a UDT, though I understand a lot of people don't have the skills for that.

HTH
T

[simplenuity]

Hi Tony,
Thanks for your input.
There is no doubt that "the challenge" could be solved by utilizing tags and categories. The keyword here you mentioned yourself: manually.
We have been looking for a (more or less) automatic solution though, mainly based on the position of tasks in the tree.
Hope that clarifies it better :)
Ryan

[John Smith]

Simplenuity ++

On Friday, September 16, 2016 at 12:40:52 AM UTC+1, simplenuity wrote:

Hi Tony,
Thanks for your input.
There is no doubt that "the challenge" could be solved by utilizing tags and categories. The keyword here you mentioned yourself: manually.

We have been looking for a (more or less) automatic solution though, mainly base on the position of tasks in the tree.

[Gnopps]

I've been playing around with this function to use it as Next action for GTD-purposes. However I can't get the search to ignore completed tasks. I.e.

1
1.1 - Completed
1.2 - Completed
1.3 - Not completed

I would like a search for position 1 to show 1.3 only. Can that be accomplished?

[.dan.g.]

Not at present, that's one of the recognised problems.

I'll have another think about how best to resolve this.