Question: Indented sub-tasks #1761

Closed
opened 2020-12-31 18:53:17 +00:00 by azymondrian · 22 comments

I really like the flexibility of task relations, but I find myself wanting sub-tasks to be grouped and indented with the parent task.

My general use case of creating a task with subtasks usually ends up looking like the attached screenshot, which feels a bit awkward to me.

I understand this can be complicated a lot since relations can be cross list and namespace, which is why I haven't attempted to implement this yet, but I'm hoping we can find an elegant solution.

I really like the flexibility of task relations, but I find myself wanting sub-tasks to be grouped and indented with the parent task. My general use case of creating a task with subtasks usually ends up looking like the attached screenshot, which feels a bit awkward to me. ![](https://kolaente.dev/attachments/117fb894-cd42-44bb-975d-e57bc65d5aec) I understand this can be complicated a lot since relations can be cross list and namespace, which is why I haven't attempted to implement this yet, but I'm hoping we can find an elegant solution.
Owner

You mean you want to see all sub tasks a task has in the list view?

You mean you want to see all sub tasks a task has in the list view?
konrad added the
kind/feature
label 2020-12-31 18:59:14 +00:00
Author

This is a very rough mockup of how I typically picture a task with subtasks. I don't know how this would work with sub-tasks or a parent-task in a different list/namespace though.

This is a very rough mockup of how I typically picture a task with subtasks. I don't know how this would work with sub-tasks or a parent-task in a different list/namespace though. ![](https://kolaente.dev/attachments/57768601-8fe9-4dec-a2b9-a82089a3c2b8)

This feature would be super useful - I would imagine it working like this: when the subtask is in the same list, it would show up indented below the parent task (like in Todoist). If it's from a different list, it would show up with a link as it does today.

And it would tie in perfectly with drag-and-drop (what I really miss in Vikunja) - you could drop any task below a different task, and it would become a subtask.

This feature would be super useful - I would imagine it working like this: when the subtask is in the same list, it would show up indented below the parent task (like in Todoist). If it's from a different list, it would show up with a link as it does today. And it would tie in perfectly with drag-and-drop (what I really miss in Vikunja) - you could drop any task below a different task, and it would become a subtask.
Owner

The hard part about this is a) how should this work with pagination? Should it still only show 50 tasks with some regrouped or 50 in total with some being reorganized to appear under their parent task? What should happen if a sub task would show up on a different page than its parent task?
Custom sorting per drag and drop would add extra complexity to the problem.

The hard part about this is a) how should this work with pagination? Should it still only show 50 tasks with some regrouped or 50 in total with some being reorganized to appear under their parent task? What should happen if a sub task would show up on a different page than its parent task? Custom sorting per drag and drop would add extra complexity to the problem.
Author

Yeah pagination definitely makes it more difficult. I personally would prefer the second option:

50 in total with some being reorganized to appear under their parent task

But that is in part because the curent ordering doesn't matter as much to me.

I agree that drag-and-drop would make this super convenient, but it definitely adds complexity

Yeah pagination definitely makes it more difficult. I personally would prefer the second option: > 50 in total with some being reorganized to appear under their parent task But that is in part because the curent ordering doesn't matter as much to me. I agree that drag-and-drop would make this super convenient, but it definitely adds complexity

What if subtasks bypassed the limit of tasks per page and didn't count towards the total? That way you won't have subtasks split across multiple pages. If the concern is that too many subtasks will show at once, maybe we can cap their initial count at some value and add a "show more" button that will load more subtasks?

Drag and drop will definitely be harder, but I think it's a must have feature. I like dragging tasks around instead of them being sorted by some arbitrary value. Since the drag and drop feature already exists in Kanban, I think that a similar method could be adapted for list view.

What if subtasks bypassed the limit of tasks per page and didn't count towards the total? That way you won't have subtasks split across multiple pages. If the concern is that too many subtasks will show at once, maybe we can cap their initial count at some value and add a "show more" button that will load more subtasks? Drag and drop will definitely be harder, but I think it's a must have feature. I like dragging tasks around instead of them being sorted by some arbitrary value. Since the drag and drop feature already exists in Kanban, I think that a similar method could be adapted for list view.
Owner

maybe we can cap their initial count at some value and add a "show more" button that will load more subtasks?

I think that would make it even more complicated than it is already - I'd rather not implement that in a first version. If people complain, sure, but I doubt anyone has tasks with more than 20 subtasks or so.

> maybe we can cap their initial count at some value and add a "show more" button that will load more subtasks? I think that would make it even more complicated than it is already - I'd rather not implement that in a first version. If people complain, sure, but I doubt anyone has tasks with more than 20 subtasks or so.
Owner

For drag n drop please see the discussion in vikunja/frontend#115

For drag n drop please see the discussion in https://kolaente.dev/vikunja/frontend/issues/115

I personally think subtasks should either be loaded underneath their master task, or at least allow for a view in the list where labels can be grouped together. This way if you want to say make a grocery list, you can specify the store you have to go to as the master, and all the items below it; then another store as a master and the other items below that.

For the second option, if you want, I can make a new issue for that since it is inherently different than the first.

I personally think subtasks should either be loaded underneath their master task, or at least allow for a view in the list where labels can be grouped together. This way if you want to say make a grocery list, you can specify the store you have to go to as the master, and all the items below it; then another store as a master and the other items below that. For the second option, if you want, I can make a new issue for that since it is inherently different than the first.

Upvoting this because I'm sure it is a crucial visual feature for current users and many to come!

Upvoting this because I'm sure it is a crucial visual feature for current users and many to come!

Having tasks which are related by "subtasks" being indented under the main tasks on List view is a must for the people that I work with.
This is something which would bring more visual clarity to the table
I'll give some visual examples of how this could work from old screenshots I had of Todoist

List View

The list view seems to be the one where you @konrad have the most fear of being poorly implemented. I get it, but maybe you could set a default maximum expanded view for subtasks (I think its rare to have a LOT of subtasks).
For example:
image
Also, their collapsable.

Kanban View

For this type of view, the problem is much easily tackled in Todoist. Instead of having a visual indenting tasks, any Tasks with subtasks will have that Icon (with the 2 connected circles) showing the number of completed/total number of tasks:

image

And to see the subtasks of that tasks we click on it:

image

Having tasks which are related by "*subtasks*" being indented under the main tasks on List view is a must for the people that I work with. This is something which would bring more visual clarity to the table I'll give some visual examples of how this could work from old screenshots I had of Todoist ## List View The list view seems to be the one where you @konrad have the most fear of being poorly implemented. I get it, but maybe you could set a default maximum expanded view for subtasks (I think its rare to have a LOT of subtasks). For example: ![image](/attachments/53ab83fe-6812-4b7a-82a9-b8df45254cec) Also, their collapsable. ## Kanban View For this type of view, the problem is much easily tackled in Todoist. Instead of having a visual indenting tasks, *any* Tasks with subtasks will have that Icon (with the 2 connected circles) showing the number of completed/total number of tasks: ![image](/attachments/fa10161e-10aa-4a61-bc27-454a8d6c6105) And to see the subtasks of that tasks we click on it: ![image](/attachments/ef47146e-523f-458f-92cb-6c92a35f5703)
Owner

@bolgrov Thanks for the screenshot, I think that makes it a bit more clear.

The little indicator about how many subtasks are done is already implemented for checklists:

image

image

What would you say is a use-case where you absolutely need a fully-fledged subtask and a checklist won't be enough?

I think something like you showed in the screenshots would absolutely be doable, but I'm a bit hesitant about the performance. But that's something to check and see how bad it really is.

The other thing I'm not sure about is the way other relations should work if we'd show subtasks beneath their parent task in the list. Should we just ignore them? Should we do something else about them?

@bolgrov Thanks for the screenshot, I think that makes it a bit more clear. The little indicator about how many subtasks are done is already implemented for checklists: ![image](/attachments/95bc16ac-9db4-41f5-bd48-6c52de039fca) ![image](/attachments/79e306d0-56bb-490a-9c36-58cef023d57f) What would you say is a use-case where you absolutely need a fully-fledged subtask and a checklist won't be enough? I think something like you showed in the screenshots would absolutely be doable, but I'm a bit hesitant about the performance. But that's something to check and see how bad it really is. The other thing I'm not sure about is the way other relations should work if we'd show subtasks beneath their parent task in the list. Should we just ignore them? Should we do something else about them?
4.7 KiB
5.5 KiB

What would you say is a use-case where you absolutely need a fully-fledged subtask and a checklist won't be enough?

Although the checklists are an awesome feature, which I've never seen implemented in previous closed-source apps, they are not a full feature task.
Checklist are good for tasks which have many subtasks which don't need any information updating on them or other sub-sub-tasks. A perfect example of this would be a shopping list task with various checklist items to buy or a Pack suitcase with various checklist items of things to pack.
These two examples are very handy for this type of tasks which are often even reusable.
However, for other types of tasks, we need subtasks which can take days to finish, we have to comment and update information on them, can have their on subtasks/blocking/ etc tasks. So for these types of tasks, a checklist is not enough.

I think something like you showed in the screenshots would absolutely be doable, but I'm a bit hesitant about the performance. But that's something to check and see how bad it really is.

In relation to performance, maybe it could be helpful setting a default number of expanded subtasks and if the users do have more than that (which I think will be the rare case when this happens) there could be a button to load more subtasks.

The other thing I'm not sure about is the way other relations should work if we'd show subtasks beneath their parent task in the list. Should we just ignore them? Should we do something else about them?

The simple answer would be yes, just display the tasks which are subtasks. This is what almost all the other Task management apps do, albeit because they only work with subtasks.
However, since Vikunja has all these useful task relations, we could levarage that specially in the Kanban view.
I have some ideas of how that could work, and want to make a mockup image and post here later for you to see.

However, maybe a first implementation of how the subtasks are handled in Todoist (post above) i.e. only display subtasks should be implemented. And maybe later, if you agree with the mockup I'll post you could implement these additional features I'll write later ?
Would like to hear your opinion @konrad and anyone who wants to chime in also !

> What would you say is a use-case where you absolutely need a fully-fledged subtask and a checklist won't be enough? Although the checklists are an awesome feature, which I've never seen implemented in previous closed-source apps, they are not a full feature task. Checklist are good for tasks which have many subtasks which don't need any information updating on them or other sub-sub-tasks. A perfect example of this would be a shopping list task with various checklist items to buy or a *Pack suitcase* with various checklist items of things to pack. These two examples are very handy for this type of tasks which are often even reusable. **However**, for other types of tasks, we need subtasks which can take days to finish, we have to comment and update information on them, can have their on subtasks/blocking/ etc tasks. So for these types of tasks, a checklist is not enough. > I think something like you showed in the screenshots would absolutely be doable, but I'm a bit hesitant about the performance. But that's something to check and see how bad it really is. In relation to performance, maybe it could be helpful setting a default number of expanded subtasks and if the users do have more than that (which I think will be the rare case when this happens) there could be a button to *load more subtasks*. > The other thing I'm not sure about is the way other relations should work if we'd show subtasks beneath their parent task in the list. Should we just ignore them? Should we do something else about them? The simple answer would be **yes**, just display the tasks which are *subtasks*. This is what almost **all** the other Task management apps do, albeit because they only work with subtasks. However, since Vikunja has all these useful task relations, we could levarage that specially in the Kanban view. I have some ideas of how that could work, and want to make a mockup image and post here later for you to see. However, maybe a first implementation of how the subtasks are handled in Todoist (post above) *i.e.* only display subtasks should be implemented. And maybe later, if you agree with the mockup I'll post you could implement these additional features I'll write later ? Would like to hear your opinion @konrad and anyone who wants to chime in also !

Also see https://community.vikunja.io/t/task-checklists/680 - this paralellization of discussions in Discourse and Gitea is a bit annoying ^^

Also see https://community.vikunja.io/t/task-checklists/680 - this paralellization of discussions in Discourse and Gitea is a bit annoying ^^

Is there another communication channel apart from Gitea, Github and Discourse? I am pretty sure I wrote about what I wanted to add here somewhere, but I just can't find it anymore, so I will reiterate it quickly.
I think for each list there should be an option how to display subtasks, in two parts:

  • how many parent task names to display as prefix (i.e. if you have a task hierarchy Invoicing > Crater > CSV Import whether to display only the name (CSV Import) or include parent task names - the current default would correspond to a value of 1 here - this will especially be important for kanban, while the list can use indentation as suggested)
  • whether to only display leaf nodes, only a specific subtask level, or all nodes (currently: all)

This might also be implemented for filters, especially the latter, by adding that as a filterable attribute.

Is there another communication channel apart from Gitea, Github and Discourse? I am pretty sure I wrote about what I wanted to add here somewhere, but I just can't find it anymore, so I will reiterate it quickly. I think for each list there should be an option how to display subtasks, in two parts: - how many parent task names to display as prefix (i.e. if you have a task hierarchy `Invoicing > Crater > CSV Import` whether to display only the name (`CSV Import`) or include parent task names - the current default would correspond to a value of `1` here - this will especially be important for kanban, while the list can use indentation as suggested) - whether to only display leaf nodes, only a specific subtask level, or all nodes (currently: all) This might also be implemented for filters, especially the latter, by adding that as a filterable attribute.
Member

I have similar doubts about the deep nesting as @konrad for the list view:

The moment we allow deep nesting we have something similar to an outliner. This means people would expect outliner functionality. Also many pkm apps go more in this direction, like RemNote or Logseq. My personal opinion here is that I see Vikunja more as a classic todo app. Meaning tasks and lists.

There one thought here that makes this for me especially clear why this makes sense:

Time is linear, so you can only do one thing after the other. Meaning if you do a project you need to prepare tasks in that project that you can tackle after each other.

Obviously in the real work projects get easily to complex to plot them down in a simple list. I don't have an answer for that for Vikunja yet. There is a lot of work that I see more import to tackle first.


Sidenote:
I was surprised to when I recently found out that hierachical structures don't seem to be the obvious answer anymore.

I have similar doubts about the deep nesting as @konrad for the list view: ![](https://kolaente.dev/vikunja/frontend/attachments/53ab83fe-6812-4b7a-82a9-b8df45254cec) The moment we allow deep nesting we have something similar to an outliner. This means people would expect outliner functionality. Also many pkm apps go more in this direction, like RemNote or [Logseq](https://logseq.com/). My personal opinion here is that I see Vikunja more as a classic todo app. Meaning tasks and lists. There one thought here that makes this for me especially clear why this makes sense: Time is linear, so you can only do one thing after the other. Meaning if you do a project you need to prepare tasks in that project that you can tackle after each other. Obviously in the real work projects get easily to complex to plot them down in a simple list. I don't have an answer for that for Vikunja yet. There is a lot of work that I see more import to tackle first. ----------- Sidenote: I was surprised to when I recently found out that [hierachical structures don't seem to be the obvious answer anymore](https://www.theverge.com/22684730/students-file-folder-directory-structure-education-gen-z).
Member

I got one more tought here:

I have the feeling that it's not possible to make a really good task manager that supports deep nested structures. At least I haven't found one yet.

When you open to many possiblities to manage your tasks, you end up doing exactly that instead of actually doing them.

I also have think of Notion here, where I made the experience that you end up spending way more time organising your stuff then you should.

For me it seems like tasks that do have subtasks are kind of no tasks anymore. They are 'mini-projects'. This raises the question of what the differences is between them and what we call 'lists' in Vikunja.

To sum up I think we should focus on Vikunjas core strength and do them really well.


Interesting read here would be Linears Method.

I got one more tought here: I have the feeling that it's not possible to make a really good task manager that supports deep nested structures. At least I haven't found one yet. When you open to many possiblities to manage your tasks, you end up doing exactly that instead of actually doing them. I also have think of [Notion](https://www.notion.so/) here, where I made the experience that you end up spending way more time organising your stuff then you should. For me it seems like tasks that do have subtasks are kind of no tasks anymore. They are 'mini-projects'. This raises the question of what the differences is between them and what we call 'lists' in Vikunja. To sum up I think we should focus on Vikunjas core strength and do them really well. ---- Interesting read here would be [Linears Method](https://linear.app/method).

For me it seems like tasks that do have subtasks are kind of no tasks anymore. They are 'mini-projects'. This raises the question of what the differences is between them and what we call 'lists' in Vikunja.

That is why I created vikunja/api#1198 which I will amend soon, explaining why task nesting is important.

TLDR: Yes, they turn into mini-projects, which is exactly what you need for project management (See Scrum: Project > Epic > Story > Task - but flexible for any workflow).

Time is linear, so you can only do one thing after the other.

That point gets moot in project management, too ;)

> For me it seems like tasks that do have subtasks are kind of no tasks anymore. They are 'mini-projects'. This raises the question of what the differences is between them and what we call 'lists' in Vikunja. That is why I created https://kolaente.dev/vikunja/api/issues/1198 which I will amend soon, explaining why task nesting is important. TLDR: Yes, they turn into mini-projects, which is exactly what you need for project management (See Scrum: Project > Epic > Story > Task - but flexible for any workflow). > Time is linear, so you can only do one thing after the other. That point gets moot in project management, too ;)
Member

I agree.
Scrum is a good example. As you wrote the sublevels are defined there, because they are defined by the workflow (scrum).

Fixed but definable hierarchies is something I could get comfortable with :)

I agree. Scrum is a good example. As you wrote the sublevels are defined there, because they are defined by the workflow (scrum). Fixed but definable hierarchies is something I could get comfortable with :)

you can still fix them by introducing a frontend that uses that structure, no need to limit them from the backend-side

because in real-life projects, you often need different breakdown levels depending on the project scope

you can still fix them by introducing a frontend that uses that structure, no need to limit them from the backend-side because in real-life projects, you often need different breakdown levels depending on the project scope
Member

because in real-life projects, you often need different breakdown levels depending on the project scope

Yes! I meant fixed per project / list. Because you really should stick to one workflow in one project :D

> because in real-life projects, you often need different breakdown levels depending on the project scope Yes! I meant fixed per project / list. Because you really should stick to one workflow in one project :D
Owner

I took a stab at this in e41712647d. It's probably not perfect but great for a first version. If you have a lot of tasks and the other tasks are on a different page, you might not see certain sub tasks. Not sure how to solve that other than returning all tasks from the api, which could get resource heavy and will probably mess with pagination.

Haven't decided either on whether to show all levels of sub tasks, at some point you will run out of space to display them (but at that point you probably should rethink your pm strategy).

Here's how it looks:

image

I took a stab at this in https://kolaente.dev/vikunja/frontend/commit/e41712647d1c699482ddc7a323f22b63f7c7e1db. It's probably not perfect but great for a first version. If you have a lot of tasks and the other tasks are on a different page, you might not see certain sub tasks. Not sure how to solve that other than returning all tasks from the api, which could get resource heavy and will probably mess with pagination. Haven't decided either on whether to show all levels of sub tasks, at some point you will run out of space to display them (but at that point you probably should rethink your pm strategy). Here's how it looks: ![image](/attachments/6aef9e5d-c458-4c9d-b883-64020b9fbe7e)
Sign in to join this conversation.
No Milestone
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: vikunja/vikunja#1761
No description provided.