Add display feature on tasks to show days to due date, or days since due date

lvillap commented 1 year ago

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

[X] I searched previous Ideas in Discussions didn't find any similar feature requests.
[X] I searched previous Issues didn't find any similar feature requests.
[X] I am only requesting a single feature. Multiple changes should be split into individual requests, with links between them.
[X] 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

I think it would be useful to include two calculated fields: time to due and delayed time. These fields could be very useful to be able to visually watch the most pressing tasks.

I know this is equivalent to sorting or grouping by due date, but I think visually is a lot easier to manage when a list has a lot of tasks, as the user would not need to do any calculations.

✔️ Solution

When showing the tasks (except in short mode), a new field would show, something like:

[ ] My task (2 days to due) [ ] My other task (2 days delayed)

❓ Alternatives

No response

📝 Additional Context

No response

claremacrae commented 1 year ago

Thanks for the suggestion, but I don’t understand what you mean.

Please could you give some concrete example of how it would behave, what you would use it for, and what the complete tasks would look like.

Many thanks.

lvillap commented 1 year ago

Sorry, my english is not very good and I struggle to be clear :S

Now, as explained in the Layout section of queries (in the documentation), we can show:

edit button backlink ...

So, an example of a visualization of our tasks could be:

[ ] My first task +2023-07-31 [icon due] 202-08-07 [ ] My second task +2023-07-31 [icon due] 202-08-28 [ ] My third task +2023-07-31 [icon due] 202-08-29

what I propose is to add two keys more: delayed time and time to due, so if shown, the tasks would visualize as follows: [ ] My first task +2023-07-31 (10 days delayed) [ ] My second task +2023-07-31 (due in 1 day) [ ] My third task +2023-07-31 (due in 12 days)

I think it is a lot faster for the eye to try and have the perspective of how much delay or anticipation the tasks have.

I hope I've explained the issue better now :S

claremacrae commented 1 year ago

Thanks for the extra information. Sorry but I am still missing something.

In the follow, what does the ‘+’ mean?

[ ] My first task +2023-07-31 (10 days delayed)

claremacrae commented 1 year ago

I don’t understood where the dates calculations come from in the visualisation example. I can’t see how the numbers work at all.

lvillap commented 1 year ago

The idea would be:

If a task has a due date that is after today (for example, today is august 17th and due date is august 19th) the task would be shown as follows: [ ] My task (due in 2 days)
If a task has a due date that is before today (for example, today is august 17th and due date is august 14th) the task would be shown as follows: [ ] My task (3 days delayed)

The rest of dates I put in the previous examples, where only the standard dates (creation dates, etc), they're of no relevance.

claremacrae commented 1 year ago

Ok thank you, that is clear. And presumably if the task is due today, it would show nothing.

How would it work if somebody used Start date instead of Due date?

And also, how would it work if a task had a Start date and a Due date, and if the start date was before the Due date?

lvillap commented 1 year ago

Great! Sorry I was not clear before.

If the task is due today it could show "(due today)"

In the cases you specify (using start date) I see two solutions:

Ignore start date in any scenario (as its main use it to make tasks not appear until some date)
Show "(started x days ago)" is due date is not specified, but ignore it due date is set (only show the due date text).

I hope it is useful

claremacrae commented 1 year ago

Hi, thanks for the suggestions.

The thing is, different people use the Start, Scheduled and Due dates in different ways. So some might want 'overdue' to be calculated from Due, and some from Start or Scheduled...

I worry it is going to be very difficult to make a solution here that is widely useful.

lvillap commented 1 year ago

how about the labels are calculated and can be hidden via layout (https://publish.obsidian.md/tasks/Queries/Layout) adding:

hide pretty print due date
hide pretty print scheduled
hide pretty print start date

would it be acceptable?

claremacrae commented 1 year ago

Hi @lvillap,

Thanks. Now I think that this is an understandable feature.

A small change, but I would have the display turned off by default, and then people who wanted it would say:

show pretty print due date
show pretty print scheduled date
show pretty print start date

Realistically, I'm afraid this is not going to be a very high priority thing to work on, as there is such as very high number of existing, popular requests on Tasks.

However, I will leave it open to allow it to be voted on.

claremacrae commented 1 year ago

Some thoughts if anyone considers implemetning this:

We should review the instructions names to use, for example, considering if we can find something more specific than 'pretty print' - 'relative date' might be another option
There will likely be a mechanism soon to group by moment.js' fromNow(). We should then review if this is still considered worthwhile.
It's not just adding the text, it's styling it as well, to look visually appealing

petertadrous commented 1 year ago

Hi, I've taken a go at implementing this as "relative X date" where there is an additional task option for every date present in the tasks object. So that it is possible to write:

```tasks
not done
hide due date
hide scheduled date
show relative due date
show relative scheduled date

This has led to a lot of duplication of code in several places. Additionally, it makes querying relative dates more verbose as one must hide the absolute dates as well as showing the relative dates.

So now I'm thinking there may be a cleaner way to implement this more generally. If instead there was a `date format option` in the query or a `Query Date Format` in the settings, then users could customize the format of all dates appearing in the query results.

i.e., the following syntax, and the existing format of `'YYYY-MM-DD'` would be the implicit default

not done
show due date
show scheduled date
date format 'MM-DD'


And either a date format string could be passed or the keyword `relative` for the functionality requested in this issue.

not done
show due date
show scheduled date
date format relative



What are your thoughts on this approach?

claremacrae commented 1 year ago

Hi @petertadrous,

I’m on a small screen at the moment and have read your message multiple times and still don’t feel I really understand it.

Regarding ending up with repetitious code, one of my specialities is refactoring code to remove duplication. So as long as code has unit tests, I can easily refactor it to move duplication.

So I would not regard duplication in one person’s implementation of something as a reason to give up and switch to a different approach.

I am also not seeing why the proposed approach would make querying more complex.

I believe that there are requests elsewhere for allowing date formats to be customised in different areas of the plugin.

claremacrae commented 1 year ago

@petertadrous Thanks, also, for giving it a go. It’s very much appreciated.

Is there any chance you could push your code to a branch on your fork of Tasks please? If you are comfortable doing so, it might give me a better idea of what you had in mind. Thanks.

petertadrous commented 1 year ago

@claremacrae I haven't yet gotten around to adding/updating the unit tests -- just tried to commit locally now and the pre-commit hooks failed, likely because of the failed tests...

I pushed with --no-verify for now to a branch called feat/temp/issue-2222. In short, I borrow the "days overdue" computations from the urgency calculation. And duplicate the task date getter methods for relative dates.

With this implementation, it is possible to have something like the following:

```tasks
not done
show due date
show relative due date



Which shows the due date twice, once absolute and once relative. In my earlier response, I was proposing discarding my current implementation in favor of incorporating the "relative dates" as a format option of a TaskDate object, as opposed to being it's own Task attribute. This would:

- disallow showing the same date in two different formats
- eliminate the need to maintain 2 copies of task attribute code for each date attribute
- allow for simpler expansion beyond relative dates, ie different string based date formats
- allow for formatting all date attributes with one query option, ie `date format relative` or `date format 'mm-dd-YYYY'`

I couldn't find another issue about allowing date formats to be customized in different areas of the plugin, but I can direct my efforts there if this proposed solution is accepted.

Lastly, I'm very happy to help! I've only just started using obsidian and the community's hard work on plugins like this one has been steadily replacing many different tools in my workflow (including now my todo-list app!)

claremacrae commented 1 year ago

Excellent - thank you @petertadrous. Note to self: Here's the link to the diffs: https://github.com/obsidian-tasks-group/obsidian-tasks/compare/main...petertadrous:obsidian-tasks:feat/temp/issue-2222

claremacrae commented 1 year ago

I use the label "scope: rendering of tasks" for this area, so here are the Issues:

is:issue label:"scope: rendering of tasks"

And discussions (not all of which are labelled - there are just so many of them)

claremacrae commented 1 year ago

Hi @petertadrous,

I pushed with --no-verify for now to a branch called feat/temp/issue-2222. In short, I borrow the "days overdue" computations from the urgency calculation. And duplicate the task date getter methods for relative dates.

This really helped me to understand what you are saying - thank you very much.

In my earlier response, I was proposing discarding my current implementation in favor of incorporating the "relative dates" as a format option of a TaskDate object, as opposed to being it's own Task attribute.

Yes, I do agree that adding new method(s) on TasksDate is a good idea - better than creating new fields.

This would:

disallow showing the same date in two different formats

eliminate the need to maintain 2 copies of task attribute code for each date attribute

allow for simpler expansion beyond relative dates, ie different string based date formats

allow for formatting all date attributes with one query option, ie date format relative or date format 'mm-dd-YYYY'

That all sounds really good.

I couldn't find another issue about allowing date formats to be customized in different areas of the plugin, but I can direct my efforts there if this proposed solution is accepted.

I think a new date format instruction, that controls how dates are rendered in Tasks results block, is a great idea.

I had assumed that the relative date format one would use moment.fromNow() - but it's up to you do decide whether that has enough precision for dates a long time ago...

Lastly, I'm very happy to help! I've only just started using obsidian and the community's hard work on plugins like this one has been steadily replacing many different tools in my workflow (including now my todo-list app!)

Oh wow, thank you very much indeed. Yes, that would be very welcome.

If you haven't done so already, do have a look at the Contributing Guide - I've tried to share useful info on things like testing and writing user docs.

petertadrous commented 1 year ago

Your suggestion of moment.fromNow() looks like the way to go, especially if task times are supported in the future.

I think I should open another issue for tracking a kind of date format query option as a feature request, and link this issue as a requested format. Functionally, date format strings and relative dates are different implementations, but I think from a user perspective it would make more sense to have them abstracted to a single query option.

And thank you for putting together the contributing guide, it was very helpful in getting started, especially as I'm new to typescript and js as well

claremacrae commented 1 year ago

@petertadrous Sure that sounds good. Thanks.

obsidian-tasks-group / obsidian-tasks