a-mabe
[Feature/Improvement] Random duration work/rest intervals within an interval timer
Hi there! I've been meaning to build out support for this feature in either a standalone project, or, even better, contribute to an existing project. Would you be open to accepting a PR on this, if I wrote it?
I recognize that this is a bit larger of a change, and don't mean to just do a giant drive-by PR :) Happy to fork and do my own thing, or also tweak the idea to match your vision for your app. Let me know what you think!
Purpose: As a Muay Thai fighter, I sometimes need to train with high intensity intervals that more closely simulate a fight. This involves bursts of energy when I am attacking or my opponent is, that might be a brief second or two, or might be as long as 10 seconds. And then, I may need to immediately counter after a 1 second pause, or I might have a longer span of time to recover.
It's important to not know how long each interval is, since I need to train my brain/body not to try to taper off in anticipation of the end of an interval. It also helps me gauge my minimum amount of time to recover from a given energy expenditure.
Today, my coach will just randomly tell me to stop/go. But, I'd like to save him the trouble, as well as be able to do this training on my own.
More details:
I'd defer to the maintainers if you have any preference for UX. I also see that there is work in flight here: https://github.com/a-mabe/OpenHIIT/issues/202 which might play nicely with this.
We probably need a toggle on the 'new interval timer' view, since it asks you to pick an interval count? Which would switch it to 'total duration' rather than interval count. And then, the further configuration view would then have two fields for setting work/rest time (min/max)?
It's all a bit awkward with the current interface since it isn't easy to hop between screens to flip between fixed duration intervals versus random. The new one seems like it would lend itself well to this type of larger configuration mode change.
Another option entirely might be to add a new top level mode, but it seems like this belongs as an interval timer where it can be integrated into workouts?
Acceptance Criteria:
Required configuration:
- set a total session/exercise duration, rather than interval count
- set a minimum and maximum duration for both work and rest (separately)
- still respect warm up / cooldown time as fixed time spans before/after first/last intervals
- different sounds for work/rest (though I think that already is available?)
True randomness is not important. Mediocre randomness using whatever is convenient per platform is fine. Further tuning of randomness also isn't important scope (example: making sure that at least x% of it is work vs rest).
Hello! I would most definitely be open to accepting a PR for this.
For UX, I also agree that this would be easier to implement with the UX in #202. Feel free to drop some mock-ups on that issue for implementing this feature so that I can keep them in mind as I work on #202. I'll try to make some mock-ups myself as well. I am also thinking some sort of "Fixed Intervals" / "Total Duration" toggle?
I greatly appreciate the interest in the project and would love to see another practical use case like this implemented.
Hi @a-mabe ! Awesome, I'll take a closer look this weekend and try to draw up some mocks. Do you have a convenient way to share the Figma files for the mocks in the issue?
I am also thinking some sort of "Fixed Intervals" / "Total Duration" toggle?
What about, "Interval count" / "Total Duration" toggle. And then, if you select total duration, it defaults to fixed length intervals, but you can opt-in to randomized per work or rest with min/max length config? Frequently when I'm planning a workout, I think in terms of total work duration, even without randomness. Just a thought!
@jlizen I created a copy of the UX Figma design so feel free to edit directly, this link should work: https://www.figma.com/design/tN4mPwXnlE8YMkHQQUYrkW/New-UX?t=9BTQD8Jy8WU1chQN-1
What about, "Interval count" / "Total Duration" toggle.
I think this would work well. I'm assuming total duration would exclude any interval not work/rest from the total duration calculation (e.g. Warmup or Get ready as these are add-ons to the workout)
Dropped some mocks in the other issue: https://github.com/a-mabe/OpenHIIT/issues/202#issuecomment-2727729531
I'm assuming total duration would exclude any interval not work/rest from the total duration calculation (e.g. Warmup or Get ready as these are add-ons to the workout)
Correct, only work/rest would be randomized. I tweaked the mock a bit to segment out those "primary" time settings from the other optional ones.
(This discussion probably belongs here rather than in #202):
Technically there are use cases where somebody might want both total count + total duration, however this is pretty awkward to handle on the 'set time' view since they are effectively forced into a fixed ratio of work to rest if not randomizing, which we now need to validate, have design language to convey without confusing people, etc. So, I left that out, unless anybody starts asking for it.
It occurs to me that the same type of problem exists if the user sets a total duration based timer, without enabling randomness. It doesn't feel great to expect the user to calculate a perfect sum of work/rest lengths that evenly divided by the duration, and throw validation errors otherwise...
One option would be to just force randomness in case total duration is set. But that is a pretty unfortunate ux.
Probably the most user friendly thing would be to just implicitly adjust the total duration to the closest achievable value based on the set lengths? And have some sort of indication to the user that this happened?
Thank you @jlizen, I will take a look!
Probably the most user friendly thing would be to just implicitly adjust the total duration to the closest achievable value based on the set lengths? And have some sort of indication to the user that this happened?
I see the problem you've described. I'll try to think it over as well and post if I come up with anything. It might be one of those things that starts to make more sense as the UI is implemented