Improvement suggestions

[avatar1024]

Hello,

First of all I’d like to thank everyone working on this brilliant project. I am a fairly new user but I’ve really been enjoying over the past few months (I was previously a Wekan user).

In the spirit of making it even better I would like to point to a couple of minor improvements when it comes to the UI and one more major suggestion to improve the consistency and power when it comes to the logic of tasks/projects management.

Minor IU improvements taken from Wekan

• One handy feature in Wekan was the ability to change / assign properties to task without having to fully open the task. For things like changing labels, mark as done, delete/archive this is very good (see the screenshot). I believe a similar approach could work in Vikunja, at least for the list and Kanban views.
  
  
• In Wekan it is possible to hover on a card/task (which highlights it) and activate keyboard shortcuts straight from there without having to open the card. Again this is super useful to quickly manipulate tasks with just mouse motion and pressing keys (deleted/archive, assign card to yourself, etc)
• (not taken from wekan) It would be useful to be able to assign tasks to teams, which would then automatically assign it to all users of that team.

While the above would be nice to have for slicker experience, they definitely are not deal breaker.

Suggestion on the logic and management of projects/tasks/subtasks

Currently in Vikunja:

• you can have projects and sub projects, within which you have tasks that can be viewed as list, gantt, kanban, table.
• projects can have a name, an identifier, can be shared with users and teams, can have parent/sub projects and contain tasks.

Within tasks you can:

• have checklists in the description which which show progress when you tick them off (great!), which is handy for writing down the list of little actions one has to carry out to complete the task (NB: you cannot assign individual list items to different users).
• create relations to other tasks, such as subtask, which is super handy in principle. These relations are other tasks which can therefore be individually assigned to different users. Relations also appear as tick boxes but do not show progress, the tick box is effectively just a useful indicator of what has been done within a given constellation of tasks relations.

This approach is already pretty good but I believe leaves a few gaps which I think can be solved in a neat way.

• Currently it is not really possible to monitor the progress of a parent project in relation to its sub-projects. Sub-project do not appear in the list/table/gantt/kaban view of the parent project in anyway.
• Only in the list view we can see the relationship between tasks and subtasks. In the Kanban view especially this is pretty messy and confusing as they are not linked in any way and in effect the parent task becomes redundant to see in there if it is only made of subtasks (I currently use colors to show the association - see screenshot)
  
  
• If a project is big enough, and is broken down of smaller sub-projects, the parent project itself may contain no tasks, which leave an empty and useless view, whereas in fact the sub-projects are the kind of milestones we’d like to be able to use to monitor the progress of the parent project with (see screenshot)
  
  
  
• If we create a sub-project which contains only tasks that are subtasks of task in the parent project, the list and table views in that sub-project are empty and those (sub)tasks only appear in the kanban view of the project (they do however appear in the list and table of the parent project - see screenshot).
  
  
  
  
  
  
  
  
  
  
  

I think all this can be solved neatly

First let’s think about the differences between items in a checklist and subtasks (two functions that may appear somewhat similar but that in fact serve different purposes). In effect checklists are list of mini (sub)tasks to be carried out by the person assigned to a task, whereas a subtask is a task related to the parent task but that is big enough so that it may need to be assigned to someone else, and it may need to itself contain a checklist…it is a kind of “mini project”.

This made me realise that if we redefine a sub-projects as “a task that contains subtasks” then something cool happens.

• As a sub-project it should still appear in the project hierarchy (on the left hand-side) but they would also become a task of the parent project. This means they could be visualised in the list/gantt/etc views of the parent project. It would also allow us to assign to it any properties of a task (due date etc.) which could be very handy for sub-project.
• Any tasks that contain a subtask would automatically become a sub-project with its own views that contain all the subtasks. The subtasks would still appear in the list views and tables (as they currently do), but not in the kaban view of the parent project.

This approach would make it really easy and consistent to managed and monitor progress all the way through the hierarchy from projects to tasks to subtasks.

Key changes would be:

• make it possible for tasks to appear in the project hierarchy on the left hand side
• make it so that as soon as you create the subtask, the parent task appears in the project hierarchy, the subtasks appears in all the views of the newly created sub-project / parent task, and only in the list, table and gantt views of the parent project as a subtasks (as it already does currently), but not in the kaban view.

As you can see in the above screenshots, I have kinda reproduced this behaviour of creating a sub project within which I chuck in the the subtasks, but it is all done manually and doesn’t work very well or consistently that way.

I hope you’ll find some of this somewhat useful

[avatar1024]

The proposed approach would deal with requests / issues such as:

Viewing all tasks for parent project and sub projects

Currently i can only view tasks for sub projects by clicking on each one, is there a way to show all tasks from sub projects just by clicking on the parent project? Create project “test parent project” Create task “test parent project task” Create new project “test parent project sub project” with parent of “test parent project” Create task “test parent project sub project task” View kanban of “test parent project” [image] In backlog i only see “test parent project task” and not the task…

Sub Project improvement views

I agree with that. A simple filter would be a great thing for my use Filters include tasks from subprojects Include Tasks which don’t have a value set Require all filters to be true for a task to show up

Listing subprojects tasks

Should be nice to have an option to shows all tasks belonging to child projects. Thank you

Show subprojects inside a project

Maybe a carrousel, maybe collapsed… Let’s see if somebody else need it and have a good idea Thank you!

Confusing Layout of subtasks

Thank you so much for your great work. I was exactly looking for this.

[kolaente]

Hey, thanks for the very detailed suggestions!

Let me go into more detail for a few of these. I’ve also replied to your GitHub issue about the missing subtasks.

@avatar1024

Currently it is not really possible to monitor the progress of a parent project in relation to its sub-projects. Sub-project do not appear in the list/table/gantt/kaban view of the parent project in anyway.

As a workaround, you could create a saved filter with all projects you need.

@avatar1024

Only in the list view we can see the relationship between tasks and subtasks. In the Kanban view especially this is pretty messy and confusing as they are not linked in any way and in effect the parent task becomes redundant to see in there if it is only made of subtasks (I currently use colors to show the association - see screenshot)

Do you have any good examples of how other applications are solving this in a kanban view?

@avatar1024

but they would also become a task of the parent project

You mean it would show up as a “real” project in a way?

Your suggestion reminds me of this: #1198 - What if lists themselves were just tasks? - vikunja - Gitea

What if the user does not want to have their subtasks appear as projects? What if a project is really big and has hundreds of these? How would the UI stay manageable?

I’m really hesitant about implementing this. I think this would somewhat make things more complicated from a UX perspective. The change in the data structure would be huge as well, which means many merge conflicts and a long time with nothing else getting done.

[avatar1024]

Hello, many thanks for reading and taking the time to look into this, and for your comments!

@kolaente

I’m really hesitant about implementing this. I think this would somewhat make things more complicated from a UX perspective. The change in the data structure would be huge as well, which means many merge conflicts and a long time with nothing else getting done.

First let me start by the end and say I totally understand and respect the hesitation/reluctance when it comes to things like this! Especially considering how to migrate existing projects / instances to a new structure without corruption, data losses, etc. It would be a different story starting from scratch. Yet I thought it was still worth suggesting, given this approach tries to streamline / simplifies the concepts inside the app, making most things tasks/cards other than top-level projects, and so while it does involve changing a few things for tasks so they can be more like projects (e.g. making them shareable) and converting sub-project into cards, I thought it might be possible to find a reliable and clean way to do it.

Also in the long run it feels it would allow for a cleaner and easier evolution for the app by having less, yet more consistent concepts that clearly integrate through the different level in a project hierarchy (both for teh devs and users, since as noted in the forum thread linked in my post above, there already seems to be confusion brought by the current implementation of sub-projects).

@kolaente

Your suggestion reminds me of this: #1198 - What if lists themselves were just tasks? - vikunja - Gitea

Yes there is indeed a big crossover!

@kolaente

Do you have any good examples of how other applications are solving this in a kanban view?

Wekan for example creates subtask in a separate board, which in Vikunja would be “another project” . In Wekan it is technically possible to set the “sub-task board” as the current board which then reproduces the current Vikunja behaviour, but this is not the default and is a pretty niche use-case.

@kolaente

What if the user does not want to have their subtasks appear as projects?

There could be a setting at the project level that can be ticked on and off “create subtasks as a sub-project” so that users could opt-out of if they don’t like that behaviour. But this does not (have to) alter the concept of sub-projects being task (of parent project), it simply means that in some case, sub-task are created but the parent task does not become a project and in other cases it does.

@kolaente

What if a project is really big and has hundreds of these? How would the UI stay manageable?

Sub-projects are already collapsible which helps a lot with the keeping the UI manageable. One other thing could be to add a setting at the sub-project level to be able “hide/unhide” the project from the hierarchy if that was really an issue.

@kolaente

You mean it would show up as a “real” project in a way?

I mean sub-projects would show-up as tasks in the parent project and so would appear in the lists/gantt/table/kaban views of the parent project which allows to keep track and organise the progress of the parent project in relation to its sub-project (see screenshots below)…

@kolaente

As a workaround, you could create a saved filter with all projects you need.

…which unfortunately is not currently possible to do with filters.

I have sent you an invite to a moke up of what I mean on a vikunja instance where I manually demonstrate the concept (the invite will come from a Cloudron on the domain chourmo.net) - caveat is that some of the list view will be broken because of the issue with subtasks reported on Github.

Btw solving that GitHub issue about the subtasks not showing up in the list view would at least allow to manually create the suggested behaviour in this thread (i.e. manually creating sub projects=parents tasks and chuck the subtasks in it to create a fully organised hierarchy made of tasks and subtasks from the top level project). E.g:

[kolaente]

Hey, sorry for the long delay in my response, I wanted to take the time to properly respond to you, which took longer than I wished.

@avatar1024

Also in the long run it feels it would allow for a cleaner and easier evolution for the app by having less, yet more consistent concepts that clearly integrate through the different level in a project hierarchy (both for teh devs and users, since as noted in the forum thread linked in my post above, there already seems to be confusion brought by the current implementation of sub-projects).

I see how this would be the case for power-users but I think it would take longer to “click” than what many new users would be willing to spend time on it. They usually expect something called “projects” where they can put their tasks into, as is the case with many other tools.

@avatar1024

…which unfortunately is not currently possible to do with filters.

You mean the filter in a project? Because this is very much possible with a saved filter.

@avatar1024

Btw solving that GitHub issue about the subtasks not showing up in the list view would at least allow to manually create the suggested behaviour in this thread (i.e. manually creating sub projects=parents tasks and chuck the subtasks in it to create a fully organised hierarchy made of tasks and subtasks from the top level project).

A fix for that is underway.

[avatar1024]

Hi, thank you for your reply, for paying attention to this and no worries at all about taking the time, we’re all busy and it’s hard to make everything fit.

@kolaente

I see how this would be the case for power-users but I think it would take longer to “click” than what many new users would be willing to spend time on it. They usually expect something called “projects” where they can put their tasks into, as is the case with many other tools.

The proposal here is not so much around how it looks in the UI, I still think a project/subproject should be called a project/subproject and appear as a project/subproject, and so intuitively it shouldn’t change much in the UX for any users (power user or not). Let me try to put it another way:

• sub-project are created as places that themselves contain tasks, and so a sub-project can be seen conceptually a “parent” place for those tasks, and the corollary is that tasks contained in a sub-project can be seen conceptually as sub-tasks of that sub-project.
• making that relationship more explicit and therefore functional in the code so that under the hood:
  • a sub-project = a parent task = just a task in a parent project which can also be displayed in the UI as a sub-project
  • tasks within a sub-project = sub-tasks of the parent task / sub-project

would allow in the code to have a clear and consistent conceptual relationships between Project > Tasks > Subtask to handle the management and tracking of tasks through the different levels of a project’s hierarchy, fix various consistency issues and given flexible UX through UI options such as (either global or per-project) like:

• display sub-projects as tasks in the parent project
• display all parent tasks as sub-projects
• track project tasks as project sub-tasks

If none of those are selected, Vikunja would look like as it does now. If they all are selected then:

• sub-projects can appear as tasks of a parent project
• as we create sub-tasks in a task then that “parent” task now also shows-up as a sub-project and the sub-tasks appear in the kanban view of the sub-project
• any task created in the sub-project automatically appear as sub-tasks of the parent task

…which I think would be consistent and awesome

I’m writing all this meanly for clarifications (to for insisting) in case there might still be some misunderstanding. Vikunja is your project and it’s totally fine if you don’t like this approach. I’m only making suggestions which I feel would benefit my use case and the Vikunja project as a whole.

@kolaente

You mean the filter in a project? Because this is very much possible with a saved filter.

No, I mean like in the screenshots in my previous post, where it is possible to follow through th whole hierarchy and where sub-projects appear as tasks in the parent.

@kolaente

A fix for that is underway.

Brill! Thank you. At least this will make the manual hack to kinda reproduce the suggested behaviour more usable.

[avatar1024]

@kolaente

They usually expect something called “projects” where they can put their tasks into

And so this is totally still the case in the proposed approach. A project/sub project is absolutely a place where you put tasks into.

In fact this whole proposed approach is based specifically on that relationship. A project is a parent place for tasks, therefore a parent task (i.e. a task with subtasks) which is also a parent place for tasks can be seen conceptually and practically as a (sub)project, and, as a corollary, a (sub)project can be seen and used as a parent task in the parent project.

[kolaente]

Gotcha, that makes things clearer. I think I understand where you’re coming from.

I’m still hesitant about implementing this, but I think it would make sense to have it eventually. I won’t commit to it now though.
If someone from the community wants to implement and put a PR forward, please do.