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