Feature Requests

Strain-Based Training Load
Hi, After digging deeper into how Apple handles training load calculations for watchOS 11, I had an interesting idea for the Bevel team. Apologies for the following, as it it is a bit long winded. We know from watchOS 11 that Apple’s attempt at training load is approximately equal to their “effort” score multiplied by duration. Currently, Bevel has a “cardio load” which is TSB based (if I am not mistaken). However, one of the biggest complaints is that there is no good way to track holistic load over time since many activity types are not high HR and so TRIMP exercises do not impact cardio load properly. Insert my proposal: Since we have a strain score for both cardio and muscular (strength trainer) workouts, what if Bevel collected those and did its own holistic training load calculations? This would essentially have each day’s acute training load be the (exponential) moving average of the previous 7 days workouts strain scores, and the long-term training load be the 28 day (exponential) moving average of completed workout strain scores. To make this more helpful, you could even allow users to view training load by sport type (running, walking, gym, …). To get even deeper here, this new training load could be tied directly into the HRV state metric and/or the journal, showing how your training across various sports/overall is impacting HRV, sleep, and recovery. You could keep the current TSB-based cardio load, renaming it to TRIMP load or something like that, and include this new training load as a more holistic understanding for users. The graph structure for the current cardio load would work perfectly for this new training load as well, with a chip selector for sport type to show just that sport. Because strain is calculated automatically, the user never has to manually log anything in-app and every user, high-HR runner or not, can track their training load over time.
3
·

planned (soon)

We've got Muscular Strain, now let's think about Muscle Recovery:
We all know based on research and papers, that HRV, which is one of the main component of Superset Recovery, is not a reliable metric to measure muscular recovery, it's perfect for running, swimming, cycling, but not so much for Strength based excercises. Let's try to find a way on how can Muscular Strain be used to help us plan workouts: There are studies which aim to understand the general time each muscle group takes to recover, obviously there's always variability based on the subjectivity of individuals, but that, as of now, can't be easily measured with just a watch and an app. So, why don't use data like in this link to quantify recovery in relation to muscular strain that we already have?: https://www.patreon.com/posts/recovery-rates-62989969?l=it Something like this is made by this app(fitbod): https://fitbod.zendesk.com/hc/en-us/articles/360006269014-Muscle-Recovery You can see there's a body heatmap(which i believe someone else already requested and so it's planned) and which muscle group is already recovered and at which percentage, probably based on generic recovery data like the one i linked before. Obviously one could even change the recover percentage with the slidebar because, by self evaluating, feels like that muscle group is more recovered than expected by the app. This would be completely unrelated to Recovery that we have right now, so it wouldn't screw with it and people which don't use strength builder wouldn't be bothered by it. It could use muscular strain data that the app already has, to calculate the impact on muscle groups and how much recovery is needed(cross checking with the standard recovery data). It would be a completely different tab where you would be welcomed by the body heatmap which refreshes with time and changes color reflecting, becoming less and less red the more it's recovered. Also, wourkouts could show a color, a percentage or an alert informing you that your excercises in your workout could be of muscle groups still recovering. In the end there should always be a big disclaimer that this should be used as a way to auto evaluate and not dictate when or not to excercise. I attach some quick edited images with the idea of how it could be implemented in the app UI.
3
·

planned (soon)

Load More