In their first week with Commit, each new Engineering Partner takes on a hackathon onboarding project. They build a project, present it to the Commit community, and write a short summary of their experience. There are no restrictions, no limits, no joke.
My onboarding at Commit has been one of the most pleasant experiences I’ve had as a new hire in a company. My first day was pretty busy, learning about the processes and company culture, and getting to know the team. Taking some initial time to work on something I had my mind on, for the hackathon onboarding project, was something new for me. I struggled a bit to find out what I wanted to do since I didn’t have anything at the top of my mind.
Eventually, I settled into working on something I thought about during a distant pre-pandemic time when going to the gym was part of my routine. When I was a novice at the gym, I was always curious about why instructors recommended pairing specific exercises, or why it was okay to work on some parts of the body on the same day. It seemed to me that most gym knowledge was shared by word-of-mouth and nobody knew why they did things a certain way.
Researching what’s out there already
Through my informal research, the reasoning on why some exercises’ movements are recommended over others and why some exercises go well together with other exercises was something that I had a hard time understanding. While I admit that a good part of this research was kind of “folk science,” I was satisfied with these explanations, as some of this data was backed up by actual research and science.
I spent a good amount of time trying to figure out a good workout routine with this information—a workout routine that properly worked out my full body with the equipment I had available and, if I couldn’t get access to some of it for some reason, alternative exercises that I could replace without detriment on the balance of my workouts.
So I had a pretty niche need, but the existence of the resources I found was a good indicator that there were people that could probably find an app like that useful.
In the end, it was simply an idea that I kept on the backburner. In parallel, I was never happy with the workout apps available at the time. I tried a few of them and I never liked one, in particular, some apps did something great but fell short on others. So an itch to have a single great workout app that had great features for tracking and that also helped you design your workouts started to take shape. But I never really explored the idea until I joined Commit.
The making of my HOP project
While I have ambitious goals for this project, which I call Irontemple (common slang to refer to the gym), I just wanted to build something simple that put the general rules of designing a balanced workout routine into an app.
Also, I wanted to explore various concepts that I haven’t had the chance to explore recently, such as:
- Building a UI using a modern React framework. I used Material UI.
- Toying around with React Native a little bit
- Exploring the idea of mobile-first design
- Putting into practice an implementation approach I’ve used in the past but wanted to try: Rule of Representation: Fold knowledge into data.
So I got down to business by thinking about a simple use case: As a user, I want to create a workout routine based on how often I can go to the gym.
So, with my limited design knowledge, I put together a simple landing screen:
Each of these days has preset templates that act as recommendations. For example, for the three days a week option, the application has a base template of configuring a Day A and Day B routine:
As you select exercises, the application evaluates your selections and tests basic recommendations and it makes sure that you choose exercises that go well with your previous selections:
In terms of UX, I believe that some automation can be done here so that recommendations are automatically selected for you or shown at the top.
Once you’ve selected your exercises, you can save your workout and it’s ready for you to try.
The bulk of the logic of the application lies in the data structures that describe the workout templates and rules they follow. This goes in line with the principle of the “Rule of Representation,” keeping the implementation straightforward and more complex logic out in “smart objects.”
For example, the component that drives the workout day configuration looks something like the following:
And the data structure that drives the UI component looks like this:
The component has very little logic in terms of driving what is presented in the UI. The bulk of the logic exists within the schedules data structure. This makes it very trivial to add new schedules in the application, or to eventually support users creating and sharing their own schedules. In this prototype, the validation rules apply on a specific day but it is possible to add validations that are evaluated in the context of all days within the schedule. This complexity can be contained within this data structure and the UI component would require very little changes, if any, to support these new validations.
Furthermore, we can have functions that generate other functions for rule validation as patterns start to emerge; in this sense, we start to look at the complexity and logic of our application as data and suddenly we can craft complex scenarios and application logic from basic building blocks that are easy to understand at a fundamental level.
Takeaways
After spending a long time searching for the perfect fitness app, I gave up and went with the one that ticked most of my checkboxes. It wasn’t perfect but it did the job while I thought about building an app myself that would tick all my checkboxes. In my mind, I had a more or less clear picture of what I wanted, but, curiously, I found putting those thoughts into a working prototype very difficult. When you add the complexity of being in charge of building a UX out of other people’s vision, the task becomes exponentially more difficult.
At the end of the day, the reason why I didn’t like all those apps I tried was mostly because they had poor user experience in my eyes. You can have a well-designed application in terms of infrastructure and architecture, but if the UX is not there, users will just skip your app and try the next thing, just as I did.
In terms of the code design, it was fun to again explore the approach of keeping complexity within data structures. This is not a new concept and also likely not an original one. There are many philosophies that follow a similar line of thought, for example the “fat models, skinny views” approach on a MVC architecture or the Separation of Concerns principle.
# # #
Xavier del Castillo is a Commit Engineer who enjoys working out (obviously), as well as playing piano and reading epic fantasy novels.