⚡️ Ideas
Darren Brierton Darren Brierton Jan 27, 2025

Group by relative day/week/month/year

Explain the problem as you see it

A common task management strategy is to group tasks by today, tomorrow, this week, next week, this month, next month, etc., and then to manage planning by moving tasks between those groups, a little like on a Kanban board. There is currently no way to actually do this in Tana.

Why is this a problem for you?

I can create multiple search nodes that correspond to those groups:

  1. Tasks with due date = FOR RELATIVE DATE today
  2. Tasks with due date = FOR RELATIVE DATE tomorrow
  3. Tasks with due date = FOR RELATIVE DATE this week AND NOT FOR RELATIVE DATE today/tomorrow
  4. Tasks with due date = FOR RELATIVE DATE next week
  5. Tasks with due date = FOR RELATIVE DATE this month AND NOT FOR RELATIVE DATE this week
  6. Tasks with due date = FOR RELATIVE DATE next month

etc.

But currently you cannot drag-and-drop between distinct search nodes to change somethings's field values.

Suggest a solution

The obvious solution would appear to be to allow dragging and dropping between search nodes. However, it soon becomes apparent that this would lead to chaos for unsuspecting users. The results of dragging something from one search node to another based on entirely different search criteria might be wholly unintuitive to a normal user, and in many cases exactly what changes should be made might be underdetermined.

Therefore I propose a custom grouping option when grouping by a date field: group by relative date. There would be checkboxes to select which of the 12 relative date periods should be displayed:

  • yesterday/today/tomorrow
  • last/this/next week/month/year

The grouping would be exclusive: items shown in "today" would not be shown in "this week" or "this month"; items shown in "this week" would not be shown in "this month". Dragging and dropping a task from the "today" column to the "this week" column would change its date field value from, e.g. Mon 27th Jan to simply Week 05.

⁨4⁩ ⁨Comments⁩

it soon becomes apparent that this would lead to chaos

I see nothing that could lead to chaos or disrupt user expectations. On the contrary, this is the most intuitive way to use it. When moving a node from one search node to another, only one thing should happen — the setting of parameters based on which the search was conducted. For the sake of security and stability, a restriction on dragging nodes with differing tags will suffice. In all other cases, the setting of properties described in the receiving search node is the expected behavior.

There are at least a couple of reasons that I prefer the solution that uses grouping quite independently of whether Tana should allow users to drag and drop between search nodes:

  1. In cards view you can use the multiple column display that Tana already has. I strongly suspect that users who use this task organisation workflow would prefer to be able to organise tasks in this Kanban-style manner, and this takes advantage of something that is already provided by Tana. Trying to achieve something similar with search nodes would require opening them into separate panels, and given that it is likely that this would require four or five panels to be simultaneously open some user simply will not have screen real estate for this.

  2. This provides a built-in solution for a common use case, and does not require that less technical users manually create the required search nodes.

The question of whether Tana should allow users to drag-and-drop between arbitrary search nodes is one that ultimately Tana must answer. I see numerous difficulties there.