feat: add estimated time (i.e. Duration) to complete in Task

⚠️ 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.

🔖 Feature description

add estimated time to complete to any Task.

ex)

• [TODO]: find cheque book #P2 #someday ⏱ 0:15

the scope of the feature is as follows:

• add new task metadata to Task class and associated parsing
• support suggestions when typing a task in vault
• add rendering of metadata to a task line
• add to edit task modal
• add support in query lang to filter based on this new metadata

and of course, some new tests are going to need to be added ...

✔️ Solution

the current code has support for lots of task metadata such as dueDate, startDate, scheduledOn, etc.

the change required to implement additional metadata would sit next to what is already there to support these other ones and thus requires no refactoring, etc.

future refactoring wouldn't be impacted either as it doesn't add any additional burden w.r.t what it already would be to take the current pattern X to the new one Y.

❓ Alternatives

N / A

📝 Additional Context

I have already implemented this in a private fork, see the screencaps below.

The statements I made in Solution are true for at least points 1-4 of the scope I mentioned above, as this is what I already have implemented. As for point 5, I hope the statements still hold true.

Screen.Recording.2023-02-10.at.9.06.54.AM.mov

[claremacrae]

Hi @BluBloos,

add estimated time to complete to any Task.

Yes, I think this will be really popular. Thank you very much for offering to contribute it!

• [TODO]: find cheque book #P2 #someday ⏱ 0:15

the scope of the feature is as follows:

• add new task metadata to Task class and associated parsing

I've asked on Discord for opinions about the emoji choice. If you're on Discord, would you mind keeping an eye out for replies please?

• add rendering of metadata to a task line

I imagine you would do this anyway, but I suggest putting this before all the existing fields, to avoid breaking any Tasks-parsing code other plugin authors may have written.

• add to edit task modal

The video was helpful.

Re 03:1 - interesting that it's interpreted as 3:01. That's fine, but I wondered whether it would be 3:10.

I'm unsure how closely this video matches your intention for a PR, but a lot of Tasks users are not developers, so something other than a regexp for showing the allowed pattern would be good.

• add support in query lang to filter based on this new metadata

When you come to add it, you should find that having added the filter, adding sort by and group by options will be very easy. I can imagine that people will find them useful, perhaps to find short tasks to fill available time.

Other items for your consideration:

• Please check out How do I add a new field to the Task class? which lists the current known steps to add storage of new fields to Tasks.
• Please write at least a first draft of the documentation. It doesn't need to be word-perfect, and it can have ad-hoc screenshots, but it should try to describe all the user-visible behaviours.
• I imagine that this might be merged before feat: New CSS classes for "themeability" #1519 - but @esm7 please note a potential incoming new field, for later considering in the styling...

future refactoring wouldn't be impacted either as it doesn't add any additional burden w.r.t what it already would be to take the current pattern X to the new one Y.

I don't think I understand that sentence...

[claremacrae]

I just remembered: it would be helpful to add it to the show/hide instructions too.
It’s also fine to split some of these thing over multiple PRs if you wish.

I've asked on Discord for opinions about the emoji choice. If you're on Discord, would you mind keeping an eye out for replies please?

I am on Discord, I'll keep an eye out!

I imagine you would do this anyway, but I suggest putting this before all the existing fields, to avoid breaking any Tasks-parsing code other plugin authors may have written.

I actually didn't think of this! Although, I am confused about this. What specifically are the other plugins parsing, is it the .md source?

I'm unsure how closely this video matches your intention for a PR, but a lot of Tasks users are not developers, so something other than a regexp for showing the allowed pattern would be good.

haha yes, certainly some cleanup will be needed on this front ... the video was very much "I have it at least working but there is still work to do".

Re 03:1 - interesting that it's interpreted as 3:01. That's fine, but I wondered whether it would be 3:10.

Good point! I think the interpretation of 3:10 is more consistent. Seems like the rule here is that there shall never be anything implicit between a digit and :. So for example, 3:01 should never be interpreted as 30:01.

---

As for the statement I made on X -> Y it was kind of like so:

for Idx : 0..3
  do_A()
  do_B()
  do_C()

the above pattern is snippet X.

we could do a refactor (albeit a terrible? one) to some pattern Y:

do_A()
do_B()
do_C()
do_A()
do_B()
do_C()
do_A()
do_B()
do_C()

my planned PR is going to make some sort of change to X like so:

for Idx : 0..3
  do_A()
  do_B()
  do_C()
  also_do_D()

and so we can see that the refactor to Y should hopefully be minimally impacted.

Re 03:1 - interesting that it's interpreted as 3:01. That's fine, but I wondered whether it would be 3:10.

An alternative is to use a format such as (hours)h(minutes)m.

so ex) 10h30m, 10h, 30m, 10h3m

this way there should be no ambiguity, and in some cases the time spec can be terser

[claremacrae]

I've asked on Discord for opinions about the emoji choice. If you're on Discord, would you mind keeping an eye out for replies please?

I am on Discord, I'll keep an eye out!

Thank you.

I imagine you would do this anyway, but I suggest putting this before all the existing fields, to avoid breaking any Tasks-parsing code other plugin authors may have written.

I actually didn't think of this! Although, I am confused about this. What specifically are the other plugins parsing, is it the .md source?

Various plugin authors have implemented various bits of interoperability with subsets of features of various other plugins.

It's complicated.

Re 03:1 - interesting that it's interpreted as 3:01. That's fine, but I wondered whether it would be 3:10.

Good point! I think the interpretation of 3:10 is more consistent. Seems like the rule here is that there shall never be anything implicit between a digit and :. So for example, 3:01 should never be interpreted as 30:01.

I think that's good. As much as possible I would like the mark-down to be unambiguous, and any flexibility being in the auto-suggest and/or Edit modals.

As for the statement I made on X -> Y it was kind of like so:

for Idx : 0..3
  do_A()
  do_B()
  do_C()

the above pattern is snippet X.

we could do a refactor (albeit a terrible? one) to some pattern Y:

do_A()
do_B()
do_C()
do_A()
do_B()
do_C()
do_A()
do_B()
do_C()

my planned PR is going to make some sort of change to X like so:

for Idx : 0..3
  do_A()
  do_B()
  do_C()
  also_do_D()

and so we can see that the refactor to Y should hopefully be minimally impacted.

I still don't understand, so let me be a bit more specific about the kind of impact I am concerned about.

Now

Currently, the only documented bits of Tasks are the things in the user manual, like the filters and the modals.

Refactoring to me means 'no observable changes for users to the documented behaviours'.

(I am aware of Hyrum's law, but I'm also working on a volunteer basis, and I chose to favour making the current code more maintainable over maintaining backwards compatibility for users who have found ways to access unpublished bits of Tasks code)

This means I am free to rename classes and methods, divide up classes, move implementation details from one bit of code to another...

Post-API

As soon as we start documenting calling of code in Tasks, my other mode kicks in. I will try very hard to avoid breaking changes in documented facilities.

And that is what I mean by an API preventing future refactoring.

[claremacrae]

Re 03:1 - interesting that it's interpreted as 3:01. That's fine, but I wondered whether it would be 3:10.

An alternative is to use a format such as (hours)h(minutes)m.

so ex) 10h30m, 10h, 30m, 10h3m

this way there should be no ambiguity, and in some cases the time spec can be terser

I guess it would be good to find out if any other task-related Obsidian plugins provide tracking of required time, and try to be consistent...

[Prometheus720]

An alternative to this that would interest me would be a 🍅Pomodoro field. I don't really want to type in how many minutes I think something will take. I want to think about how many Pomodoros it will take, which is easier to type in as a simple 1 digit integer (maybe 2 for incredibly long tasks).

Perhaps the true problem here is that it is not easy for users or even contributors to add additional fields to the Tasks plugin.

[claremacrae]

Perhaps the true problem here is that it is not easy for users or even contributors to add additional fields to the Tasks plugin.

interesting observation and probably fair.

One of my focuses, since taking over responsibility for Tasks last year, has been to make the searching, sorting and grouping code easier to develop and extend. There has been a lot of progress.

One that work is done, I may well turn to the code for adding fields.

[Cito]

An alternative to this that would interest me would be a 🍅Pomodoro field.

Maybe both could be allowed, e.g. 30m = 30 minutes, 1h = 1 hour, 4p = 4 Pomodoros?

Optionally, could even be displayed as 🍅🍅🍅 = 3 Pomodoros or ⌛⌛=2 hours. This would nicely emphasize the heavyweights in task lists.

I agree that some support for estimated time would be nice to have. According to GTD doctrine, the time to complete a task and the energy needed to complete a task are the crucial factors when choosing next actions, while priority (urgency) does not play a big role and is only considered after context, time and energy have been checked. Often you have only a limited left before a meeting, or you are tired after lunch, in which case you can't tackle time consuming or difficult tasks. So this makes sense. You can also consider time and energy as part of the context in which you do the task.

Currently, I'm just using two tags #quick and #chore. The quick tasks are those under 15 minutes, the chore tasks those that I can even do when a bit sleepy or unmotivated. All tasks that do not have these tags are longer or require more energy. For this, no additional support from the plugin is necessary. Though it would be nice to have them as checkboxes in the edit dialog. For the more fine-grained time and energy fields, sliders would be a suitable kind of UI element.

I love all the discussion and glad to see that estimated time is something that more than just I desire :)

(as a contributor that gives me motivation)

I certainly agree that both time formats should be allowed (i.e. let 1p, 2p, etc be a thing).

[wc8]

I'm currently using a dataview field for this, and using it to calculate estimated time to finish groups of tasks. I'm not on discord, but I rather like the styling of ⏱️ and 🍅, but maybe it makes sense to only use one.
Previous to obsidian, I used ⌛ for estimated duration— the scheduled date emoji throws me (but I'm glad for the feature).
Maybe worth considering whether actual vs. estimated would be a future thing.

[wc8]

Stumbled across downside of dataview fields for this... no short mode.

+1 for this feature. I suffer pretty heavily from over scheduling my days and forcing myself to add "estimated times" for my tasks would be great. I think it would then be realistic to eventually parse the data so that I'm not scheduling more than a certain number of hours in any given day.

In addition, it would be nice to be able to indicate the ACTUAL time the tasks took. If there was a way to indicate the start time of the task, then upon checking off the tasks it adds a completionTime property alongside the meta data for estimated time. In an ideal world, I'd love to be able to let Tasks know that I'm starting a task, let them know when I've paused or finished, then have it calculate based on those times the actual time it took to complete the task, but even just being able to manually enter the time that it took would be incredibly helpful and provide a LOT of useful data!

For the styling, either a different type/color of clock could be used or graphics for completion. A couple examples: ⏲️ ⌚ 🏁 ☑️ ⏰

[claremacrae]

Hi @DrakeShad - for project-planning to be feasible and practical on a project with such a large number of requests, it’s important to keep each issue focused on a single topic.

This issue is about storing estimated time needed to complete a task.

You are describing time tracking which seems to me to clearly be a different topic.

As such, your comments here won’t ever get seen for planning or action.

Feel free to check whether there are existing requests for time tracking and up-vote them. And if not, to instead start a new request.