I’d love a relation type that is a stopwatch meaning that when that relation is shown on an object screen or as a column in a set it would show a timer that you can click to start it counting up and click again to pause.
I’m terrible at time estimation so the way that I’m trying to improve is by making a (bad) guess at how long I think a task will take, then when I start that task I set a timer and stop when I’m done. That way afterwards I can compare how close my estimate was and use that info of how far under or over I was to improve my estimates in future.
I could also see such a feature being super useful for people who need to keep time sheets for their work. Right in their “Task tracker” set (or equivalent) at the same time as they pick a task to start working on they can also just click to start the timer and stop it when checking off the task.
An alternative approach for my use case would be to make the “Done” checkbox of the task type non-binary by including a third state call “doing” or “in progress” or something. Clicking the checkbox once sets it to doing and would log the start time and when you check it again then it would be marked as checked/done and time elapsed in the doing state could then be displayed somewhere, maybe as a pseudo-relation like the done checkbox already is (in that “Done” doesn’t show up as a relation but you can do things like sort sets with it in the same way you can with relations). This is how Logseq currently operates:
Or another approach could be to have a new relation type which you can configure to track how how much time another relation in that object has a specific value for. This would mean you could create a type called “Time” and set it to track how long the status relation contains the value “In progress” for. Then you could add that Time relation to the task type and when you move that task to the “In progress” kanban status column the Time field would start tracking that and then if you move it out again it would pause the timer. Maybe it could be implemented with the derived relations/formulas suggestion.
These alternatives would be more work to implement (I’m guessing) and in some ways less general purpure (and thus cover less other peoples use cases) even though I’d personally prefer it as it would involve less clicks in my use case (and thus I’m less likely to forget to start it).