Let's start by putting to paper what the app is supposed to do. We'll start by what it is and then list out what is has to do, and what it will not do. What problems will it solve? What is the base approach to solving them?
Regardless of what is written at the start, no plan survives contact with the enemy and the app is bound to change with time. But having a good idea of it's scope is important.
This app is a workout tracker!
It is meant to be used with the Hybrid Calisthenics programme (HC). It will have pre-created exercises.
As per HC, exercises have progressions which are variations on the exercise itself (actual form, not reps/sets). As such, HC groups all push-up related exercises into a Push-Up group, and then their variations (knee push-ups, wall push-ups, etc.) as Progressions.
Goals
The app will have/allow:
- CRUD for exercise groups, their progressions, and the difficulty levels for each progression. Progressions will always have three difficulties (amount of sets + reps): Easy, Medium and Hard.
- CRUD workouts. Workouts are sets of exercises.
- CRUD reactions to past workouts. The user should be able to fill in if they were able to succeed or, if not, how far they got into their workout.
- Schedule workouts/single exercises and react to workouts on a calendar. The calendar is meant to be the main UI of the app.
- User authentication and verification (login system) with Role-based functionality. Normal users have access to their own stats and base app functionality. An Admin role will be created that can see statistics for everyone (anonymously) but will have no real power over the users.
- See statistics via tables and graphs of how workouts are going overtime.
These systems all seem to interconnect even if slightly, so designing the DB schema should be simple enough :)
Top comments (0)