## Introduction A few weeks ago, I was contacted by my old coach, Dima Kachan, to help him out with an idea for a new training aid software. Dima is a very successful international gymnastics coach. He has six world championship medals, across five of his athletes and two disciplines. I have been lucky enough to train with him over a period of two years (unfortunately I haven’t won him any medals) and I’ve learned a lot. A lot of factors goes into becoming a world-class gymnast, like training intensity and recovery. One of the big factors Dima monitors, is total difficulty of skills, performed in a training session. This metric helps measure the physical demands placed on gymnasts based on how difficult skills they perform and varies depending on the training phase in a season. Currently, Dima uses spreadsheets for tracking difficulty. Athletes manually record the number of repetitions for each skill performed during a session. However, this system is cumbersome, error-prone, and often neglected by athletes. This is where I come in. This blog will first explain the more overall process I go through in a project like this, followed by a bit of technological decision making. ## The Process When I start new project, I use an iterative process. Rapid prototyping allows me to get a functional version into users’ hands early, ensuring the app meets their needs. Feedback is invaluable, helping me avoid spending time on unnecessary features. The first step is to figure out the requirements. What does the app need to do? In this case, it need to replace the spreadsheet and make tracking and monitoring training, more dynamic. ![Feature and corresponding requirements](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k7kpgkext675wj7exvat.png) After spending some time talking with Dima and looking at the existing approach, the main requirements of the app is: - **Athletes** should be able to track each skill they do and on what apparatus - **Athletes** should be able to see their difficulty for each session - **Coaches** should be able to see which skills the athlete has done during a session - **Coaches** should be able to see a weekly or monthly view of what an athlete has done - **Coaches** should be able to assign programs (set of skills for a session) to an athlete. These requirements translated into the app’s core features: - **Tracking**: Where users choose their program and record their skills - **Monitoring**: Where athlete and coach can monitor completed sessions and difficulty - **Programming**: Where the coach can put skills into programs and assign them to athletes With the features set and confirmed with Dima, I can start developing. To ensure the app is useful from the start, I prioritise features in this order: **Tracking → Monitoring → Programming** This sequence allows me to collect and review training data early, gradually adding more functionality. Each feature is deployed on GitHub Pages for Dima and his athletes to test, providing immediate feedback. These insights guides refinements before I move on to the next feature. ## Technical Insights ![Tech stack](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9oqwql22iu45hcd7vejy.png) ### Tech Stack My base tools of choice are Flutter and Supabase. Flutter is a cross-platform frontend framework, which allows me to make apps for both Android, iOS and web. Supabase is my backend which delivers database and authentication, it is open source and it runs on PostgreSQL. These choices came out of necessity, as I had to implement ML models into a Flutter app, in a previous job for a medical monitoring app. I fell in love with both Flutter and Supabase and have used it since. I wanted to try out the MVC design pattern, as it seems to be the standard in a lot of companies, but as the app grew, the unfamiliar framework got in the way of quality. The controllers got too bloated and the interplay between the different components wasn’t clear to me. Because of this, I switch to Clean Architecture, which I’ve worked with in other projects. For me it offers more granularity, as the organisation into individual features makes a lot of sense to me and it ensured that each feature remained independent and testable, simplifying future maintenance and scalability as more users are added to the app. I make use of BLoC for state management as well, which makes my widgets very clean and simple. ### Features With the foundation of tools, architecture, and state management in place, I focus on implementing the core features that will bring the app to life. Each feature is designed to replace the existing spreadsheet workflow while prioritising ease of use and functionality for both athletes and coaches. #### Tracking The main functionality from the spreadsheet, that I replace, is tracking. It needs to be quick and simple, so the athletes wont get their training disturbed, but it just becomes a habit. In order to accomplish this, I come up with two designs. A button layout and a bar layout. ![Tracking views](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5u7eilo35l5ynd6pfc9f.png) The design needs to fit in adding, subtracting, reseting and editing a large number of skills. As you can see, my solution is a toggle menu for layout and skill name format, allowing the athletes to smoothly go back and forth. This makes it possible for the athlete to customise the experience, while utilising all the features with one tap. The functionality itself is a simple set of counters stored in BLoC and uploaded to Supabase. The challenge with this is how to format the data. Sessions and Skills are the two main models, but within them, they need to keep track of data for each piece of equipment. Although I don’t believe it’s the best solution, I’ve used a map to solve this. This keeps the data structure compact but may require additional handling for custom equipment in the future. *Session Model:* ```dart import 'package:equatable/equatable.dart'; import 'package:json_annotation/json_annotation.dart'; import 'package:tumblelog/constants.dart'; part 'session_model.g.dart'; @JsonSerializable(explicitToJson: true, fieldRename: FieldRename.snake) class SessionModel extends Equatable { final String id; final String athleteId; final String athleteName; final DateTime date; final double totalDd; final Map equipmentDd; const SessionModel({ required this.id, required this.athleteId, required this.date, this.totalDd = 0, this.athleteName = 'NoName', this.equipmentDd = defaultEquipmentDd, }); // Factory method to create a SessionModel from JSON factory SessionModel.fromJson(Map json) => _$SessionModelFromJson(json); // Method to convert a SessionModel to JSON Map toJson() => _$SessionModelToJson(this); @override List

mikkelsj

Usecase: TumbleLog

Join Our Newsletter. No Spam, Only the good stuff.