Road Map

Paco's goal is to provide the most advanced, most useful, open-source, behavioral science tools to promote experiential understanding

By enabling the creation and delivery of advanced behavioral science tools for researchers and individuals, we aim to speed the progress of behavioral science-based research and the discovery of field-vetted, theoretically-sound tools to help everyone understand daily experience better and hopefully improve quality of life.

##Quick Feature Overview What does that mean more concretely?

Paco should give researchers and individuals tools to easily build, deploy, and monitor experiments to study behavior and implement and evaluate behavior change theories.

• It should be easy to create a wide range of experiments to collect behavior and to offer behavior change protocols.
• It should be easy to deploy and monitor these experiments as they are running.
• It should be easy to pull the data out for analysis.
• Users should have informed consent and the ability to control if and how their data is shared.
• It should be easy to analyze data across multiple experiments.
• It should be easy to share data and experimental designs when appropriate and with permission in order to facilitate propagation of good experiments, replication of results, and creation of meta-studies.
• It should be easy to compare behavioral theories and protocols to one another by virtue of a common definition and execution platform.
• It should be easy to create visually exciting and nuanced behavioral experiments with a little programming ability.
• It should allow those who want to participate in studies and those who want to conduct studies to easily find each other.

Experiments

• Most experiments should require no programming. The webapp should allow users to specify the experimental definition graphically. This definition should include the following functions.

  What data to collect

  • first-person self-reported experiential data
  • sensor data (accelerometry, location, photo, audio, video, barometry, temperature, light, humidity, noise)

  When to collect data

  • time-based signaling, e.g., random, fixed, adaptive
  • event-based signaling, e.g., geo-fencing, activity on phone, changes in environment
  • compound compositions of those two mechanisms

  How to collect it

  • Active notification of users to participate and active questions to the user
  • Passive sampling of sensors

  What to do with the data

  • Process for later analysis
  • Provide participation statistics during experiments
  • Use to compute intervention protocol responses (adaptive or dynamic feedback)
  • Share with researchers, share with friends, keep completely private

Areas where we are actively working in 2014

Custom Experiment definition

It is also necessary to have a way to break out of the pre-defined experiment mechanisms to define more powerful behavioral experiments. To this end, Paco provides the ability to define the collection and feedback parts of experiments as HTML, Javascript and CSS. A web programmer can easily use the Paco API to create new input forms and new output forms. This quarter we are adding the default generated code to make it easier for users to do code by example and small modifications without having to override all parts of the experiment design. We will also be providing several example experiments that use custom rendering so that users can learn and copy our patterns.

This also requires some cleanup of the Paco javascript experiment api to be cleaner and more intuitive to use.

In the future, the full experimental definition will be adaptable while running. This would include the signaling mechanisms as well as the items being collected and how feedback is displayed to the user.

More Expressive Signaling Mechanisms

We are in the midst of refactoring the design of experiment signaling to allow composite or compound schedules and triggers to data collection. This will make it possible to define designs that currently require multiple experiments within one experiment. The most salient example is a design that uses a daily, randomized schedule (ESM) coupled with an end-of-day fixed-time schedule with retrospective questions about the random daily events. Currently, this must be defined as two experiments because the different groups of questions in each and the different schedules of each. This requires more work on the participants' part because they have to join two experiments and stop two experiments when it is really the same study. This new feature will make it possible to define one experiment with two different groups of inputs that have their own schedule.

The compound signaling allows multiple triggers to be defined to control how a user is prompted. For instance, an experiment may want to trigger when a user hangs up the phone or receives an SMS. This is two system events and currently requires two experiments. Instead, we will be able to specify that either signal triggers the user. Also, this allow us to set constraints on frequency of signaling for both types of events at once which is currently impossible.

Other minor features include adding geo-fencing triggering and iBeacon (or other ble or nfc device) triggering support.

iOS Feature Parity

The now-launched iOS version currently supports randomized scheduling (ESM) and fixed-time scheduling experiments but it does not yet support custom feedback or custom rendering.

UX Improvements

Based on User Experience Research studies of Paco and feedback from running experiments, we have identified several areas where the user interface for Paco needs to be improved. We will streamline the first-time use model for recruited participants. Streamline the use model for repeat users actively in experiments. We will streamline the website in a similar manner. We will redesign the experiment definition parts of the webapp. We will add new participant monitoring functions into the webapp, specifically, more break out of per-user data and response statistics.

Cleanup and reorganization of the way users Find Experiments

We will be adding tagging and full text search for experiments so that users can explore available experiments and make their experiments more easily findable by others. This is not a huge effort but has lots of UI implications.

Integration with more sensors for better triggering on Android

We currently integrate with the system services on Android to detect phone call determination and user presence and apps used. As well, we have a broadcast mechanism that allows us to receive events from other applications. We will be adding more of these sensor integrations both inside Paco and via auxiliary applications that allow touch point integration when it is not a feature that belongs inside Paco proper.

Background Sensor Polling

We will implement a background mechanism that polls inputs (sensors) and stores that data locally. Example polled inputs include geo (for building traces), app usage (for behavior pattern), motion detection (for activity), and audio sampling (for environmental levels and conversation participation). This will also supplant the current polling mechanism for process watching.

Add payment flow

Investigate integrating Google Wallet and in-app purchases to facilitate research payment. The goal here is to just streamline the usage model so that it becomes easy for a researcher to convert the participation stats directly into incentive payouts for participants.