Discrete inline fields for tasks and updates Daily Notes log for Dataview DQL

What I’m trying to do

The way I structure my Daily Notes:

starttime: 08:30
  - DailyNote
#### [date:: 2024-01-15]
# Log 
- [[2024-01-15 - Meeting 1]]
- Meeting 2
- [ ] EXAMPLE TASK  || [duedate:: 2024-01-15] || [priority:: 1] || [person:: me] || [project:: x] || [topic:: 1] || [type:: work] || [tags::] || [date:: 2024-01-15] || [state:: valid] || 
- [x] UPDATE EXMAPLE || [project:: y] || [topic:: 2]

## Tasks Done
WHERE done = date("2024-01-15")

# Daily Thoughts

The challenge

I am trying to work as efficiently as possible to allow me to get the most comprehensive output for the most concise inputs.

The best way i have found to do this is with Daily Notes as the epicentre for ALL (personal and work related) projects, tasks, updates etc, then filter these out using Dataview to display in other project or task dashboards using Canvas.

I originally began by not using YAML or inline fields, but just obsidian tags (#), which was really quick as i could jot down a task and add a #project and #assignee and append the task with a date to sort in Dataview by “SORT text”.

I wanted to take this to the next level and delve into the world of variables, but it is significantly more effort to fill out this (even when using a template):

  • EXAMPLE TASK || [duedate:: 2024-01-15] || [priority:: 1] || [person:: me] || [project:: x] || [topic:: ] || [type:: work] || [tags::] || [date:: 2024-01-15] || [state:: valid] ||

than what i used to do previously:

  • 2024-01-15 - EXAMPLE TASK #assignee/1/me #project/x

Obviously i have far more data available in the new structure (which means i can filter and process the data much better) but i feel like it is a lot more cumbersome and because I can have completely different tasks or updates next to eachother, it means my daily notes are more filled with inline fields than actual text, as well as my dataview tasks now being less clear.

Actual questions:

  1. Is there a better way to structure my tasks/updates to achieve what i need without the excessive inline fields (is it currently overkill)?
  2. I feel like i am making everything a task, as the TASK feature in Dataview creates discrete 1 line items, is another way i can just use bullet points for updates and display ALL meetings, tasks, updates in my project dashboards?

First post on here - thanks in advance.

At the end of the day too much information will just be that; too much information. I believe you need to find some middle ground leaving your tasks easier to read and work with.

For starters, I think some of your inline fields seems to belong to the file instead of the task itself, and if so then put them in the properties of the note instead of directly in the task. The queries will be able to lift metadata from the file also.

Some of the information can be simplified, like you don’t need to explicit name the tags inline field. Just use the tags directly. There are also various icons commonly use to denote due date, start dates, and so on… Some of them can be easily added if you’ve got the Tasks plugin installed. Similar stuff applies to the priority field.

I don’t think I would have the empty inline fields there either, which might lead to issues related to what you named various fields. But that in turn could also be a pro, as if your taxonomy for classifying tasks is so complex that you can’t remember it, then maybe it’s time to simplify and take another round on what you actually need to see in any given task.

Second to last, if you insist on having this much information in each task, you might want to look into the Modal forms plugin which was recently updated, and build yourself a dialog to enter all of your information.

Finally, if you’re using dataview for your queries, you’re allowed to use FLATTEN ... as visual to rebuild what it displays in the query result. It’ll still keep the link back functions, and possibilities to complete the task and so on, and you can use regexreplace() or similar on the task text to get rid of any inline fields or other stuff you don’t need to see all the time.

Bonus tip: Inline fields can be defined using either square brackets, [ ... ], or round brackets, ( ... ). The latter variant will hide the key from display, which can be a good thing every now and then

Bonus tip 2: If using the square brackets, you can also target both the key and/or the value for custom styling, which could be useful to enhance/hide various bits and parts.

1 Like

Amazing, thanks for all the useful info, I will investigate your suggestions. Any insight into the custom styling you mentioned as the final bonus tip?

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.