Question: Indented sub-tasks
Openopened 2 years ago by azymondrian · 21 comments
Reference in new issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
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.
You mean you want to see all sub tasks a task has in the list view?
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 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.
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.
Yeah pagination definitely makes it more difficult. I personally would prefer the second option:
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.
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.
For drag n drop please see the discussion in #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.
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
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).
Also, their collapsable.
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:
And to see the subtasks of that tasks we click on it:
@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:
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?
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.
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 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 ^^
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:
Invoicing > Crater > CSV Importwhether to display only the name (
CSV Import) or include parent task names - the current default would correspond to a value of
1here - this will especially be important for kanban, while the list can use indentation as suggested)
This might also be implemented for filters, especially the latter, by adding that as a filterable attribute.
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.
I was surprised to when I recently found out that hierachical structures don't seem to be the obvious answer anymore.
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.
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).
That point gets moot in project management, too ;)
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
Yes! I meant fixed per project / list. Because you really should stick to one workflow in one project :D