# Direct Mobile Coaching as a Paradigm for the Creation of Mobile Feedback Systems
## 3 Direct Mobile Coaching  
As described previously in the original Mobile Coaching paradigm [13; 15], feedback for athletes can either be sent by a coach or provided automatically by computer algorithms running on a server. However, since the computational power of mobile devices has increased over the last decade, parts of the algorithm in use could also be incorporated into the software running on the mobile client. While feedback by coaches can still be given remotely, the feedback provided by algorithms can now be computed on both the smartphone and a remote server. This is made possible by modern smartphones usually featuring a CPU using a multicore architecture, which allows applications to facilitate true multi-processing. Therefore, it is possible not only to capture data on the smartphone but also to analyse it and provide feedback at the same time. However, using a server as proposed in the original Mobile Coaching paradigm still offers benefits. One example of this is large (relational) databases. When run on a (hardware) server, a database usually offers better performance, for example, providing shorter response times for queries. Additionally, any data recorded by athletes can be made accessible to coaches, experts and athletes when stored in a central database (on the server). Hence, we propose \"Direct Mobile Coaching\". This model is built on the idea of making use of the additional computing powers. Figure 1 illustrates the architecture of the system, each of the components is described in more detail in the following sections. In this model, a mobile client collects data from sensors (wireless, wired or built into the device). Data are sent by means of wireless communication (e.g., WIFI or mobile data) \begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Challenge** & **MoCo** & **GCIS** & **RADAR** & **DMC/PEGASOS** \\ \hline Target field & High & Medium & High & Low \\ Recording arbitrary data & NA & High & High & Low \\ Providing concurrent feedback & Low/NA & Medium & NA & Low \\ Providing terminal feedback & NA & Low/NA & Low/NA & Low \\ Programming Language & Low & Medium & NA & Low \\ Complexity & Medium & Medium & High & Medium \\ Extending capabilities & Medium & NA & High & Low \\ \hline \hline \end{tabular}  
\end{table} 
Table 1: Challenges for potential first-time users. to the backend component of the server, where it is stored in a database. Additionally, a web-based frontend of the server offers different groups of users (e.g., athletes, coaches or experts) different views, such as reports, on the data. Feedback can either be provisioned using the remote components (c.f. Figure 2b) or directly on the mobile client (c.f. Figure 2a) by a \"Controller\", which can communicate directly with the server. Remote feedback can either be provisioned by a human or a software module (labelled \"AI\" in Figure 1). A further difference between MC and DMC is the clear distinction between the timeliness of feedback. Feedback is classified to be concurrent when it is provided to an athlete while they are exercising. A further type of feedback is so-called terminal feedback, which is provided after a movement or activity has finished. While MC does not incorporate such a distinction, DMC enables it in its model (Figure 2). The proposed architecture and terminology for these modifications are as follows: While on the client, a controller is responsible for the computation of the feedback, on the server, the live computations are performed by components referred to as AI module (artificial intelligence modules). Additionally, after an activity that uses the feedback system is completed, one or more post-processing modules are scheduled to perform post-hoc analyses for the activity. Furthermore, after an activity has finished, a mobile client can also provide feedback by requesting additional data from the server.