dwyl / app

Clear your mind. Organise your life. Ignore distractions. Focus on what matters.
http://dwyl.github.io/app/
143 stars 22 forks source link

Feat: Edit Timer `start` or `stop` time to adjust duration #282

Open nelsonic opened 1 year ago

nelsonic commented 1 year ago

In the first instance our app needs to be useful for the individual using it. i.e. "single player mode".

Story

As a person tracking time spent on items on my task list, ✅ I want the ability to edit the timer.start or timer.stop value 📝 So that my timers accurately reflect the actual time spent on a task.👌

Reasoning

I might forget to start the timer, so I didn't time the task at all. or neglect to stop a timer a so it ends up clocking up way more time than it actually took, both of these scenarios are undesirable and might put the person off using the App/Tool.

Analysis

From the perspective of the backend/API this is a trivial feature to implement as it's just updating the value in a row/record i.e. T25m with tests and docs. But from the perspective of the front-end/UX it's a lot more nuanced.

UX/UI?

Will the input be a numeric field where the person can manually input date and time values. Or will it be a picker that facilitates input? in which case what is the desired UI/UX?

e.g. would we have a date picker: https://flowbite.com/docs/plugins/datepicker/

image

Coupled with a timepicker: https://tailwind-elements.com/docs/standard/forms/timepicker/

image

Open Questions

Do we want all timers to be editable? 💭 How far back should people be able to edit their timer? e.g. should we limit it to recent? Should we record the original start and stop for audit trail purposes?

nelsonic commented 1 year ago

Forgot at timer running before I went on "holiday":

image

really want fix this problem as I feel it greatly diminishes the usefulness of the MVP. 💭

iteles commented 1 year ago

YES. I need to add my vote to this because the app is becoming practically unusable to me because of the lack of this feature 🤦‍♀️

I'm constantly being interrupted and consequently have timers on for far too long.

If this was just a task list, that would be different, but having lots of timers that are HOURS long when it was a 20 minute task is just annoying. Or even worse, when I have used the timer multiple times as I have made progress on a task in fits and starts so it's all lovely and accurate and then that is wasted by the one time I forget to switch the timer off.

I then just get super frustrated with this and mark the task as done, opening a duplicate that no longer accounts for the time already spent on it because I don't want to see a 14 hour timer in my task list 😅

image
nelsonic commented 1 year ago

@iteles thanks for the feedback! 🙏 🎉 If you glance over the backlog, besides having distinct lists to separate items and being able to share them, how would you prioritise the work that needs to be done by the team? Would you say this feature is next? 💭 [ @SimonLab made a good summary of what we have planned in: https://github.com/dwyl/mvp/issues/179 ...]

iteles commented 1 year ago

To answer your question @nelsonic I think that https://github.com/dwyl/mvp/issues/145 is the feature that would be 'the most bang for our buck' as it goes some way to resolving #221 and #292 already.

We could then move to lists https://github.com/dwyl/mvp/issues/179 followed by this feature in the OP.

nelsonic commented 1 year ago

On the basis that editing timer.start and timer.stop is purely UI/UX (updating the LiveView and adding a couple of tests+functions on the backend) and requires zero schema/db updates. I feel that this could be a "Quick Win" in the MVP that @LuchoTurtle can pick off in an afternoon now that he's up-to-speed on his Mac https://github.com/dwyl/mvp/issues/190 as such I've sketched super basic UI in: https://github.com/dwyl/mvp/issues/195

image

That way we can test the edit timer feature this week. 🤞