What's next — and what openGym is deliberately not going to be #37
Replies: 2 comments
|
This is fantastic — I've got it self-hosted on my NAS and completed my first workout with it the other day, using it on my phone in the gym. Went smoothly. Importing my history from the Strong app also worked with no issues. From your list, per-exercise notes and a plate calculator are the two I'd use straight away. One more, in the concrete style you asked for: when pulling up a completed workout from the Stats page, it'd be great to have an option to repeat that workout. Even though a workout starts from a planned routine, I sometimes adapt it on the day — swap an exercise, add one in — and right now there's no way to get back to that specific version later. Being able to open a past logged session and re-run it as-is (rather than only ever re-running whatever the current plan says for that day) would cover that. |
|
This is just what I have been looking for, going to give it a go in the gym later. Importing my workouts from Progression went well and is such a great feature, something missing in a lot of other apps. Given the wide range of naming differences for the same exercises it would be great if the unknown exercises could be manually mapped so that they can be associated to an existing exercise in the app if available prior to labelling them custom. |
Uh oh!
There was an error while loading. Please reload this page.
The roadmap so far has been driven almost entirely by issues people opened, so here's the current
state of it in one place. Tell me which of these you'd actually use — that's what decides the
order.
Planned
engine. The policy interface in
src/lib/progression.jsis already there; this is mostlywriting the policy and its tests.
languages; the upstream dataset just doesn't ship instruction text for these two yet.
Shipped, in case you missed it
Automatic progression programs · estimated 1RM · effort per set (RIR/RPE) · importers from
FitNotes, Strong, Hevy and Apple Health · standalone Android app · 12 UI languages.
What it's deliberately not going to be
Not a rejection of anyone's idea — just so nobody spends a weekend building something that then
gets turned down:
has exactly one dependency. A feature that needs a database server or a build-time framework is
going to lose to a simpler version of itself.
it badly is worse than not doing it.
So: what's missing?
Reply with what you'd use, or open your own thread in
Ideas. Concrete beats
abstract — "I run 5/3/1 and I need the TM to recalculate after a failed AMRAP" is far more useful
than "more programs please". If you're migrating from another tracker and something didn't come
across, that's a bug, not an idea — open an issue.
All reactions