Adding time boxing (tracking and estimate) capabilities to obsidian-tasks

[mathisgauthey]

⚠️ Please check that this feature request hasn't been suggested before.

• I searched previous Ideas in Discussions didn't find any similar feature requests.
• I searched previous Issues didn't find any similar feature requests.
• I am only requesting a single feature. Multiple changes should be split into individual requests, with links between them.
• I believe my requested feature will be generally applicable to other users, not just me: it is not uniquely tied to my personal workflow.

🔖 Feature description

Feature scope :

• Add a time estimate to tasks
• Add a time spent on tasks
• Track time spent on task directly within Obsidian
• Add query for tasks based on time estimate and time spent, examples :
  • Total time estimated for task that happens/due/scheduled/start on DATE
  • Total time spent on task done on DATE
  • Tasks with or without estimated/tracked time
  • Tasks that have an estimated/tracked time of x or less/more

✔️ Solution

✅ Add New Tasks metadata(s)

First, we'd need to add new task metadatas for time.

Either only one that gets the tracked time and estimated time :

• [STATUS] DESCRIPTION ⏱️ [ (_h) _m / (_h) _m] 🔁RECURSION ➕ CREATED_DATE 📅 DUE_DATE ⏳ SCHEDULED_DATE 🛫 START_DATE

Or in the form of two new metadatas :

• [STATUS] DESCRIPTION ⏱️ (_h) _m 🧮 (_h) _m 🔁RECURSION ➕ CREATED_DATE 📅 DUE_DATE ⏳ SCHEDULED_DATE 🛫 START_DATE

The time format would be like that : (_h) _m → x hours x min

Examples :

• 25m
• 1h 10m
• 6h 30m

It would be simple enough to write without using the obsidian-task dialog, and yet simple enough to calculate from this simple timestamp.

❓ Questions are :

• Should we always add them to tasks like the CREATED_DATE, make it customisable in settings, or add one/both only when a time tracked/estimate is added via the dialog box ?
• How to handle recurring tasks ? I'd suggest resetting time tracked but keeping time estimate.

✅ Update the Current Dialog Box

In FR #1649, there's this way of handling things :

I'd personally go more for something like that, using a simpler time format :

We would type in the time spent/estimate in the correct format, or use the wheel to easily input the time estimate. The inspiration is entirely from Super Productivity which is an amazing piece of software but lacks the note capabilities of Obsidian for managing references materials of tasks and projects.

✅ Add Time Tracking Capabilities to Obsidian

1. Clicking on the watch emoji would trigger a timer that would go right into the bottom bar of Obsidian : ⏱️ (_h) _m.
2. It would store the click timestamp, add the already tracked time if existing, and calculate from here, showing the tracked time in the (_h) _m format in the bottom bar but using a more precise timestamp in ISO format to calculate from.
3. It would keep track or the task filename and description to be able to come back to it and modify it.
4. When the user end it by clicking in the bottom bar, it would then add the rounded time spent to the time spend metadata or create it if it doesn't yet exist.

❓ Question is : How should we manage :

• Obsidian being closed during a timer. → Ask user if they really want to close it ? Edit task and sync before closing (if possible ?) ? Do nothing ?
• Storing the timestamp for calculation in obsidian-tasks settings ? Inside the task ?
• File moved or title edited during calculation, how to adapt like obsidian linking adapt ? Just stop the timer and show an error wouldn't be enough.
• What do we do if we start a timer on a machine and go on another one ? Should we be able to see it going still, and turn it off ? Meaning there would be only one timer at a time in a certain emplacement on obsidian-tasks plugin config ?

✅ Add New Queries

Maybe just starting with simple queries to show time estimate for DATE and/or time spent on done task on DATE would be enough first.

Then adding the other one featured in the feature description above.

❓ Alternatives

N/A

📝 Additional Context

• I got largely inspired by the amazing and simple way that Super Productivity deals with time boxing :
  Each task has a time estimate in (_h) _m. It allows us to see the estimated working time of the day and compare it to our agenda. And we can review our working time at the end of the day to learn to better estimate our capabilities.

• There's been a feature request for time tracking only based on status (Feature Request: Time tracking #179), but it lacked the execution and where to store the timestamp.

• There's a feature request for adding a time estimate to tasks, it has quite the same idea as I have, and some Super Productivity users got lost here as well it seems (feat: add estimated time to complete in Task #1649). I just do think that both features need to be worked on at the same time to use the same formatting and such, that's why I created this FR. I just hope I'll be able to get people opinion about how to better add such functionalities.

• I see that there is already a ObsidianSimpleTimeTracker plugin, we might be able to take advantage of how he handled the timestamp. That could allow us to start a timer on a machine and continue it on another one.

• I hope for this FR to be able to gather information about how to technically implement these features (that's why I left some questioning here and there with the ❓ emoji).

• I hope it could help focus on how to add the two other linked FR that supplements each others.

• I don't have any dev experience yet, but I'd be glad to play around this feature and try to implement it if someone wants to lend a hand.

[claremacrae]

Hi @mathisgauthey - Thank you for the time and effort you have clearly put in to this.

From an initial read, one thing that it would be helpful for you to think through, please, and add to the notes above, is how you envisage it working when a recurring task has these new fields on them. What should the values of these new fields be, be on the next recurring task?

[claremacrae]

Also, keep in mind the emoji used for reminders in #1925... which I will complete and merge at some point.

I think that what you have in your screenshots is different, but it would be good to check.

[mathisgauthey]

Hi @mathisgauthey - Thank you for the time and effort you have clearly put in to this.

From an initial read, one thing that it would be helpful for you to think through, please, and add to the notes above, is how you envisage it working when a recurring task has these new fields on them. What should the values of these new fields be, be on the next recurring task?

Hey there, you're right, I'll need to think about it clearly. And I also just thought about obsidian sync. How to manage starting a timer on a machine and changing to another one for instance. Should it sync ? Should it not ? How to do it ? These are important questions as well.

Also, keep in mind the emoji used for reminders in #1925... which I will complete and merge at some point.

I think that what you have in your screenshots is different, but it would be good to check.

Yup, I gave it a look and that's why I used the clock watch instead o/

[claremacrae]

Should it sync ? Should it not ? How to do it ? These are important questions as well.

Good point.

I'm not expecting every single last detail to be nailed down... It's more "whilst you have your thinking hat on, and this is all fresh in your mind, let's capture what you can...."

[mathisgauthey]

Just adding something for future me : Questions to ask about how to handle time tracking without writing every seconds

[claremacrae]

I would prefer Tasks not to be writing to IndexedDb.

From what I understand, doing so has caused reliability problems on Dataview.

[mathisgauthey]

I would prefer Tasks not to be writing to IndexedDb.

From what I understand, doing so has caused reliability problems on Dataview.

Oh, my point was more to remember about not using something that writes down to the disk every second but using some timer (1, 2 or 5min) and using actions such as obsidian closing or something to update the current timer time 👍

[claremacrae]

User eatgrass on Discord is writing a tracking plugin - discussed in Discord.

Assuming it has some overlap with this request, I would personally much prefer to support that, than to have it implemented in tasks, so each plugin can focus on their core purpose, and to share the maintenance effort too.

I have suggested that we have a chat with them to discuss collaborating.

[mathisgauthey]

User eatgrass on Discord is writing a tracking plugin - discussed in Discord.

Assuming it has some overlap with this request, I would personally much prefer to support that, than to have it implemented in tasks, so each plugin can focus on their core purpose, and to share the maintenance effort too.

I have suggested that we have a chat with them to discuss collaborating.

I do completely agree about it, if tasks can stay focused on what he is doing (helping organizing tasks) and another plugin could "simply" add features such as time tracking while working well with tasks, I'm all for it 💪

Looking forward to discuss it then.

[eatgrass]

Hi @claremacrae and @mathisgauthey,

I feel excited to discuss the task-tracking feature. Currently, I'm developing a timer plugin aiming to help those who use the Pomodoro technique. My focus has been on creating a Pomodoro timer that can generate logs, these logs are then can be aggregated using dataview for basic time tracking.

To enhance user experience, I'm looking for a way to initiate the timer directly from tasks and add task-related information to the log.

the plugin here: Obsidian Pomodoro Timer.

I would greatly appreciate your thoughts and feedback.

[ivan-lednev]

@claremacrae, ironically, I've also written a time tracking feature in the day-planner plugin 😄

I haven't released it yet, since there are a few rough edges to address, but it's already functional. Looks something like this:

[claremacrae]

In view of this size of the backlog for this project, and the demotivating effect of a very long backlog on volunteer energy levels, I'm going through a slow process of reviewing tasks for things that are one or more of the following:

• unlikely to be realistically achievable, from the design of the current code, and the planned future refactorings
• not sufficiently high priority to a broad community of users, based on the feedback I receive from a variety of sources
• do not fit the core purpose of the Tasks plugin
• are better covered by a different plugin - to share the development and maintenance effort

So I'm marking this one as 'not planned'. This doesn't mean 'won't fix' - it means not likely to be done in the foreseeable future.