Trying to solve "inline-tasks bloating with properties" problem

Help
1

Hello everyone!

So, as you all know after the introduction of the task-notes idea, its very easy to add a lot more properties to a particular task than usual now. All inline-tasks cannot be converted to a task-note (atleast this is the workflow I follow and I saw few other users follow as well). So, basically when we feel a particular inline-task is no more suitable to be an inline-task we convert it into a task-note.

Now when it comes to managing any kind of data spread across the vault, from say a single place, notes are easy to manage, because of their frontmatter. But when it comes to managing a particular data-entity within notes, the best and universal method followed is giving the data an ID. We are aware of the concept of block-id in Obsidian. But again, inline-tasks are sometimes a single line. Also, in Tasks plugin we have the concept of giving each task an ID.

The problem I am trying to solve and I want all of your opinion is as follows :

I never create a task-note directly. I always convert an inline-task into a task-note. A lot of times I am in a situation wherein, I don’t feel like converting this particular inline-task into a task-note.

(My usual criteria is like, if its a recurring task, or some big task which is going to stay for a while and I have to add comments and all on this task, then I convert it into a task-note)

So, when I leave a inline-task as it is…
And if its inside my usual notes and not a dedicated note for adding inline-tasks…
And I am adding a lot of properties to it…
The this inline-task is getting bloated.
To fix this problem I have implemented a feature where I can hide a selective property in Live Editor and in Reading mode.

But the real question is, only because we can hide the properties it doesn’t mean will keep adding more and more metadata to it. So, I have this new idea where each inline-task will have a unique ID on them. Now, only important properties can be written inside this inline-task. Properties like :

  • Scheduled date
  • Due date
  • Priority

But, other properties which are not so important but can be useful later and we want to store it. These properties can be stored inside a separate inline-tasks-metadata file/database for each of these inline-tasks since they have a ID on them now and its easy to find them. Properties like :

  • Reminders
  • Created date
  • Blocked-by
  • Blocking
  • Map position data
  • And custom properties using Dataview format…

Which design do you guys think will be a good design for Obsidian :

  1. We have Obsidian features like rendering virtual information inside Live Editing mode and Reading Mode. So, even if the properties are not written inside the note for the inline-tasks they can be still viewed by fetching them from the database.

Or

  1. Store the metadata within the inline-tasks itself, but it can be hidden using the property hiding feature.
2

My solution to the problem you are trying to solve is to create task notes directly and let go of inline tasks.

I am trying out TaskNotes as my full GTD task management tool, coming from heavy use of the Tasks plugin. My view is that every GTD next action/task will be a task note. Once migrated, I expect my only use (limited) of checkbox tasks will be for small checklists in a task note.

For me, a hybrid system doesn’t make sense. I want a common approach for all of my tasks to ensure queries show all of the appropriate tasks in one place. Since TaskNotes uses Bases for its views (queries), displaying inline checkbox tasks is not possible.

While it is possible, and in many cases useful, to add lots of information to a task note, I’m not stressed over the task notes that contain the minimum required information associated with the task.

The push that got me to try TaskNotes again was the release of version 4 with its robust views in Bases. My prior system used custom Tasks queries and the DayPlanner plugin to provide a set of views, but they are not as frictionless or functional as the Bases views. I am going to be customizing the views and the statuses and other setup items, but the foundation provided by TaskNotes is much closer to the views I want.

1 Like
3

Thank you for sharing your workflow. That made me realize, I might not have addressed one important question, which is, “why I don’t want to create a note for every single task I want to add inside Obsidian”.

The answer is more of a “psychological burden” of trying to figure out whether this task deserves to have a note of itself. This pressure of creating a proper hard-file, which will be sitting inside your hard-drive is a little bit concerning to me. I want to have my mind free when I am creating a task, and inline tasks are the way to go about this, for me.

You see, in other note-taking services, the notes we create are not exactly stored as files. (Now, I cant prove this since these services are closed source, and the data is in their servers). But in Obsidian the “Notes“ we create are actual “hard files”.

There are advantages as well as disadvantages of having this power we have in Obsidian. So, I dont know if we can call this an ADHD, but I dont feel like having a “hard file” file for each and every single task I am going to create. And this concern of mine is the biggest hurdle for me to create a note for every single task. (I might elaborate on the disadvantages of converting every single task into a note in a long run, once I have enough data/facts).

And secondly, I am note entirely dependent on Bases for my task management. So the approach of entirely dependent on task-note concept is out of the solution.

The problem we are trying to solve here will should account for following :

  • There will be inline-tasks for sure in our Obsidian setup.
  • These inline-tasks will be present, not only in a dedicated file, but spread across in multiple files.
  • And based on requirement, will be converting an inline-task into a task note.

Anyway, I appreciate for sharing your workflow and ideas.

4

I may not fully understand the issue, but my resolution to having arbitrary frontmatter properties in task notes not clutter up my workflow is to display a subset of properties in my task notes base view. My task notes contain up to 30 properties, and I rarely look at all of them, but they are useful for different base views.

1 Like