The Intent Of This Post
In sharing the development progress of the MOOVPAD apps on a regular basis, I've found myself repeating certain points, or wanting to explain the reasons behind particular approaches to this but not having the scope to do so in a short format. This post will be linked to the bottom of each upcoming MOOVPAD Blog post as a way of summarising these key points specifically related to the "why, what, when, where, how and who" of the MOOVPAD development process. As there is quite a lot to cover, and additional points may be needed over time, this post will be an ongoing work in progress, with new sections added as the need arises. Where you see headings with no content, these are placeholders for more content still to be written.
Point 1
Why Is MOOVPAD Necessary?
The need for MOOVPAD as a suite of apps arose out of the research I completed for my Honours and PhD projects at uni, between 2009 - 2014. From this research began the notion of defining "physiologic efficiency" mathematically in a standardised, repeatable and universal way that could be used across exercise science and physiology. This work is itself an ongoing process too, with the "Physiologic Algorithms of Physical Exertion (PAPE)" that contains all of these mathematical relations continuing to expand as I develop more of the logic behind this science. There have been research publications, conference presentations, as well as patent releases and these specifically have become the main publication focus for MOOVPAD app development purposes, for obvious commercial reasons.
However another major part of the MOOVPAD project overall is the publication of the science behind all of this, in a series of books and courses. As these are not really within the scope of app development, I will mention here that these and other resources relating specifically to the underlying science behind MOOVPAD can be found through the link to the right as part of the current Resources section of this website. And this brings us to the "why" behind the MOOVPAD apps themselves...
To make all of this science usable for people during exercise and training, tools were needed. The current apps and approaches available for desktop, mobile, wearables, and online all focus on using measurements like heart rate, distances, speeds and so on, without making the connection between these things. MOOVPAD apps and the science at their core are the first to make these connections, giving users a "miles to the gallon" during exercise. There are lots of calculations to be made for this process, and doing these manually is not practical. That's where MOOVPAD apps come into the picture, allowing users to collect information about their exercise simply, and get very powerful information about their results that can be used to improve their performance in meaningful ways.
Point 2
Choosing Blazor WASM For The MOOVPAD Web App
This image to the right was a screen capture taken on 01/06/2022, and this was (I believe) the very first time I had actually tried to learn about Blazor. I had tried other frameworks and approaches in the past relating to moving the work I had been doing for the Windows desktop version (explained further below). I also spent some time learning about Razor just before this period. But Blazor had a few advantages for my case over these other methods.
The main one being that the code and "class library" I had already been building for previous work was developed using the programming language called C#, which is also the main language at the core of Blazor (as is the case with Razor). However as of this date, there are currently two main flavours of Blazor (although Blazor hybrid for .NET MAUI is also officially launch - but that's somewhat a separate issue as it is mainly focused on taking Blazor for web dev and simplifying the migration of these projects to desktop and mobile).
And so from the start of June 2022 through the end of July 2022, I began working and learning about Blazor, but initially focusing on Blazor Server (the first of these two "flavours"). This framework has many good points, but it was around the middle of July 2022 when I realised that I would have trouble getting the user interface (UI) that I wanted for the client-side if I continued with Blazor Server, as the small amount of javascript I needed to use for building the UI screens the way I wanted simply wouldn't work.
That's because the pages in a Blazor Server project, as the name implies, are server-side rendered, meaning the javascript I need to adjust page appearance on the client-side wouldn't run. And so to get the kind of results that I currently have with the UI in it's present state, I moved to Blazor Web Assembly (WASM) around the end of July 2022, and began learning about how this approach worked. Both of these systems were completely new to me as frameworks, and I am quite lucky I was able to discover this limitation early.
Point 3
Everything On The Index.Razor
In recent posts, I've shared the approach I'm using to build the MOOVPAD Web App with all of the UI code and markup being contained/written on the Index.razor page. Of course this is not necessary in Blazor WASM, which even though allows the building of "single page applications (SPA), actually remains flexible by allowing developers to include razor components as building-blocks for pages, as well as the navigation between different pages. I am by no means an expert in this field, and would recommend finding appropriate experts to learn from when it comes to Blazor WASM and how it is intended to be used in a standardised way. I have certainly found learning about these approaches insightful. Ultimately though, I chose to take the route of including all of the code on Index.razor for a few reasons, with one being a major point for me.
Cookies and session tokens... to me, these things are a user-privacy and security risk. I know from personal experience that these things allow more than just advertising trackers to deliver "personalised content". They also enable dangerous hacking and harassment. And I want MOOVPAD apps to have no part of this, and will do everything I can to ensure MOOVPAD minimises these risks for users. In doing so, MOOVPAD will NEVER use advertising trackers, will minimise data collected and stored on our servers, and will avoid the use of cookies. This last point is made possible by keeping all of the code on the Index.razor page, since there's no need for navigating to other pages, meaning no need for session tokens and cookies to run the MOOVPAD Web App.
I did my own research and also asked some professionals with lots of experience about any differences between having all of the code and markup contained on the Index.razor page versus having these split up over many razor components. As the approach I'm using is not the normal method, the experts could only advise that "there shouldn't" be a difference, but they couldn't be certain as they hadn't tested it themselves. Completely fair enough of course, and in terms of my own logic, the same amount of code would be downloaded by the users' browsers regardless of it's breakup, so there shouldn't be a difference in terms of initial download by browsers.
Another important reason for having all of the UI code on the Index.razor page is the ability to use transparent (opacity 0) elements, which isn't possible using razor components. For example, I've used .PNG images to build the compound gauge (more details through the link to the right). If I built this as a separate razor component and called it in, it would have it's own background (to the best of my knowledge at least).
Point 4
Why Use Only Part Of The User Screen/Web Page
There are a few reasons for reducing the footprint of the MOOVPAD Web App on the web page, and I'll quickly go over the main two here. The first is that the app needs to be consistent across all of the different platforms and devices as much as possible. While there will of course be some differences as screen sizes get much smaller (e.g. on small mobile devices), the goal is to keep a consistent look and feel to the MOOVPAD Web App on desktops and tablets, which can have screens much smaller than the large format monitor I'm currently using for development. It's the size of my monitor that makes these screen captures look as though the user screens are really small. Actually, the width of the main stage/tablet where all of the content is shown is 1100 px wide.
Another important reason is that depending on the user and the particular situation where the MOOVPAD Web App is running, there may be a need to have more than one window open at the same time. And while not everyone using the app will be running it on a large format display, I wanted to do what I could to make it easier to have more than one of these windows open. For example, some users of the MOOVPAD Web App may be professionals who need to have more than one window open for a particular client, or multiple clients.
