As I made public in My Every Minute With Obsidian, I tend to track my day-to-day activities in gross detail in my so-called timeline.
However, I couldn't do this with an off-the-shelf solution. Instead, it's a system I've iterated upon for the better part of two years.
There are few like it, and I am its steward. I've mastered it as it's my life. My timeline, without me, is useless. Without my timeline, I'd have more time in a day, but what about in a year?
So, if, like me, you're looking to track 9 out of every 10 minutes in your day, read along my journey, and you'll see how I do it.
Before getting to the implementation, you need to understand the underlying considerations behind it.
- Note: a markdown file.
- Wikilink: a link to a note.
- Workflow: a set of actions I intend to track (i.e., to Write, Program, etc.) saved as a note.
- Activity: a slice of time dedicated to a workflow with notes & additional data attached.
- Daily Note: a note comprising all activities for a given day.
The Source of Truth
First and foremost, I need a place to save my timeline. It would be nice to store it in a database and display it with fancy graphics, but that's easier said than done.
Instead, I've found success in the modern features of digital notebooks. The functionality to search, define metadata, organize, and link between notes provides a base to start a timeline.
For the foreseeable future, my data will remain in a markdown-based editor.
The Components of Tracking
At its core, my implementation has three functions required to track an activity:
- Load the timeline's state
- Associate data with an activity (i.e., notes, type, etc.)
- Save an activity as markdown to that day's note
On top of Obsidian, I make use of several plugins:
Daily Notes (built-in)
Provides painless daily note creation and navigation.
At an additional cost, it syncs your notes between devices.
A bandaid for Templater's poor mobile support.
Creates a simple calendar UI for navigating daily notes.
A text completion engine that makes it easy to input wikilinks.
Allows for making stylish links, which I use to distinguish between types of notes.
Allows a second row on the toolbar on mobile
You need at least one device that runs ObsidianMD. In my experience, I have not had compatibility issues. However, I only use a laptop running Linux and an iPhone.
A clock in and out system has merits, but I've found a stopwatch provides better flexibility.
With a stopwatch, I can track an activity almost like clocking in/out, or pause the timer when not-so-relevant tasks appear amid an activity.
Plus, I can start an activity from anywhere as long as I have my watch.
An Initial Data Schema
Since markdown isn't a computer-readable format, we must implement a consistent structure to our data. For metadata, we'll use the widely supported YAML format. However, for the timeline activities, YAML isn't the right fit.
Instead, I use a personalized format composed of two activity states. The first represents an activity not yet concluded, where I'll link some data, and the latter is a completed one.
- #I ==00:00==-==00:00== (⏳ [[Writing]]) (📚 ) ^id-4 - :PROPERTIES: - :BEGAN: #BEG - :ENDED: #END - ==08:50== - #👍 ==08:45==-==08:51== (⏳ [[Writing]]) (📚 <Link to content>) ^id-4 - :PROPERTIES: - :BEGAN: 1694353529 - :ENDED: 1694353889 - ==08:50== <Notes here>
Here's a break down on the activity components:
Defines an Obsidian tag based on how the activity went. It could've been normal (👍), unusual (〽️), frustrating (🤬), amazing (⭐), or whatever.
A human-readable format showing a completed activities timeframe.
Defines a generic format for activity metadata. For instance,
(⏳ Writting)represents the workflow, and
(📚 <Link to content>) references some content I'm writing.
An Obsidian reference to this activity based on its ID. It's also used as an anchor for enhanced wiki linking.
An antiquated metadata format. It's only used to define the ":BEGAN:" and ":ENDED:" timestamps. These respectively represent the beginning and end of an activity.
They each start with a placeholder tag and transition to a Unix timestamp upon completion.
- =08:50= <Notes>
A section dedicated to notes. I'll usually create sub-bullets for more complex activities.
However, in code, the format is defined by configurable regular expressions. So, if you're comfortable with regex, I recommend trying a format of your own.
Tracking An Activity
Before anything, the script parses the current state of the daily note. If all activities are completed, it'll prompt to select a workflow and appends a new activity to the bottom of the daily note. However, if your last activity isn't yet completed with a duration, it'll prompt for one.
So, in practice, it's a four-step process:
- Start your stopwatch and wait
- Trigger the command and select a relevant workflow
- Add your notes and metadata
- Trigger the command and define the duration from your stopwatch
Issues In My Experience
As you may have suspected, this system isn't designed to track simultaneous activities. However, this is a feature, not a bug.
I could create some complicated system, but instead I simplify and force myself to focus on one thing. Of course, I exercise tolerance when relevant (usually podcasts) and will break from my focus when necessary, but I keep it brief.
Due to the nature of offline editors, you will have conflicts merging notes from multiple devices.
From my experience (and other reports), Obsidian Sync handles issues the best; however, expect issues when quickly switching devices quickly (or after losing internet). My systems aren't responsible for a poor merge, so they're handled manually.
This implementation isn't precise, but it's usable. There's a balance to strike, so I expect each activity (plus notes) to be accurate +/- 30s. In other words, I round each duration to the nearest minute.
A more accurate approach may be the aforementioned clock-in/out method, but that's not for me.
My implementation is complex, so if you're interested, I suggest starting slow. I began with a simple bullet list and a timestamp command.
I plan to share my templates/code with the community; however, they are not in a state for public release. I expect to release them on my Github by 2023-09-24.
Thank you, @Duifkruid, for encouraging me to release this article promptly.
And, of course, I appreciate the time of my crazy or curious readers. I hardly even know why I do this, so it's hard to imagine somebody else doing so.