Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support lifting programs, especially those that don't fit within a week #848

Open
ChemiKyle opened this issue Oct 6, 2021 · 15 comments
Open
Labels
effort: high High effort/complexity, e.g. big feature help wanted needs discussion Feature not yet completely clear, needs brainstorming
Milestone

Comments

@ChemiKyle
Copy link
Contributor

ChemiKyle commented Oct 6, 2021

Use case

Programs whose workouts don't fit within a single week schedule are tedious to configure.
Programs like Stronglifts and Starting Strength are simple enough to just deal with the tedium, but programs like GZCL and 531 - which follow an ABCD cyclic pattern of workouts - but are intended to use a 3 day schedule require 4 individual workout weeks to be made in this example, despite only having 4 unique days.

Proposal

Ideally, one should be able to specify N workouts cycling over M days (specified weekdays is simplest, though I imagine some PPL routines may deviate from MWF).

Again, using GZCL as an example, there are 4 unique workout weeks: ABC, DAB, CDA, BCD. Ideally there would be an interface much like the "Workout" creation that allows defining an arbitrary number of training days, perhaps assigning them an integer instead of a weekday. The next step would be to pick the days of the week to schedule.

This could fall under a new option, "Training programs".

If it needed to fit within the existing framework, a "training program" could be an advanced option while creating a schedule; the requisite number of "workouts" could be autogenerated until workout "A" appears again on the first scheduled day1. Each of these workouts would then be added in to a looped schedule, each workout's "Weeks" set to 1.2

Consideration of full periodization support

Periodization support would be necessary to really ship a "Training programs" feature but may be beyond the scope of this issue.

Non-responsive undulation can be handled by the user, but even simple progressive overload is dependent on user logging.
When initiating a log on a known workout, the previous log for the same workout would be checked if it matched the specified number of reps and requisite weight increase for all sets of the specified exercise. If it did not, the autofilled values would fall back to the next stopping point. An issue here is the programs I've used as examples increase set count the next exercise after a failure, managing this on the frontend may be as simple as generating an additional <div class ="form-row form-row"> on the log page, but I haven't dug into the backend much.

Footnotes

  1. I'm sure this can be pre-calculated, there must be some formula for a set of N ordered elements mapping to a set of M ordered elements having P permutations, but my combinatorics knowledge has left its pigeonhole.

  2. I'm poking around the database (much easier thanks to the docker setup!) trying to implement this, albeit outside wger itself. I do this sort of thing for a living in R; I'll try to keep my script general if anyone might find it useful. I'm not familiar with django, but may be able to translate to python3 with standard lib (might need pandas) if that'd be helpful to the dev team.

@rolandgeider rolandgeider added needs discussion Feature not yet completely clear, needs brainstorming effort: high High effort/complexity, e.g. big feature labels Oct 7, 2021
@rolandgeider
Copy link
Member

This is a good idea and something I've also been thinking about. What I personally do when I have something like your GZCL is adding all four days and keeping track of the days (which is easy, but not optimal, that's something computers are very good at).

The same for any kind of planned weight change we might need (what is the smallest unit by which you can increase the weight? what happens when you are not able to lift the planned weight one week? What if you do more?)

In general, I would prefer to only have one point to add such routines in the app, the current schedules are only tacked on and if we implement this would be removed. It might be enough to hide this behind some switch that shows the advanced planning. Or we save some program templates so that you could select 531 and just "fill in" some values, the rest of the planing is already there.

@manfre
Copy link

manfre commented Nov 6, 2021

For adaptive programs, the weight and/or reps can vary based upon the previous workout of that type. E.g. With SBS there is a percentage change to the training max (up or down) based upon how many reps in the final set compared to the target number of reps. For 531, you increase training max only if you hit a minimum number or reps in the 1+ AMRAP set.

If there is a singular way of adding training sessions, these adaptive programs could potentially leverage that portion of the API in a pluggable way that essentially does an "add the next scheduled session". This is something that I need in a training program to accommodate my training not being bound to a weekly schedule. It cycles between 5 unique training days over a period of 8-12 days (depends on schedule and how I'm feeling).

I found wger today and am planning to get more familiar with the code to better refine my idea of how the above can fit in to the project. (Really happy to have found a Django based fitness project while determining if I needed to create one)

@RlndVt
Copy link

RlndVt commented Jan 2, 2022

Proposal

[...] Ideally there would be an interface much like the "Workout" creation that allows defining an arbitrary number of training days, perhaps assigning them an integer instead of a weekday. The next step would be to pick the days of the week to schedule.

Emphasis mine.

Is it necessary to loop back to the day of the week? I would say it is preferable to just keep it ABCD or 1 2 3 4; and show which is the next workout.

Using a rigid 'days of the week' of the week system has a few issues:

  1. For people with a more chaotic out-of-gym life; one week they might fit in one workout and another week four, and never on the same day of the week.
  2. As OP mentioned, some lifting programs don't 'fit' in a week. If someone wants to use a ABCD schedule, but train thrice a week we get OP's scenario. But this is the case for any mismatch between scheduling days, and workout days (per week).
  3. Missing a workout-day, should not equal missing a workout. e.g. Running a U/L or PPL scheme and missing one day would mean you skip a targeted area. And we all know you should never skip leg-day.

So in conclusion, I would suggest stepping away from days of the week for creating a program.

@rolandgeider
Copy link
Member

I would also tend to specify how often / in which order / etc. one plans to do the training and then calculating the days of the week on the fly as some kind of nice to have info for the calendar, personal planning, etc. This would have the advantage that if you miss one day the next dates are still right, but we might also want to show a warning or something similar.

In any case, after finishing the exercise rewamp (whenever that might be), this is probably the next bigger feature I'd want to tackle

@ChemiKyle
Copy link
Contributor Author

I think templates are a good idea as long as customizability remains. Perhaps an import/export feature would be a good addition here. Most programs are distributed via spreadsheets with macros which leaves a lot to be desired.

My first thought would be to store program data as JSON - this may not play nice with base SQLite, but there is an extension - for customizable progression based on performance. That opens up quite a can of worms, but I tossed a mockup down at the bottom.


Is it necessary to loop back to the day of the week? I would say it is preferable to just keep it ABCD or 1 2 3 4; and show which is the next workout.

I would also tend to specify how often / in which order / etc. one plans to do the training and then calculating the days of the week on the fly as some kind of nice to have info for the calendar, personal planning, etc

Indeed, auto calculating this may be best, perhaps setting an acceptable range of rest days and intended sessions per week? I definitely agree that if you miss a day it should not mean skipping that exercise.
Personally, knowing what exercise, weight, and reps I have to do next is what I'd like to know at a glance. Timestamps don't seem important outside of data entry.


Here's a bit of rough JSON off the top of my head for how a cookie-cutter GZCL "A" workout may look; it is perhaps over engineered - and overfit to linear progression GZCL - but I tried to imagine how undulating periodization and AMRAP varied progression may be handled generically.

Expand JSON mockup

In prose, if you hit your rep/set goals, you increase weight by weight_increment for the next session of that workout.
If you miss your reps for any set, your weight remains the same and you fall down to the next scheme for the next session of that workout (e.g. if I'm supposed to do 5x3 and I get 3, 3, 3, 2, 1, next session I do 6x2 at the same weight).
Once you fail the last scheme, your next session is spent trying to find your 3 rep max.

  • The final set is AMRAP, if you double your goal reps, you also double your progression.
    • I think 531 the scheme:weight_increment would be 0, since progression is solely based on AMRAP.
[
  {
    // workout day is an array of objects representing lifts and metadata
    "A": [
      // Tier 1 lift: low rep, high weight
      {
        "lift_name": "back_squat",
        "scheme": [
          // schemes are ordinal, if you fail progression criteria, you drop to the next scheme
          {
            "sets": 5,
            "reps": 3,
            // successfully complete this workout scheme this many times to enable weight increment,
            // possibly useful for programs that don't progress each sequential session
            "success_limit": 1,
            "weight_increment": 10.0
          },
          {
            "sets": 6,
            "reps": 2,
            "weight_increment": 10.0
          },
          {
            "sets": 10,
            "reps": 1,
            "weight_increment": 10.0
          },
          // after failing all the above schemes, GZCL has you retest to find your 3RM
        ],
        "progression_changes": {
          [
            {
              "scheme": -1,
              "reps": NULL,
              "weight_increment": NULL
            },
            {
              // (optional) success condition, hit double your rep target to increase rate of progression
              "set": "last",
              "reps": "double",
              // choose one of these, flat replacement of usual or multiplier on usual
              "weight_increment": 20.0,
              "bonus_weight_increment_multiplier": 2.0
            },
            {
              // (optional) failure condition, fail to meet reps on any set and you will fall to the next scheme
              "set": "any",
              "reps": "less",
              // optional smaller weight increment?
              "bonus_weight_increment": 0.0
            },
          ]
        }
      },
      // Tier 2 lift: high rep, low weight
      {
        "lift_name": "bench_press",
        "scheme": [
          {
            "sets": 3,
            "reps": 10,
            "weight_increment": 5.0
          },
          {
            "sets": 3,
            "reps": 8,
            "weight_increment": 5.0
          },
          {
            "sets": 3,
            "reps": 8,
            "weight_increment": 5.0
          }
          // after failing the final scheme you simply start back from the top at a lower weight
        ]
        "progression_changes": {
          [
            {
              // failure condition, fail to meet reps on any set and you will fall to the next scheme
              // fail to meet reps on the final scheme and you lower weight and restart
              "set": "any",
              "reps": "less",
              "scheme": -1, // end of scheme array
              // decrease
              "bonus_weight_increment": -20.0
            }
          ]
        }
      }
    ]

@BeatLink
Copy link

Here is my spin on how this would be implemented.

Workouts would be organized in two stages: Sessions and Schedules.

Sessions would be a group of exercises along with all of their details (reps, weights, sets, etc). Eg Push, Pull, Legs or Workout A and Workout B

Schedules would be groups of sessions organized so that sessions can be added to particular days of particular weeks.

Hopefully the below hierarchy helps explain somewhat

  • Weeks (eg. Week 1, Week 2, etc)
    • Days (eg. Monday, Wednesday, etc)
      • Sessions (eg, Push, Pull)

It is essentially the existing system but rather than breaking each workout into particular days, it would be the schedule that would be broken up into days after the weeks. Workouts would just be self contained sessions, devoid of scheduling information.

So for example, a user may create 4 seperate sessions: Push, Pull, Legs and Cardio.
The user could then combine these sessions to form a schedule, so for example,

Week 1
Monday - Push, Cardio
Tuesday - Cardio
Wednesday - Pull, Cardio
Thursday - Cardio
Friday - Legs, Cardio

Another Example would be an alternating programme

In this case, the user would create 2 sessions, Workouts A and B. Then it could be implemented as follows:

Week 1
Monday - A
Tuesday
Wednesday - B
Thursday
Friday - A

Week 2
Monday - B
Tuesday
Wednesday - A
Thursday
Friday - B

Loop Weeks: On

@BeatLink
Copy link

Hi. I wanted to find out if there was any progress with this design change. Perhaps we could get a poll for the various ideas?

@rolandgeider
Copy link
Member

Nothing spefic yet, but you are right that we should probably start thinking about specific things to do.

Somebody in another issue suggested taking some inspiration from https://www.liftosaur.com/ about handling progression

@BeatLink
Copy link

I took a look at that app before and it would be awesome if this could be integrated into wger!

The first step I think though would be decoupling the workouts from specific weekdays though. Once you have self contained workouts decoupled from scheduling information, you could then look at integrating the scripting syntax from liftosaur.

Any thoughts on the structure I proposed here #848 (comment)?

@IsotoxalDev
Copy link

This!! This is something i need as well

@BeatLink
Copy link

BeatLink commented Jul 6, 2023

I've created an entity relation diagram to detail my suggested structure. Maybe it could give some guidance with refactoring the models:

irontech-entity-diagram drawio

Its still a work in progress but if you need help explaining any part let me know

@rolandgeider
Copy link
Member

something like that, yeah. Something that we still need to consider for the data model is handling progression, e.g. like in the JSON on this comment

@lediable
Copy link

Any update on this feature?

@rolandgeider rolandgeider modified the milestones: 2.2, 2.3 Oct 20, 2023
@rolandgeider
Copy link
Member

status update, I've started doodling and thinking about this and besides the usual unplanned stuff that suddenly needs to be done, I'll try to actually (and finally) work on this

@RlndVt
Copy link

RlndVt commented Dec 10, 2023

I've created an entity relation diagram to detail my suggested structure. Maybe it could give some guidance with refactoring the models:

irontech-entity-diagram drawio

Its still a work in progress but if you need help explaining any part let me know

A small change suggestion:

image

The 'workouts' or structure (what you called schedule) should not be coupled to a 'day of the week'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort: high High effort/complexity, e.g. big feature help wanted needs discussion Feature not yet completely clear, needs brainstorming
Projects
Status: In Progress
Development

No branches or pull requests

7 participants