6.5.4 Survey responses
This module allows the coach to read the survey response from each player. The coach and the medical staff is the only users defined as privileged (see table 3.2), therefore, they can access all responses in the campaigns they participates in. As a default, a statistical graph is presented to show which survey and how many has answered in the last 14 days (see figure 6.14(a)). The coach has to select a date in order to retrieve a list of who has answered surveys of a specific date. The list is divided into two groups;
responded and not responded. The name of those who has responded is hyperlinked, and by clicking on a player’s name an overview of the responses is shown (see figure 6.14(b)).
(a)
(b)
Figure 6.14: The response-module in pmSys-Trainer
6.6.1 User study: pmSys front-end vs Ohmage front-end
In chapter 3, we evaluated Ohmage and all the systems under the name of Ohmage. In this section we will evaluate Ohmage’s front-end versus pmSys front-end, since its features is vastly different from each other. The front-end Ohmage currently uses is meant for both the coach and system administrators, what it lacks is the features the coaches needs, in this case it is visualization that works correctly when deployed. Instead of replacing everything Ohmage has to offer, we have replaced the mobile application and the front-end (pmSys-Trainer) to suit our users better.
Systems User manipulation Class manipulation Campaign manipulation Survey manipulation Visualization Push notifications
Ohmage Yes Yes Yes Yes Yes No
pmSys No No No No Yes Yes
Table 6.1: Ohmage versus pmSys features
The reality is that where pmSys lacks features, Ohmage fulfills the missing functionalities (see table 6.1).
This is especially true for the administration features, since it is not possible to add users or remove users from campaigns with pmSys. It is also not possible to create new campaigns, this is why the Ohmage front-end is just as important for system administrators as well at the pmSys front-end is for the coaches. In a way, both front-ends cannot be compared in the normal way where you analyze the features against each other. Since Ohmage has created a web portal for both the coaches and system administrators, whereas pmSys has solely focused on the coaches with analytic capabilities, which makes the requirements for each system vastly different.
(a) Visualization settings (b) Prompt types
Figure 6.15: Ohmage’s visualization module
If we were to evaluate features between Ohmage and pmSys, only the visualization module would be comparable in this case. In comparison between Ohmage and pmSys visualization of data, pmSys has a vastly superior visualization of the data, by giving the users the ability to interact with the data. Another important aspect of the visualization between pmSys and Ohmage is that Ohmage only offersstatistical
analysisof the survey answers, meanwhile pmSys offerscontent analysis. It also requires less steps to show different types of data parameters, which again can be translated into userability and motivational factor to use pmSys if you are a coach. Another difference between the visualization of data is the team visualization, meanwhile pmSys provides this feature, Ohmage does not have this feature at all. It is not possible to do this without doing the same queries for all the players and then open all the images it returns in order to see what happens. Even then it would make it impossible to compare the players against each other, this is why it is safe to say that pmSys is the best web portal of the two when it comes to team analysis, whereas Ohmage is the best front-end for system administrations.
6.6.2 Client side versus server side processing
pmSys has systems that has client side and server side processing of data, the difference between them is small, however, the outcome of performance may be quite large over time. To understand what we mean by client side and server side processing, we need to define them.Client sideis the side where the UI is viewed, the interaction on a web page, the machine the user is using to go into web page X. In the latest years it has been popular with what you can do with the client machines, now that the machines are more powerful and cheaper than before, the means needed to process large amount of data is getting reduced. In our case, we use JavaScript to process the visualization data on the client side, because of this reason.
Now that the machines are getting faster and more efficient, there is a lot to gain by moving the data processing from the server side (back-end) to client side. We thought a lot of data had to exist before the visualization would slow down the whole process, but in reality, it was only after 2 months of real data when the visualization started to slow down. The problem lies with the library we use to create the graphs, since it has trouble when there is more than 500 data points on a graph [91]. The problem also lies in the way the Ohmage back-end serves the data. Instead of one API call to get all data, we need to do multiple calls, then match the results from all the calls into 1 JavaScript object before creating the graph (see figure 6.16(a)). This increases the latency for the user even though it is barely noticeable since client machines are pretty powerful these days. However, with large sets of data, it becomes a lot of load on the web browser to process all the data.
There are several ways the processing process can be fixed, the first way is to process everything on the server side (see figure 6.16(b)), and then send it to the client side for simply visualize the data. This would be the easiest solution for big data sets, but there is also another way (see figure 6.16(c)) that requires some more work because then the Ohmage back-end has to be modified, to pre-fetch all the data together (unprocessed) and then returned. The difference between figure B and figure C is that one of them returns the data pre-processed processed which means the client can simply visualize the data, and the other way simply gathers all the data the client needs unprocessed, and instead of X calls the data is returned in one and then it is processed on the client side.
6.6.3 Token storage
In pmSys-Trainer, we chose to use Redis as the session storage, and some of the reasons has been discussed in section 6.4.2. The reasons listed were due to the speed and the high amount of supported concurrent connections in Redis, but another reason is that pmSys-Trainer can potentially use a lot of memory on sessions. Instead of leaving the sessions in memory without a timeout limit (current configured on pmSys-Trainer), it is possible to let Redis store this in a file to save memory. This way we can reduce the memory usage instead of using up all the memory needed on session tokens. The idea of using this technology is to force the coach to login once onto the web portal, after that the coach should be automatically logged in on to one specific computer. If the sessions were set to be invalid after
a couple of minutes or hours the coaches had to use time to log into the portal just to use it.
(a) Client side (b) Server side (c) Client side v2
Figure 6.16: Client side vs Server side with pmSys-Trainer