Suggestion: glitch in Kanban view

[G-Eric]

** REPOST from here and here as requested here **


Hi Dan,

I report a visual glitch in Kanban view.

I don't attach the file 'Documentation.tdl' to evidence the issue as it relates to display and not record handling (aka 'engineering').
It is pure display misleading, where records handling is correct;

Let's assume that:
- tab view = Kanban
- in view, have the 'Completion checkbox' displayed next to task (I can't find out where to active this - sorry)
- top filter 'Show' = B) Incomplete tasks
- top filter 'Options' = unselect 'Show all subtasks'  (i.e. checkbox not ticked)
- program preferences : User Interface > General > Filtering > Automatically re-filter after editing = selected (i.e. checkbox ticked)

Action1 : check the 'completion box' of a task (preferably a subtask for better visibility, but not required)
Result1 : the task is marked as completed and disappear from the view (automatic refresh)
Side effect : you see at the bottom right corner that the currently selected task is 'x' (task id) but the related task is not colored as the selected task is expected to be
Action2 : go to view 'Task Tree' (no other action - just note that the task selected is visually marked by selection color) and then go back to view 'Kanban' (no other action)
Result2 : the task selected is now visually marked by selection color, as expected

IMHO, the Kanban view is missing a step at the end of the refresh process to color the selected task, what is misleading because any keyboard action will happen on a task that you don't see which one it is.
I hope you can understand my report, and stay available if you need more details.

Thanks for your attention - Have a nice day - Eric

Hi Dan,

Here it is!

1. TDL_Kanban-1.png = initial situation, showed in 'Task Tree' view to present the structure and the task ID's.
   
   [ not visible : I click now on low tab 'Task Tree' to switch the view from 'Task Tree' to 'Kanban' - no other action performed by me ]
   
   
2. TDL_Kanban-2.png = initial situation, showed in 'Kanban' view to verify that selected (32) evidencing task is colored (= selected).
   Btw, note that task 35 'MyRecords' is on top of display.
   
   [ not visible : I click now on the completion checkbox of task 32 to mark it as 'completed' - no other action performed by me ; however, the automatic filter reacts and hides the task 32 has it is now completed ]
   
   
3. TDL_Kanban-3.png = situation after click, showed in 'Kanban' view evidencing (bottom right footer) that task 28 is now selected but this task is not colored.
   Btw, note that task 35 is not more at the top of display = the entire column list has "jumped" vertically.
   
   [ not visible : I click on low tab 'Task Tree' to switch the view from 'Kanban' to 'Task Tree' - no other action performed by me ]
   
   
4. TDL_Kanban-4.png = situation after click, showed in 'Task Tree' view evidencing (bottom right footer) that task 28 is now selected and this task is colored.
   
   [ not visible : I click now on low tab 'Task Tree' to switch the view from 'Task Tree' to 'Kanban' - no other action performed by me ]
   
   
5. TDL_Kanban-5.png = situation after click, showed in 'Kanban' view evidencing (bottom right footer) that task 28 is now selected but this task is now well colored.
   Btw, note the name of the view has not been updated / refresh (bottom right corner)
   
   I suspect that re-entering the 'Kanban' view did refresh something to color the task selected and that was not refreshed after the automatic filter action.
   
   
6. TDL_Kanban-6.png = situation I would have visually expected after my action between points 2 & 3, i.e. complete task 32.
   The task 28 is colored and the task 35 did not "jumped" (no need as selected task is visible).
   

Thanks for your thoughts on this - Eric

** Additional note > related files 'Introduction.tdl' and 'ToDoList.ini' sent by email to your attention as requested here  **

[.dan.g.]

Thx Eric, that's awesome!

[.dan.g.]

Fixed in 7.2.7

On Wednesday, 20 February 2019 08:01:53 UTC+11, G-Eric wrote:

[G-Eric]

Thanks Dan.

It works fine in 'Introduction.tdl', even with mutli levels of tasks.
However, I have some other behavior in my own databases (display jumping + again no visibility of selected task) - I can't reproduce so far = testing further, I will revert if I can point something.

[.dan.g.]

When you have more information can you update this thread rather than the latest release thread please :)

On Monday, 25 February 2019 08:34:55 UTC+11, G-Eric wrote:

See comment here.

[G-Eric]

Hi Dan,

I think I finally understood the reason of the unexpected behavior I spoke about.

Situation: a root record 'z_AB' with childs, where one of the childs 'A3' has another category (i.e. 'Travel' instead of 'Groceries')
Go to view 'Kanban' and have records displayed by categories >>  Attribute to track = Category.

First, you will notice that the child A3 is in the right column 'Travel', but without parent despite the setting activated.
Second, when you mark the child 'A3' as completed by checking the completion box, the next task selected is not highlighted (although the next task id is well displayed at bottom right corner).

I suspect that this particular situation of having mixed Kanban tracking keys (i.e. 'Category in the example) in the same record "family" (i.e. parent + childs) is causing a rupture in the display handling.
You will find attached both 'Introduction.tdl' and 'ToDoList.ini' to document the post.

Thanks - Eric

[.dan.g.]

>> First, you will notice that the child A3 is in the right column 'Travel', but without parent despite the setting activated.

This is a misunderstanding/confusion about the wording of the preference 'Sort subtasks below their parent' because this only applies when the parent and the subtask share the same value.

I decided it this way because if the parent appeared in any column that contained its children, you wouldn't be able to tell whether a parent was in that column because it had the value of that column or because some of its subtasks had that value.

And I decided that this was more important that anything else.

Consider the alternative where the parent appears in two columns but only shares the value of one of the columns, as per your attached tasklist but slightly simplified:

___________________________________

|                |                |

|    Groceries   |     Travel     |

|________________|________________|

|                |                |

|  zAB           |  zAB           |

|    |_A0        |    |_A3        |

|    |_A1        |                |

|    |_A2        |                |

|    |_A4        |                |

|________________|________________|

Q: What would happen when you tried to move 'zAB' from column 'Travel' to another column? 

A: Either I would have to prevent it (causing user confusion because it looks identical to the 'zAB' in 'Groceries'), 

    Or I would have to also have to move 'A3' (also causing user confusion because this is different from moving 'zAB' from 'Groceries)

Additionally, and for consistency, I would need to display the full depth of the parent hierarchy, which would quickly become unwieldy IMO.

However I do understand your request both because the existing preference text implies this, and because having the parent there gives important context.

My preferred solution would be to somehow include the parent information in the subtask, in a way that doesn't compromise the behaviour and provides necessary context.

Imagine a kind of combined parent and subtask:

Dan

[G-Eric]

Your explanation is crystal clear - many thanks for the detailed feedback.
It leads me to share your view on how to consider things have to be displayed to keep consistency (visual, structural and technical).

Parent-Children display
I think your choices were indeed the only good ones to avoid other either unexpected side effects creating confusion and even probably wrong user actions.
The visual solution you shared (adding a visual reminder inside a task of its path inside the parent-children tree) is a surprising enhancement that will help for sure.

Marking as 'completed'
Next to that, did you had the opportunity to consider the second point I reported?  [1]
If so, was it also reproducible on your side? If not, I will search further on my side what makes the trigger.

[1]  When you mark the child 'A3' as completed by checking the completion box, the next task selected is not highlighted (although the next task id is well displayed at bottom right corner).

Thanks for your permanent open minded listening to the community.
Eric

[.dan.g.]

>> Next to that, did you had the opportunity to consider the second point I reported?

Yes, I did and I have a fix for it.

ps. Thx for making the effort you do, it helps balance the people who just want to take...

[.dan.g.]

Glitch fixed in 7.2.8.

Including parent context in subtasks requires a substantial change => 7.3.

On Wednesday, 20 February 2019 08:01:53 UTC+11, G-Eric wrote:

[G-Eric]

>>  Glitch fixed in 7.2.8.

It works fine - thanks for the fix.

One question
Assume you mark a task as completed as described in the above scenario (e.g. the usual A3) - as a consequence, the selection goes to another task (e.g. A4).
When I undo this last change (using keyboard shortcut <CTRL-Z>), the task is restored at the expected place with initial attributes = ok, fine.
However, the selection remains on the task last A4.

My initial reaction / expectation was to see the selection also revert to the task just restored (i.e. to restore the entire situation as it was before the action).
Is this intentional by design to respect other underlying elements and/or cases I overlooked?

[G-Eric]

>> Including parent context in subtasks requires a substantial change => 7.3.

Good news if this is possible, as it will help to ensure appropriate decode of the visible Kanban records.

However, it is not blocking - the explanation you provided here helps (me) to have an adjusted view on how to use it on an better way.
So, if the change is either postponed or put on hold for any reason at your discretion, no worries.

[.dan.g.]

Normally an undo would restore the selection but in this case a re-filter also occurs and the selection is not preserved.

I have a solution for it but it was more involved than I thought so I may delay it until 7.3 to reduce the risk of breaking 7.2.

[G-Eric]

Thanks for the decode of the situation, Dan.

I did not catch the reason was related to the mix of constraints (restore & re-filter).
Now I understand why it happens like this, I can adjust my settings as workaround.

I follow your prudential approach for a stable solution coming later rather than a potentially risky 'quick fix'.

[.dan.g.]

Hi Eric

>> it will help to ensure appropriate decode of the visible Kanban records.

I've implemented the structural changes to facilitate this enhancement but I still need some help to figure out the precise behaviour.

My initial thought is to only display the parents inside the child tasks IF BOTH the 'indent' and 'sort below parent' preferences are set but I wanted to run it by you first.

With these two preferences there are the following combinations:

‘Indent’ Preference	‘Sort below Parent’ Preference	Behaviour
Not set	Not set	Display no parents or all parents(??)
Set	Not set	Display all parents because subtasks are completely disconnected from their parents
Not set	Set	Display whichever parents are 'missing' from the column the subtask is in because the parents that are not missing will provide their own context
Set	Set	Display whichever parents are 'missing' from the column the subtask is in because the parents that are not missing will provide their own context.

Or perhaps there needs to be another preference...

[.dan.g.]

Or better still, I'll just go ahead and add all parents to all subtasks and then we'll at least have something more concrete to discuss - leave it with me :)