Features and limitations

As a result of this review, the need arises for an intuitive, empowering solution that allows researchers to create, deploy and collect rich data from their own ESM studies from beginning to end, with full flexibility to adjust their studies without the constraints of a commercial system. Useful features identified in the previous chapter were chosen as comparison measures across the existing EUD-ESM tools. The presence, or absence, of the capacity for tools to support these features are discussed as follows.

4.2.3.1 Implicit Context Triggers

Tools that enable specification of context-contingent sampling schedules, identified as a particularly useful feature in both psychology and clinical research, present limited functionality. While the commercial toolsLifeData,MovisensXSandEthicaDataenable the GPS tagging of self-reports, none of these tools appear to enable researchers to trigger based on this location, or indeed other sensors. EthicaDatadoes provide an API through which developers can create and link their own trigger functionality, but doing so requires Java programming experience. As open-source software,AWARE andOhmagecould be programmed to enable sensor-based triggering, but do not include this functionality in their available state.

Of the tools that allow context-contingent sampling,Sensusis perhaps the most diverse in its triggering capabilities, supporting external devices as well as a range of built-in sensors. The interface for defining trigger conditions withinPartSadditionally provides user interfaces that

80 CHAPTER 4. END-USER DEVELOPMENT

Figure 4.5:The “event pattern editor” ofPartS, allowing combined trigger conditions

enable combinations of trigger conditions, as shown in Figure 4.5. In this example, a trigger is being defined that fires when a WiFi network is detected at a particular time of day.

4.2.3.2 Explicit Context Triggering

None of the tools surveyed allow forexplicit context triggering, that is, performing actions that are contingent on attributes of a participant, derived from responses to surveys, for example. Such functionality would be necessary in order to provide tailored intervention feedback to participants. However, self-report data in all reviewed tools cannot be interpreted by the apps themselves, such that any intervention would need to be triggered by the researcher manually after reviewing participants’ data.

4.2.3.3 Preference Tailoring

Similarly, as evidenced by Table 4.4, functionality to automatically tailor ESM to the preferences and characteristics of individuals is not currently supported in EUD tools. In usingESP, one of the first examples of electronic ESM, study-specific PDA devices were manually programmed to account for participants’ waking and sleeping times. Although tailoring to participants’ schedules can improve compliance [103, 104], manually doing so is a burdensome process for researchers, and inflexible to changes in participants’ schedules. OhmageandPartSallow participants to set their own reminders, but researchers have no flexibility to add other customisations.

4.2.3.4 Two-Way Feedback

Communication functionality is understandably limited in existing tools. Given the requirements of anonymity and consistency inherent in ESM research studies, direct researcher-participant

4.2. END-USER DEVELOPMENT OF ESM STUDIES 81

communication has potential ethical implications, and biased communication delivered to some participants, but not others, could bring the validity of collected data into question. Some tools enable study information messages to be sent to all participants, but with no way for these participants to provide feedback, or to have individual interactions.

Nevertheless, as a participatory sensing platform,PartSsupports two-way communication as a motivational incentive for participants. Such functionality is supported by feedback from an end-user evaluation by the platform’s authors, which showed that participatory sensing researchers had“a significant degree of interest in maintaining contact with other participants or researchers”[101, p. 496]. This suggests that, while an uncommon feature of experience sampling studies, its applicability as a means to increase compliance and obtain feedback on a study during its course could make it highly desirable in certain contexts of use.

4.2.3.5 Creation Interface

The interface for configuring ESM specifications most frequently comprises web forms, which abstract over a semi-structured language description. As discussed in Section 4.1, this is defined as “programming by specification” (PBS). Such an interface provides a more approachable solution than the pioneering platforms mentioned previously, wherein researchers modify study specifications through plain-text or XML files.

Two notable exceptions are MovisensXSand PartS, which both utilise a visual programming environment that abstracts study concepts into graphical components. A visual approach can support end-users in configuring trigger-action behaviours, as demonstrated by Dey et al. in the development of theiCAPapplication [154]. BothMovisensXSandPartSemploy a diagrammatic visual language for editing studies. WhilePartSallows for simple triggers to be specified without linking the individual “event” boxes illustrated in Figure 4.5,MovisensXSrequires that the entire study is specified as a flowchart.

It is notable that none of the tools employ “programming by demonstration” (PBD) to any degree. While PBD is an intuitive means of demonstrating context-aware behaviours, as shown in tools includinga CAPpella[120],GALLAG Strip[137], andContext Studio[155], these are all examples of “private EUD” (development for personal use). In the development of apps for a range of participants, it is infeasible for a developer to demonstrate the personalised contexts of all participants in advance.

82 CHAPTER 4. END-USER DEVELOPMENT