Regardless of which is chosen, the three relevant principles (complexity management, cognitive integration, and cognitive fit) will not clash with one another. However, these principles, as shown in Table 5.8, have not been applied in Jeeves, as they all require the ability for developers to understand the process of abstraction creation.
5.4 Android Application
Although the focus of this thesis is on factors influencing usability and utility from the researcher’s perspective, it is nevertheless important to address considerations for design of the corresponding Android app. The overarching goal of the JeevesAndroid app is to minimise participant burden, and design decisions have therefore been made in pursuit of this goal.
5.4.1 Overview
Participants in Jeeves studies use a native Android app referred to as JeevesAndroid, which downloads a study specification from an online database, the details of which are described in the next section. JeevesAndroid dynamically interprets this specification, setting up the necessary triggers, actions and surveys automatically, such that studies can be updated in real-time. Survey responses and participant feedback are similarly uploaded to the database in real-time whenever an Internet connection is available. While web apps are compatible with different smartphone operating systems, a native app provides access to all bespoke features of the device, increasing the flexibility of data capture and triggering possibilities. The utility of Jeeves could be increased by having an equivalent iOS app, enabling a greater number of participants to be recruited. However, for the purposes of this thesis, the focus is on the Android client, while future work could include an iOS implementation.
Implementing a native Android app has also enabled use of theEmotionSenseframework - a set of open source libraries for sensor data capture, classification, and trigger scheduling [172]. JeevesAndroid integrates the Sensor Manager and Trigger Manager libraries, which have simplified the implementation of context-aware functionality. TheSensor Manager provides a consistent API to sample data from a range of available sensors, at specified intervals and granularity. TheTrigger Manageruses the specified constraints of the particular trigger events, as well as stored characteristics and preferences of participants themselves, to determine whether to execute particular actions. By combining the two components, sensor-based triggers can also be implemented.
However, maximising compliance in both installing and completing surveys with JeevesAndroid is dependent on minimising participants’ burden in doing so. Compliance and attrition are
116 CHAPTER 5. DESIGN OF JEEVES
Figure 5.14:Left: Missed surveys screen. Centre: Main app screen. Right: Feedback screen
salient issues in the majority of experience sampling studies, and have been the primary factors influencing the following design decisions, related to efficiency, security, and battery life.
5.4.2 Designing for efficiency
As explained in Nielsen’s usability heuristics:“Every extraneous unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility”[173, p. 339]. With respect to this, JeevesAndroid is designed with a minimalist interface to increase efficiency. The main app screen, after a participant registers with a particular study, presents a simple choice of three buttons (Figure 5.14, center).
By tapping the “Complete Missed Surveys” button, participants can see a list of surveys that have not been completed, but have not yet expired, as shown in the leftmost screenshot of Figure 5.14. By tapping on a survey in the list, a participant can either begin the survey if it has not been initiated, or continue from their last answered question. For example, the top survey in the screenshot showsPartially completedto indicate that the participant has already entered answers for some questions. In summary, the goals were to provide simple navigation to postponed surveys, and to ensure that previously entered data did not have to be re-entered, thereby increasing participants’ efficiency.
The rightmost screenshot of Figure 5.14 shows the participant feedback screen. This section of JeevesAndroid allows participants to send and receive messages to and from researchers administering a study. Although delivery of personalised feedback to participants is at the
5.4. ANDROID APPLICATION 117
Figure 5.15:Left: Log Design pane of Jeeves. Right: Corresponding self-report screen on JeevesAndroid
discretion of researchers in their study goals, the one-way feedbackfromparticipants is useful from a meta-design perspective. Participants’ feedback during a study could allow researchers to adjust a specification to handle unexpected app behaviour, or request new features from meta-designers if an adjustment cannot be made.
Finally, the “Log New Information” button brings a participant to the screen previously designed by the researcher, as shown in Figure 5.15, right. Researchers’ interface widgets are currently presented on this separate screen, unlike the first implementation of JeevesAndroid where these widgets were appended to those on the welcome screen. Regarding Nielsen’s usability heuristic of minimalist design [174], a potentially high number of buttons and labels on the welcome screen could be initially overwhelming to a participant, potentially causing compliance issues.
5.4.3 Designing for battery life
Battery life is a primary concern for an app that will be continuously running in the background of a participant’s smartphone, potentially for many days or weeks. During the initial implementation of JeevesAndroid, it became apparent that manually coded functions for recognising activity, and detecting geofences, was inefficient and resource-intensive. However, continuous development of Google’s APIs have mitigated this, as described in this section.
118 CHAPTER 5. DESIGN OF JEEVES
5.4.3.1 Geofencing
A popular use of context-awareness in smartphone apps is to initiate actions when a user enters, leaves, or dwells in a particular location. As discussed in Chapter 2, such functionality can be used to gather further, contextually relevant information through a self-report survey, or deliver motivational messages at a triggering location. However, a smartphone’s GPS sensor is not designed for continuous sensing, such that even simplistic geofencing capabilities place a high demand on smartphones’ resources. To avoid this issue, JeevesAndroid uses Google’s Places API10, which provides a means of setting up geofences that minimise the use of the phone’s resources, at the expense of minor delays. Google’s classifiers employ a combination of sensors, including WiFi and accelerometer, to minimise resource consumption.
5.4.3.2 Activity recognition
Appropriate use of accurately inferred activity can significantly reduce the burden of an ESM app on a participant. For example, inference that a participant is driving could delay prompts to ensure that no accidents occur. A sudden change in acceleration can imply a transition between activities – an opportune moment to interrupt [84]. Additionally, recognition of particular activities such as running or cycling could prompt for self-report regarding a participant’s recent exercise. As with geofencing, however, continuous sensing of accelerometer data can be burdensome on the processing power of a smartphone. Google’s Activity Recognition API11 was utilised in
JeevesAndroid, to minimise potential battery drainage and resource consumption. The API employs power-saving strategies such as reducing sampling frequency when a device has been still for an extended period.
5.4.3.3 Data upload
When a network connection is unavailable, continuous attempts to upload data are resource- intensive, which is aggravated by the Jeeves design requirement of real-time synchronicity between researcher and participant. In the initial JeevesAndroid implementation, data upload to a custom-built server was configured manually, causing significant drain on smartphones’ battery life. In the current implementation, which uses theFirebaseonline database and API, data is stored locally until a network connection is established, significantly reducing resource consumption.
10https://developers.google.com/places/ Accessed 17/03/18