Prior to the real user study, described in Section 4.2, we tested our RMA platform with a small group of participants in a technology trial. In this initial technology trial, we had three users (2 PhD students and 1 staff member from HCI group, school of Computer Science). We have isolated key practical issues that could impact the use of our system for successful studies to be conducted. This was important to consider as similar issues could impact the acceptance and overall utility of an mHealth system.
Our initial technology trial was for 2 weeks, with questionnaires and interviews on participants’ background and experience (with both social media and quantified-self as well as with the RMA platform) before the trial, after 1 week (mid-trial) and at the end of the trial.
The subsections below are based on participant comments and feedback. Note that all the participants were ‘expert’ users: all have research expertise in either human computer interaction or computer systems design and implementation. For simplicity, only a simple Android remote notification was implemented and used for our initial trial. It is noted that this was changed in the real user study, i.e. both Android and iOS remote notification were implemented and used.
4.3.1 Personal devices promote personal engagement
We used a smartphone as a collection device. In instances where the smartphone was not the user’s main device, users were less motivated to maintain them due to their unfamili- arity. In our initial trial, Android phones were required in order to receive mobile push notifications. iPhone users were unwilling and uninterested to use, or perhaps had no knowledge of how to use the notification service, as the Android device has different in- terfaces and usage to the iPhone. So, it is better to provide users with native apps for their smartphone rather than providing custom, unfamiliar smartphones for use in mHealth ap- plication. (As a result of this feedback, an iPhone native app was built for users in the real user study.)
4.3.2 Personalised alerts are important
From our experience, notifications on smartphones became more important than the ac- cess to the main data in our trial. Since our app was web accessed, the Android app’s only function was for receiving notifications. Firstly, it is important to synchronise both Android notifications and in-platform RMA notifications (messages) since users expect to see consistency across asynchronous alerts when they access the platform. The access to RMA is normally triggered from the Android notifications received.
Additionally, for a buddy, it is not important to know exactly how many steps their client has taken at any point during the day. What is important is to know if their client has achieved their goal or not. Unlike an mHealth monitoring scenario, users want to re- ceive notifications more related to themselves. In mHealth monitoring, the family should be aware if there is any changes in configuration related to the monitoring of the patient. In our wellbeing trial, all changes in configuration for the buddy were not useful inform- ation for the patients. When users receive too many notifications which are not related to themselves, they do not bother to check them all and therefore may miss the important notifications.
Finally, the alerts for a patient-buddy pair indicating that the other user in the pair has achieved the steps goal (weekly goal, daily goal, threshold alert) are important. A patient also wants to know what changes professionals have made to a patient’s health/fitness regime configuration. It is not interesting for a patient to know what professionals have done to the setting of a buddy’s account.
4.3.3 User interface familiarity impacts usage
The exposure to the Fitbit native app does have an influence in how users utilise and access the RMA platform. Since our implementation provides a sub-set of information to the patient, compared to the native Fitbit app, the latter is better to visualise the data, i.e. provide more detailed statistics of steps data and a more polished user-oriented interface. A comparison between the RMA platform and Fitbit native apps functionalities is also
presented in Section 4.4.1.
Our RMA platform was better for sharing data, getting alerts from people in the carer network, and providing implicit motivation and a community feeling that users’ data are being shared and monitored in the carer network. However, when people were neither interested in the social part of the platform, or do not like sharing their data, the use of RMA is limited only to the use of alerts. However, as discussed above, this is an important function within the RMA. We found users would access their steps data using the Fitbit native app, and use the RMA platform only to monitor alerts, i.e. whether there are any new messages from professionals or whether their client or buddy has achieved any goals. Of course, in a real mHealth scenario, such a separate portal for the raw data might not be available, where a specific medical measurement device or sensor was in use. However, this does show that users are willing to share wellbeing data for purposes related to health.
4.3.4 Not everyone wants to share socially
In this trial, we experienced that the background of participants in already having used online social media and their subsequent sensitivity with respect to privacy affected how they used the RMA platform and configured specific settings.
We found that participants who were not already active users of social media, (i.e. were not interested in social aspects), were not interested in using the social aspects of RMA. RMA might provide users implicit motivation for being monitored and to work toward goals, but the platform might not be fully exploited by certain users who already have experiences, preferences or biases from other (non-)use of various social media.
For users who are sensitive to privacy and do not like sharing their data by nature, to have a community aspect may not be motivational, i.e. to have a buddy provides neither a competitive feeling nor a collaborative incentive. Therefore, there is no advantage of using RMA over the native Fitbit app for this kind of user, apart from the asynchronous alerts. In contrast, for users who are willing to share data in an online social context they may not pay much attention to privacy settings. So, we have used an opt-out system i.e. default is
to share.
4.3.5 The measurement device needs to be specific
The presence of the Fitbit device reminds users of their goals and the devices are easy to use, requiring little maintenance (they need to be charged only once per week). In the technology trial, the Fitbit One model1shown in Figure 4.3 was used, and is a very flexible wearable, e.g. it can be worn around the neck, carried in a pocket, or worn on a belt. It is also waterproof. However, it is not comfortable to use at night time. Since one of our aims is to measure the privacy issues of sharing sleep data, this could have a negative influence, i.e. the difficulty of using the devices could prevent people from measuring their data even if they are willing to share. For the user study, a new model – the Fitbit ChargeHR2shown in Figure 4.2 – was sourced for the larger study. The Fitbit ChargeHR is a wristband wearable, which also functions as a watch, and detects when the user is asleep automatically (the Fitbit One device needs the user to manually adjust the device when going to sleep). Additionally, it allows monitoring of the user’s heart rate. So the Fitbit ChargeHR was more comfortable, more convenient for use and provided additional bio- data (heartrate) for examining user preferences for privacy, as well as making a stronger link to medical monitoring.
Figure 4.3: Fitbit One device used as a measurement system in the technology trial to measure steps walked and sleep data. Device is approximately the size and weight of a USB flash drive. (Image from http://www.fitbit.com/)
1https://www.fitbit.com/uk/one 2https://www.fitbit.com/uk/chargehr