What if lists themselves were just tasks? #1198

New Issue

xeruf · 2022-07-09T01:49:07Z

xeruf commented

2022-07-09 01:49:07 +00:00

As mentioned in the tasklist discussion, I hate artifical distinctions:
https://community.vikunja.io/t/task-checklists/680/5?u=xeruf

I did a write-up of my task-management dream a while ago:
https://github.com/xeruf/howtodo#design

That whole document might hold some interesting points for you, but let me mention my current use-cases:

I add a tag to all tasks in a list. Rather than tasks, it might make more sense to have lists be tags, and the lists are simply predefined views. This allows for more flexibility when juggling many lists.
I am now creating a kanban board that essentially lists all lists and provides some details and status information about them. If lists were tasks, I could add them there directly, avoiding redundant descriptions and providing easier back and forth navigation.

In the end, I don't see why lists have to be a separate entity, just as checklists. It is adding complexity and creating artificial restrictions at the same time, for no gain.
And the UI can still stay mostly as it is, but rather than imposing, what it shows you are merely sane defaults to be changed at your mercy.
It is a simplification in the backend that brings great flexibility for the future.
To bring both points together: Namespaces could be tags, Lists could be Root Tasks and belong to multiple namespaces with tags.

Then one could even simplify sharing, because by adding a tag to a person (plus a RO/RW/Admin value) you can share them all tasks belonging to that tag, no need for different scopes like namespaces/lists.
Only public sharing links need to be extra, which can be created for any view of any task - you could create Kanban or Gantt views for subtasks (epics) of a root task (project) and share them, because every task can be turned into its own view.
Welcome to Productivity and Management Utopia.

See also https://github.com/xeruf/howtodo/blob/master/concepts.md:

All task managers I have seen so far were quite opinionated. Since task management is a deeply personal matter, this likely yields many people to abandon these digital tools not long after embracing them. To build trust in the system, it needs to be your system.
So the foundational principle of this task manager is to rely as little as possible on special mechanics, implementing all convenience behavior and specialized features in a generalized way, allowing to easily compose and customize them.

As mentioned in the tasklist discussion, I hate artifical distinctions: https://community.vikunja.io/t/task-checklists/680/5?u=xeruf I did a write-up of my task-management dream a while ago: https://github.com/xeruf/howtodo#design That whole document might hold some interesting points for you, but let me mention my current use-cases: 1. I add a tag to all tasks in a list. Rather than tasks, it might make more sense to have lists be tags, and the lists are simply predefined views. This allows for more flexibility when juggling many lists. 2. I am now creating a kanban board that essentially lists all lists and provides some details and status information about them. If lists were tasks, I could add them there directly, avoiding redundant descriptions and providing easier back and forth navigation. In the end, I don't see why lists have to be a separate entity, just as checklists. It is adding complexity and creating artificial restrictions at the same time, for no gain. And the UI can still stay mostly as it is, but rather than imposing, what it shows you are merely sane defaults to be changed at your mercy. It is a simplification in the backend that brings great flexibility for the future. To bring both points together: Namespaces could be tags, Lists could be Root Tasks and belong to multiple namespaces with tags. Then one could even simplify sharing, because by adding a tag to a person (plus a RO/RW/Admin value) you can share them all tasks belonging to that tag, no need for different scopes like namespaces/lists. Only public sharing links need to be extra, which can be created for any view of any task - you could create Kanban or Gantt views for subtasks (epics) of a root task (project) and share them, because every task can be turned into its own view. Welcome to Productivity and Management Utopia. See also https://github.com/xeruf/howtodo/blob/master/concepts.md: > All task managers I have seen so far were quite opinionated. Since task management is a deeply personal matter, this likely yields many people to abandon these digital tools not long after embracing them. To build trust in the system, it needs to be your system. > So the foundational principle of this task manager is to rely as little as possible on special mechanics, implementing all convenience behavior and specialized features in a generalized way, allowing to easily compose and customize them.

👀 1

dpschen commented

2022-07-09 17:22:32 +00:00

I really like your thought process.
Sadly I don't have the time right now to answer super deep to every of your thought.

I have a similar history like you with my task managers and finding an answer to this question is one of my main motivations for working on Vikunja.

For me Vikunja is lacking right now functionality in these areas:

Tagging: I have similar thoughts than you here. Changing the system that we have is not a simple task though.
Improvements of saved views (looking at a specific list with a defined set of filters). We call this filters right now.
Help with routine stuff like habits, chores etc. This should include the thought of what separates Vijunja from a calendar.

Having said that, I guess we are talking about multiple months up to years until we can expect significant changes in these areas. We are developing Vikunja in our free time. Just keeping the code base up-to-date, without changing any functionality is already a major task. Currently we are still in the progess of migrating to Vue3 and TypeScript. Both are major tasks that sadly add a lot of new bugs. After we have realeased a new version that is somewhat stable we can think of changing / adding features :)

We should continue this discussion though!

I really like your thought process. Sadly I don't have the time right now to answer super deep to every of your thought. I have a similar history like you with my task managers and finding an answer to this question is one of my main motivations for working on Vikunja. For me Vikunja is lacking right now functionality in these areas: - Tagging: I have similar thoughts than you here. Changing the system that we have is not a simple task though. - Improvements of saved views (looking at a specific list with a defined set of filters). We call this filters right now. - Help with routine stuff like habits, chores etc. This should include the thought of what separates Vijunja from a calendar. Having said that, I guess we are talking about multiple months up to years until we can expect significant changes in these areas. We are developing Vikunja in our free time. Just keeping the code base up-to-date, without changing any functionality is already a major task. Currently we are still in the progess of migrating to Vue3 and TypeScript. Both are major tasks that sadly add a lot of new bugs. After we have realeased a new version that is somewhat stable we can think of changing / adding features :) We should continue this discussion though!

👍 1

konrad commented

2022-07-11 13:48:41 +00:00

Thanks for the in-depth explanation, really seems thought-through.

I understand where you're coming from. I use raindrop for all my bookmarks and really only use their tagging system to organize all bookmarks, and none of the folders.

As I see it, that concept is slightly advanced (even though more powerful) and not for everyone. From a UX perspective it is very easy for new users to wrap their head around the concept of lists with tasks as that's usually something everyone has done on paper at some point. I'm sure there are some improvements to be done for the UX so that a concept of "everything is a task" is as easy for these new users though.

I think we could achieve something like the workflow you're looking for with better filters? Or just a better UI/UX-flow to allow you to easily filter by labels?

Because of the high impact of changing the concept to something else I don't see this happening in the near future.

Eventually I'd like to change the names for lists and namespaces since a list has become more than it was originally, mostly with the addition of multiple different views. Maybe during that transition we could get rid of namespaces completely and allow for nested lists (or whatever they will be called by then) instead.

Thanks for the in-depth explanation, really seems thought-through. I understand where you're coming from. I use raindrop for all my bookmarks and really only use their tagging system to organize all bookmarks, and none of the folders. As I see it, that concept is slightly advanced (even though more powerful) and not for everyone. From a UX perspective it is very easy for new users to wrap their head around the concept of lists with tasks as that's usually something everyone has done on paper at some point. I'm sure there are some improvements to be done for the UX so that a concept of "everything is a task" is as easy for these new users though. I think we could achieve something like the workflow you're looking for with better filters? Or just a better UI/UX-flow to allow you to easily filter by labels? Because of the high impact of changing the concept to something else I don't see this happening in the near future. Eventually I'd like to change the names for lists and namespaces since a list has become more than it was originally, mostly with the addition of multiple different views. Maybe during that transition we could get rid of namespaces completely and allow for nested lists (or whatever they will be called by then) instead.

xeruf commented

2022-07-11 20:56:02 +00:00

Yes, this is a long-term consideration.

But the great thing about this is that the UX gets easier, not harder, if done right.
Because you could keep the UI as is - namespaces could simply be specially treated tags, and lists are root tasks where all tasks in the list are simply subtasks.
So the UI for new users stays essentially the same, but becomes much more flexible for power users while keeping it simple because the underlying structure is consistent.

Yes, this is a long-term consideration. But the great thing about this is that the UX gets easier, not harder, if done right. Because you could keep the UI as is - namespaces could simply be specially treated tags, and lists are root tasks where all tasks in the list are simply subtasks. So the UI for new users stays essentially the same, but becomes much more flexible for power users while keeping it simple because the underlying structure is consistent.

👍 1

xeruf referenced this issue from vikunja/frontend

2022-09-28 16:37:09 +00:00

Question: Indented sub-tasks #1761

xeruf commented

2022-09-28 16:53:56 +00:00

Let me lay out my ideal structure and current workarounds,
illustrating the superiority of this approach:
With everyone in the core team of our company
I want to share an uncompletable root task (“namespace”).

This task has a subtask for each project (“list”),
which might be shared with additional collaborators.
These projects can themselves be displayed on a Kanban board
(currently we have a separate list for that, linking to each project)
showing the status of the project (e.g. Ideation, Planning, Active, Completed) and providing a grand overview.

For each project, subtasks might contain areas (e.g. UX, Backend, Frontend)
or epics (user login, …) or for small projects straight individual tasks.
If it represents an area, it might be shared with a dedicated team for that area
with its own views.

Let me lay out my ideal structure and current workarounds, illustrating the superiority of this approach: With everyone in the core team of our company I want to share an uncompletable root task (“namespace”). This task has a subtask for each project (“list”), which might be shared with additional collaborators. These projects can themselves be displayed on a Kanban board (currently we have a separate list for that, linking to each project) showing the status of the project (e.g. Ideation, Planning, Active, Completed) and providing a grand overview. For each project, subtasks might contain areas (e.g. UX, Backend, Frontend) or epics (user login, …) or for small projects straight individual tasks. If it represents an area, it might be shared with a dedicated team for that area with its own views.

dpschen commented

2022-09-28 16:58:34 +00:00

I like this part:

Maybe during that transition we could get rid of namespaces completely and allow for nested lists (or whatever they will be called by then) instead.

I like this part: > Maybe during that transition we could get rid of namespaces completely and allow for nested lists (or whatever they will be called by then) instead.

xeruf commented

2022-09-28 17:49:21 +00:00

Which creates unnecessary complexity, because when a task turns out more complicated than expected you have to convert a task to a list.

What is the advantage of the separation if you ignore the UI (because there the separation can still be kept if wanted, regardless of the backend structure)?

Which creates unnecessary complexity, because when a task turns out more complicated than expected you have to convert a task to a list. What is the advantage of the separation if you ignore the UI (because there the separation can still be kept if wanted, regardless of the backend structure)?

konrad commented

2022-09-28 18:04:17 +00:00

What is the advantage of the separation if you ignore the UI (because there the separation can still be kept if wanted, regardless of the backend structure)?

The biggest advantage is it makes it easier to understnad on a conceptual level (not only for end users, which is something that could be solved via UI, but also for us as developers). Sharing/rights managment and things like kanban buckets might get more complicated too although I think that would be the case as well when having deeply nested lists.

I understand why your approach is a very nice concept but it gets complicated to migrate from our existing structure. Starting from scratch would be a different story.

That being said, do you think you could achieve maybe 90% of the structure you want with infinite sub lists? (for example the scrum example sounds very much doable with sub projects)

> What is the advantage of the separation if you ignore the UI (because there the separation can still be kept if wanted, regardless of the backend structure)? The biggest advantage is it makes it easier to understnad on a conceptual level (not only for end users, which is something that could be solved via UI, but also for us as developers). Sharing/rights managment and things like kanban buckets might get more complicated too although I think that would be the case as well when having deeply nested lists. I understand why your approach is a very nice concept but it gets complicated to migrate from our existing structure. Starting from scratch would be a different story. That being said, do you think you could achieve maybe 90% of the structure you want with infinite sub lists? (for example the scrum example sounds very much doable with sub projects)

xeruf commented

2022-09-28 19:37:28 +00:00

If a task would automatically turn into a list when you add a subtask, we would essentially arrive at the same point ;) otherwise, that would depend on the UX - you would essentially need to navigate two trees, which does not sound handy

dpschen commented

2022-09-30 11:18:55 +00:00

Sharing/rights managment and things like kanban buckets might get more complicated too although I think that would be the case as well when having deeply nested lists.

I think the impact on right management could be mitigated if we would say that only root items can be shared.

I made the experience that it's a really bad idea to support sharing stuff that is deeply nested. If you want to do that you would need to create a new shared root 'list'/'tasklist' (or whatever it would then be called).

That said, all of this seems like something out of our current focus.

> Sharing/rights managment and things like kanban buckets might get more complicated too although I think that would be the case as well when having deeply nested lists. I think the impact on right management could be mitigated if we would say that only root items can be shared. I made the experience that it's a really bad idea to support sharing stuff that is deeply nested. If you want to do that you would need to create a new shared root 'list'/'tasklist' (or whatever it would then be called). That said, all of this seems like something out of our current focus.

😕 1

dpschen commented

2022-09-30 11:21:36 +00:00

With everyone in the core team of our company
I want to share an uncompletable root task (“namespace”).

What @xeruf says here reminds me of the possibility in Todoist to create tasks that do not have a checkmark:

They do this when you prefix your title with * , so in this case it's * Fonts.

> With everyone in the core team of our company I want to share an uncompletable root task (“namespace”). What @xeruf says here reminds me of the possibility in Todoist to create tasks that do not have a checkmark: ![image](/attachments/73c16a9b-2bf6-41d0-83db-25178348b616) They do this when you prefix your title with `* `, so in this case it's `* Fonts`.

image.png

59 KiB

xeruf commented

2022-10-01 09:59:23 +00:00

Just to clarify why I am so adamant about this:
We discovered Vikunja in our unhappiness with existing project and task management software, as we need a tool with a single source of truth but many views/facets - for planners, stakeholders, designers, scrum managers, controllers, developers, QA, leadership...

We look at Vikunja and see not just a nice task manager, but the possibility to disrupt the whole torpid market of modeling development processes digitally, displacing the annoying proprietary giants like Atlassian and narrow-minded tools like Wekan while also offering everything that is nice for personal use, like Todoist, and adding unprecedented integration with other tools such as Gitea, Wikis & co.

Once the resources are there we will implement this vision through open-source, and we would be happy for Vikunja to be its foundation and its developers part of the team :)

However, I have also thought about the architecture and we might actually need to redo the data models at that point, to use a graph database like ArangoDB - that way everything is not just a task but a node, which can be tagged through edges/connections. Anyways, I'll leave that for my soon-to-come blog entry...

Related: vikunja/frontend#363 and vikunja/api#1249

Just to clarify why I am so adamant about this: We discovered Vikunja in our unhappiness with existing project and task management software, as we need a tool with a single source of truth but many views/facets - for planners, stakeholders, designers, scrum managers, controllers, developers, QA, leadership... We look at Vikunja and see not just a nice task manager, but the possibility to disrupt the whole torpid market of modeling development processes digitally, displacing the annoying proprietary giants like *Atlassian* and narrow-minded tools like *Wekan* while also offering everything that is nice for personal use, like *Todoist*, and adding unprecedented integration with other tools such as *Gitea*, *Wikis* & co. Once the resources are there we will implement this vision through open-source, and we would be happy for Vikunja to be its foundation and its developers part of the team :) However, I have also thought about the architecture and we might actually need to redo the data models at that point, to use a graph database like ArangoDB - that way everything is not just a *task* but a *node*, which can be tagged through edges/connections. Anyways, I'll leave that for my soon-to-come blog entry... Related: https://kolaente.dev/vikunja/frontend/issues/363 and https://kolaente.dev/vikunja/api/issues/1249

👍 1

konrad commented

2022-10-02 14:19:46 +00:00

I see where this is valuable - actually that's part of the reason why Vikunja has list views and kanban boards etc. I'm doing my grocery list and project management for Vikunja with it and I think that's already pretty far from each other in terms of flexibility.

As a long-term goal I think having more flexibility in Vikunja to achieve what you need is something very doable. It'll just be a lot of work to migrate everything over from the current state, hence I want to have a clear plan and make the objectives clear before starting such an adventure. Right now I'm not sure if "everything is a task" would be the only way to achieve what you want. Also I don't think this is something for the immediate future, rather a long-term adventure. I'd be happy to work with you on this once the details are clear.

I'll be awaiting your blog post :)

I see where this is valuable - actually that's part of the reason why Vikunja has list views and kanban boards etc. I'm doing my grocery list and project management for Vikunja with it and I think that's already pretty far from each other in terms of flexibility. As a long-term goal I think having more flexibility in Vikunja to achieve what you need is something very doable. It'll just be a lot of work to migrate everything over from the current state, hence I want to have a clear plan and make the objectives clear before starting such an adventure. Right now I'm not sure if "everything is a task" would be the only way to achieve what you want. Also I don't think this is something for the immediate future, rather a long-term adventure. I'd be happy to work with you on this once the details are clear. I'll be awaiting your blog post :)

👍 3

dpschen referenced this issue from vikunja/frontend

2022-11-12 13:46:27 +00:00

[Feature Request] Be able to change KanBan buckets for a task from within the task. #1793

xeruf commented

2023-08-31 14:20:28 +00:00

FYI: I am considering to write my Bachelor Thesis next year about this concept, that would provide you a very detailed plan :)

👀 1

xeruf referenced this issue from vikunja/frontend

2023-08-31 14:39:47 +00:00

Uncouple KANBAN from Lists #1976

xeruf commented

2023-09-03 18:16:56 +00:00

By the way the first iteration of that "blog post" ended up here: https://code.ftt.gmbh/janek/nodal/src/branch/main/nodal.org
Idk if I ever shared that ^^

By the way the first iteration of that "blog post" ended up here: https://code.ftt.gmbh/janek/nodal/src/branch/main/nodal.org Idk if I ever shared that ^^

konrad referenced this issue from a commit

2024-02-07 14:00:30 +00:00

chore(deps): update dependency browserslist to v4.19.1 (#1198)

Sign in to join this conversation.