Improvement suggestions

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 :slight_smile:

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 :slight_smile:

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

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.

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

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

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.

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

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).

Yes there is indeed a big crossover!

Wekan for example creates subtask in a separate board, which in Vikunja would be “another project” :wink:. 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.

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.

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.

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)…

…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: