I’ve used OmniOutliner at work for over 10 years, and have developed an efficient workflow with it for managing work-related notes, so I’ll use this as a point of comparison. As an outliner, OmniOutliner has some fairly sophisticated features. Yes it’s an outliner, but it can do a lot more, such as embed external documents, define additional columns (e.g. data elements) perform automatic numeric-value roll-ups (for example it can can roll up time on tasks that bubbles up to a total at the top of a project), regex searching, scripting, etc. etc. My tasks fall into three categories:
- Todos (Something I need to do / make happen)
- Triggers (Something I’m waiting on; e.g. another person’s task, or an event)
- Timed event (A task with a deadline)
When I’m taking notes in a meeting and think of a todo or trigger, I put that right in the notes as an entry subordinate to the current note, which is usually a topic of the current meeting I’m in. Thus these items are dispersed throughout the notes because they were entered as I thought of them, wherever I was in the notes at the time. OmniOutliner can have defined filters, so I have one that finds all triggers and todos, and I get a custom view of the note tree, with the leaf nodes being triggers / todos, and the context of each one can be easily seen by following up the branch. So for example if I had the following in my notes:
todo: Get Sandy the backup report
I can see via the parent note that it was in the context of a discussion about the new backup system, and that note’s parent is the staff meeting. Thus the structure of the notes provides the context. Timed events are in a separate section and sorted by due date.
I don’t use OmniOutliner personally because the license belongs to work, and I have my own ways of doing personal note-taking that predate OmniOutliner. But the OP’s question got me to thinking about how I would handle todos / triggers / timed events in Obsidian.
As an aside, I used to use Tinderbox to manage my tasks. If you’re not familiar with Tinderbox, it’s mind-boggling in capability. I was able to design a “radar scope” for my tasks. Really, it looked like a radar scope with a reticle. The axes represented time, with the origin at the center of the scope being “Now”. Thus the further out on the scope a task sat, the further out the deadline. Tasks were tagged with a category so that similar tasks (for example, all open tasks for a particular project) would be clustered together on a similar vector heading toward the origin. If a task was overdue, it means it hit the origin and started moving outbound, changing color to red. So it’s distance from the origin now represents how much overdue. I later discovered that some company I never heard of had patented the idea. Oh well.
For Obsidian, I would probably have a separate note specifically for todos, triggers, and timed events. The reason is that I would need to reference this list frequently; the “scan rate” is fairly high, so these tasks would get a lot of attention, with me scanning the triggers at least twice a day looking for something that fired, picking “next tasks” off the todo list, and watching the items with dates. Something like this:
Triggers
- Sandy owes me that backup config
- Waiting on reply from Charlie on my sales question
Todos
- Copy the production telecom billing process to Dev
Events
- 20201212 - get the modified swimlane to Lisa
- 20201225 - Complete config illustration before holiday
Each of these entries would be an internal link, which provides the context; just hovering over the items displays the related note. This would allow the actual entry to be concise / terse but effective. Events are ordered in chronological order so it’s easy to see the next due-date(s). I’d probably have this note nailed to a corner of the screen so that I can pop over to it during a meeting and add something, then go back to my note taking. You might ask, why no checkboxes? You can certainly add them, but in my case these items are transitory and don’t reflect permanent notes, only real-time action management. So I delete them when I’m done. If it’s important for me to document that a task was done and when, I’d add that to the specific related note.
So that’s how I’d do it. It’s not sophisticated, but meets one of my design philosophies: Keep things as simple as possible, but no simpler. In the end, whatever method you choose to use has to work for you, not the other way around.