Introduce a new customisable score property, allowing any number of user-named algorithms.

[claremacrae]

Background

This builds on ideas from #1157, which proposes breaking urgency down in to urgency, importance and some other name for combining the two.

This would obviously satisfy those who think in terms of the Eisenhower method, mentioned in that idea.

However, it's limited by the number of named values that we chose to provide, and we would need a UI to allow users to customise each one.

Suggestion

What if we implemented a new property called, for example, score, for which users could supply any number of named scoring functions.

Rough sketch of possible features

Thinking aloud...

Defining the score functions

• User selects a folder in their vault, to nominate it as the location of custom scores, would which each be in a separate .js file in that folder.
• For example, my_score.js would define a function that takes info about a Task and returns its score
• Users could supply any number of such JS files
• As a bonus, we could add a 'Refresh' button in the score settings UI, to re-load the scripts and blank out any cached score values, so users could experiment without needing to keep restarting Obsidian.

Using the score functions in tasks blocks

Perhaps:

sort by score my_score
group by score my_score
show score my_score
hide score my_score
score my_score > 5.0

Or maybe we refer to it as score:my_score or something similar.

Display

The score name can be included in the CSS class, so that users can style their different score values differently.

Differences from current custom urgency proposal

If we have a fixed number of urgency-type scores, then each time the user wants to switch to a different scorer, they have to do something in their settings, and then restart obsidian.

If instead we allow them an unlimited number of named functions, they can simply modify their queries - or add new ones - to use different values.

Also, this has the advantage that we don't have to decide on fixed names for scores, as is discussed in #1157.

Another benefit is that we can leave the current urgency score unchanged, and just document that a new, more flexible alternative exists. This nicely avoids a breaking change, and all the discussion, docs and user-support load that would be then required.

[Cito]

@claremacrae Letting the user define and name any number of custom "score" or "rank" functions that can be used to filter and sort tasks according to that score is a great idea! This would make the tool immediately much more customizable and flexible.

The syntax for filters could then look like this:

<name> score is (above|below)? <number>

And for sorting:

sort by <name> score

For example, sort by urgency score. Maybe we can make the score optional, but then we need to make sure that score names do not collide with existing options.

Users could then also create score functions not only for urgency or importance, but for instance to check if a task or its heading contains certain keywords. Then these scores could be used in various views for filtering and sorting, but the check for the properties would stay centrally at one place in the score function, and you would only need to adapt the score function if keywords are added.

Btw, it should be also possible to use these score functions in other score functions. So users can create simple score functions as building blocks for more complicated ones (like a combined urgency + importance score).

[claremacrae]

Maybe we can make the score optional

Thanks for the comments.

Just for the record, I am by default strongly against designing features to make parts of the instruction optional.

Either a word provides value or it doesn't.

User-focussed reasons

Reasons include: It makes things more complicated to explain in the docs, can open up ambiguity in future features, and adds a forever-overhead to all possible re-implementations of the parsing code.

Making something that used to be mandatory optional, after realising it wasn't necessary, is a different thing, if it solves a real usability problem that has been observed after real-world usage.

But designing in optional bits from the outset: I would strongly prefer not to do so.

Maintainer-focussed reasons

Also, in a commercial body of code, I would say that user experience trumps complexity of implementation.

But in a volunteer project, PRs have a real cost:

• the initial code review and testing
• the implicit responsibility for taking on maintenance of the code forever more (or until the ode is abandoned)

Especially adding complexity to regex-based implementations is very expensive on my time as the maintainer - and all query-parsing is currently regex based, so extra flexibility in instructions has a significant overhead on my time, making less time available to implement other requested features.

[Cito]

Agree about making the score clause optional. Still the question is, do we want to make the score keyword (or however we call that clause, maybe also rank or value or something) a required part of the syntax, or leave it out (i.e. make it an error if you use it)? I.e. given there is a custom score function named importance, should this be written as sort by importance score (or maybe sort by score importance) or should the syntax just be sort by importance? In the latter case, users must be careful to not name their functions like an already existing sort option. Therefore it may be better to make the syntax more explicit and require the keyword.

[claremacrae]

Therefore it may be better to make the syntax more explicit and require the keyword.

That was my thinking.

Often I find that these things become clearer as soon as I start writing tests for them though, or perhaps when writing the documentation before implementing the feature.

[claremacrae]

A request which would be enabled by this feature:
#1257 Give sub-tasks a higher urgency

[feedhopper]

"Optional" could mean: The option is there in the dialogue but will not show up in the rendered list if not used.

This way, both completely valid points of @claremacrae and @Cito could easily be reconciled.

[claremacrae]

Hi @feedhopper sorry, I don’t understand what you are replying to.

[feedhopper]

Oh. sorry. That is due to me not quoting what I referred to. It was you saying in response to Cito:

Maybe we can make the score optional

Just for the record, I am by default strongly against designing features to make parts of the instruction optional.

What I mean is: "urgency" could not be optional as in switching on or off that feature altogether but as something I set in the dialog for the respective task. If not used, it will not show up in the listed item.

[claremacrae]

Thanks for clarifying.

What I mean is: "urgency" could not be optional as in switching on or off that feature altogether

Yes, nobody is suggesting removing the existing urgency score feature.

In case you haven't seen its documentation, it is here:
https://obsidian-tasks-group.github.io/obsidian-tasks/advanced/urgency/

but as something I set in the dialog for the respective task. If not used, it will not show up in the listed item.

Urgency isn't something one sets on a particular task. It is a value (or score) that is calculated for each task, based on things like whether the task is overdue, or high or low priority.

The challenge is that different people have different preferences as to the weight of the components in the calculation.
Hence this suggestion to provided a way for users to write their own scoring functions.

[claremacrae]

See also #2014.

[claremacrae]

I'm now experimentally working on #1479 - custom sorting.

There are other requests about making it more convenient to re-use custom filters, custom grouping - and soon custom sorting, across searches.

I feel that those facilities would be a more general thing than this request, which predated task expressions.

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.