Figure 5.16:Simplified architecture of the Jeeves platform
5.4.4 Designing for security
A design requirement inherent to ESM apps is the security of sensitive participant information in both transfer and storage. Such information includes the participant’s personal details, as well as their self-report responses. As one layer of security, the desktop and mobile client operate a public/private key protocol, so that participants’ information and their survey responses can only be read by the researcher who designed and launched the study. While other researchers may still be allowed access to the study specification and survey questions, the responses of the participants assigned to that study will be encrypted from an outside perspective.
5.5 Platform Overview
Figure 5.16 illustrates a simplified architecture of the Jeeves platform. In this section, the functionality of Firebase and the semi-structured representation of studies will be briefly introduced. The use of Firebase is justified with regards to the design requirements addressed at the beginning of this chapter.
5.5.1 Firebase
Firebase12 is a platform for developing mobile apps, which includes a real-time database
that allows data to be synchronised across multiple devices on different platforms. Study specifications and participant data are stored in the Firebase online database, and transferred between researcher and participant clients using secure HTTP. Firebase has libraries and API documentation that allow it to be integrated easily into the Android and Java implementations. Features of Firebase that support it as a solution for Jeeves are as follows:
120 CHAPTER 5. DESIGN OF JEEVES
• Real-time synchronisation: Firebase allows survey data uploaded by participants with JeevesAndroid to be delivered to Jeeves instantly. Additionally, any updates to a study made with Jeeves get instantly delivered to JeevesAndroid participants, enabling real-time monitoring and modification.
• Offline storage: Participants may not always be online when completing surveys, or when studies have been updated. Firebase allows data to be stored in a participant’s smartphone cache to be uploaded, and study updates to be synchronised, as soon as a reliable network connection is available.
• Semi-structured data:The Firebase database is a NoSQL database, which stores data in a semi-structured, JSON-like representation. This allows dynamic additions and modifications to be made to Jeeves without major reformatting of the database structure. Dynamic updates support a meta-design approach, where changes are continuously made in response to end- user feedback. Examples of the semi-structured data of a Jeeves study specification, and of a particular participant, are shown in Figure 5.17.
• Security:Firebase has a set of security protocols for authorisation and authentication of users. In addition, a declarative security model is provided, allowing developers to customise access based on user identity. As an example use, this could allow particular study specifications to be kept private to a researcher, while allowing others to be public for collaboration.
• Storage: Firebase has storage support for images, audio, video and other media. This functionality allows multimedia to be presented to participants, or for participants to capture and upload their own media, such as photographs or audio recordings. Firebase Storage is currently used to present images to participants during surveys, including participant information sheets and consent forms.
In summary, Firebase is ideally suited to a remote ESM study application, and has saved significant work, as opposed to manually implementing a complete, custom server solution. Security, real-time synchronisation, media storage, and offline capabilities are all key benefits that should exist in any EUD-ESM tool’s server-side platform. However, the extensibility of Firebase makes it particularly useful with regards to meta-design.
5.5.2 Update procedure
The Jeeves visual specification is synchronised with JeevesAndroid to support real-time study modifications. As with all data in Jeeves, each trigger is stored in a hierarchical JSON-like structure, an example of which is shown in Figure 5.18. Each trigger has its own unique,
5.5. PLATFORM OVERVIEW 121
Figure 5.17:Semi-structured project data (left) and participant data (right)
122 CHAPTER 5. DESIGN OF JEEVES
randomly generated ID, as well as a list of the attributes it contains (in this case,BeginDateand Sleep time). This attribute list is required for when a participant updates an attribute value, as will be explained in this section. There are two ways that the logic of a study specification can be updated, by either the researcher or the participant.
5.5.2.1 Researcher updates the trigger hierarchy from Jeeves
1. In the Java implementation of the Jeeves visual programming environment, each block has listenerson its various receivers and input widgets. When a single change is made to any receiver or widget in the hierarchy, this change propagates to the trigger’s listener, which then generates a new unique ID. For example, in Figure 5.18, changing the conditional value of Glucose from 14 to 15 will generate a new ID for the entire trigger.
2. The Firebase Android API allows listeners to be registered on different parts of the database. In JeevesAndroid, a listener is registered to data of the study to which a participant belongs. For each trigger in the study, theTrigger Managerin JeevesAndroid registers a listener on each trigger, and adds it to a map structure, with the Trigger ID as the key.
3. Whenever the study listener detects a change, JeevesAndroid compares the study’s new list of trigger IDs to its current list, removing old listeners and adding new listeners as necessary. Thus, for simplicity, a completely new trigger listener is generated for the updated trigger specification.
5.5.2.2 Participant updates an attribute from JeevesAndroid
1. When a participant updates an attribute value, this can change how triggers will behave. In some cases, the value of the attribute is only used when the trigger fires (for example, in the trigger in Figure 5.18, the value ofGlucosewill be checked twice a day at random, as per the trigger specification). However, if the participant updatesBeginDateorSleep time, the trigger’s function is dependent on these new values.
2. In JeevesAndroid, all attributes are stored in Android’sShared Preferences, a set of persistent key-value pairs, where the key is the attribute name, and the value is the attribute’s current value. An additional listener is added to the set of Shared Preferences to check for any value updates made by the participant.
3. When an update is detected, the listener iterates through the app’s list of triggers. If any trigger is found that has functionality dependent on an updated attribute value, then a new
5.6. DISCUSSION 123
listener is generated for this trigger. For example, if a participant updates theSleep time attribute, then this will create a new listener on the updated trigger.
5.6 Discussion
The implementation of Jeeves represents the synthesis of literature related to experience sampling, and guidelines for visual programming language design. Jeeves therefore serves as a tool that can be used to answer the research sub-questions introduced in Chapter 1. As a visual notation representing an ESM study, Jeeves can be used to communicate ideas to researchers and clinicians, and to understand the usefulness of such a tool, without need for interaction. Further, as a visual programming language that can bewrittenas well asread, factors related to usability can also be evaluated. Finally, as a full platform consisting of the Jeeves visual programming environment, JeevesAndroid app, and surrounding architecture, it can be evaluated by researchers in practical applications outside the constraints of a usability study.
5.7 Chapter Summary
This chapter discussed the design decisions that were taken into account during the implemen- tation of the Jeeves platform, with particular focus on the visual programming environment. From analysis of existing EUD-ESM tools, as well as recent trends in psychology and medicine, a number of requirements for future EUD-ESM tools were derived. These requirements were described in relation to the blocks-based programming paradigm, the design of which was further described in relation to the Cognitive Dimensions of Notations, and the Physics of Notations. Finally, an overview of the Android app and overall platform architecture was provided.
While design principles derived from previous work, or those already empirically validated, can guide the creation of software that is likely to be usable and learnable by its stakeholders, there is no guarantee that this will be the case. Chapter 6 describes the formal usability evaluations that have therefore been conducted with the Jeeves implementation described.
6
CHAPTER
SIX
USABILITY
ANALYSIS
Ideas in this chapter have been published in the following papers:
D. Rough and A. Quigley, “Jeeves - a visual programming environment for mobile experience sampling,” in Visual Languages and Human-Centric Computing (VL/HCC), 2015 IEEE Symposium on, pp. 121–129, IEEE, 2015.
D. Rough and A. Quigley, “Jeeves - an experience sampling study creation tool,”BCS Health Informatics Scotland (HIS), 2017.
Perceived ease-of-use is a key factor in the acceptance of technology, exemplified by models introduced in Chapter 1. Furthermore, sets of guidelines for future experience sampling applications advocate allowing researchers to easily create and modify these studies themselves, independent of professional programmers. However, none provide specific details on how this could be achieved. Conversely, a wealth of usability research exists on different visual programming paradigms, including diagrammatic and blocks-based programming, as well as end-user development in general. However, the usability of a programming paradigm, and its encompassing development environment, is heavily dependent on the domain in which it is applied. This chapter thus aims to address the research sub-question related to the perceived ease- of-use of the Jeeves environment, specifically: “How can the development effort be reduced to allow rapid creation of experience sampling apps without requiring programming experience?”
126 CHAPTER 6. USABILITY ANALYSIS