Experience Sampling Application Bayer, Katrin und Rodopmann, Erce | 24.10.2015

Experience Sampling Application

Bayer, Katrin und Rodopmann, Erce | 24.10.2015

Experience Sampling | 24.10.2015Seite 2

Inhalt

• A short follow up: Experience Sampling

• Experience Reconstruction Method

• Technical part: Development of an application


Follow up: Ambulatory Assessment (Trull & Ebner-Priemer, 2013)

Definition: AA represents „a methodological umbrella that encompasses (…) methods of experience sampling (…), ecological momentary assessment (…), and continuous psychophysiological, biological, and behavior monitoring”

Types of AA:• Self-report AA (e.g. Experience Sampling Method, ESM)

• Observational AA (e.g. Electronically Activated Recorder, EAR)

• Physiological AA (e.g. ambulatory ICG, BP) and behavioral AA (e.g. accelerometers)


Follow up: Experience Sampling (Trull, Ebner & Priemer, 2013; Bolger et al., 2003)

Experience Sampling is a methodological umbrella for collecting self-report data

• in daily real-world environments• current or very recent

• multiple assessments of each individual over time: event based (initiated by the individual based on instructions), interactive (initiated by physiological signals detected by monitoring devices), time based, randomly prompted (as well as combinations of these)

• measurement of “processes of interest” (e.g. mood, alcohol use) AND characteristics of the environment (e.g., location, time, social context)

• Useful for the combination with other methods (e.g. behavioral, psychophysiological)


Follow up: Two methods collecting ambulatory self-report data

Experience Sampling Method (ESM) (Csikszentmihalyi, Larson & Prescott, 1977)

Developed by Csikszentmihalyi

Day Reconstruction Method (DRM) (Kahneman, Krueger, Schkade, Schwarz & Stone,

2004)

Developed by Kahneman

For continuous ambulatory psychophysiological measurement: which one to use?


Existing ambulatory psychophysiological methods

Measurement of physiology:• Existence of various methods • Can be at specific time points (e.g. Hawkley, Burleson, Berntson & Cacioppo,

2003) or continuous (e.g. Houtveen & van Doornen, 2007)

But without context information, physiological data can’t be

interpreted (Wilhelm & Grossman, 2010)

Self-report data by Experience Sampling Method

At specific time points • Houtveen & van Doornen (2007): every 1,5 hour• Loeffler, Myrtek und Peter (2013): every 10 to 20 minutes

No continuous context information without many interruptions:

data loss or many interruptions


Existing ambulatory psychophysiological methods

Self-report data by activity diaries (Vrijkotte, van Doornen & de Geus, 2000, 2004; Riese et

al. 2003):• At specific time points, e.g. every 30 minutes• Report about the last 30 minutes concerning time, activity,

position, amount of alcohol, coffin and cigarettes

Continuous context information, but without a psychological

variable

Need for a strategy, collecting continuous self report data for context information and a psychological variable without many interruptions


The Experience Reconstruction Method (ERM)

Experience Reconstruction Method

• Is one method under the umbrella term Experience Sampling• Was developed in the Department of Social Psychology, University of

Ulm• should be a method collecting

• Ambulatory and continuous self-report data• Without data loss and less recall bias• For the combination with continuous physiological data

combination of Experience Sampling Method and Day Reconstruction Method = Experience Reconstruction Method


Experience Reconstruction Method

(Dis-) Advantaged of ESM / DRM for the combination with physiological measurements:

Combination of the advantage of an accurate, chronological and continuous report (DRM) with the less recognition biased structure of the ESM

ESM DRM

Momentary Without interruptions

Less biased Accurate and continuous

Interruption for participants Only one a day

Data loss biases


Experience Reconstruction Method - procedure

It’s like DRM with some modifications:• Sampling by smartphones• A signal every 60 minutes (Two reminding signals after 10 minutes each)

• Reconstruction of the last 60 minutes / until the last answered signal

• Questions about• Amount of episodes• Start and end of the episodes• All and main activity/activities• All and main position/positions• Amount of coffin• Interesting psychological variable



Application starts with • Demographic variables• Whole iteration of one questionnaire• Next ‘real’ signal 60 minutes after starting time

Procedure of a questionnaire:

1. Amount of Episodes

2. Start time of episode 1

3. End time of episode 1



4. What kind of activities have you done in episode 1? (multiple answers out of 16 categories)

5. What activity have you mainly done in episode 1? (single answer out of the previous)

6. In what position were you in episode 1? (multiple answers out of 4 categories)

7. In what position were you mainly in episode 1? (single answer out of the previous)

8. Have you consumed coffeine? Yes or no?

9. Five items about the feeling and interesting psychological variable



Procedure of a questionnaire:

1. Amount of Episodes

2. Start time of episode 1 2

3. End time of episode 1

4. What kind of activities have you done in episode 1? (multiple answers out of 16 categories)

5. What activity have you mainly done in episode 1? (single answer out of the previous)

6. In what position were you in episode 1? (multiple answers out of 4 categories)

7. In what position were you mainly in episode 1? (single answer out of the previous)

8. Have you consumed coffeine? Yes or no?

9. Five items about the feeling and interesting psychological variable


Experience Reconstruction Method: But what kind of tool?

Sampling by smartphones -> need for an application which is:• Flexible: not like classical experience sampling• Adaptive: with different number of repetitions

Until now such a tool is not available

Project of developing an Experience Sampling Application which can be used for any combination of various ambulatory methods collecting self-report data


Structure of this Presentation

• Some Technical Terms.

• Who are we.

• Motivation and Limitation of Given Software Solutions.

• Overall Structure and Architectural Decisions.

• Where are we.

• Some Technical Details.

• Perspective and Current Timeline.


Some Technical Terms (1)

OS:

Operating System (e.g. Windows, Android, IOs).

Plattform:

A Croncrete and Given Technical Infrastructure (OS + Hardware + „used Technologies“).



Software Design and Software Architecture:

The Inner Structure of a Software Product from a Programmers Point of View.

Both Terms Can be Seen as Synonyms Though they are Differing in Some Respect.



User:

Anybody who Uses the Software Product. Here: Both, Participants and Researchers.

GUI := Graphical User Interface:

Everything a User Sees and Interacts With While Using the Software Product.



User Story:

A Standardized Sentence That Defines a (= One) Functionality. It Is Written for Humans and Should be Understandable for Both Developers and (Later) Users.

Structure and Example:

As a [Role] I want to [Goal] in Order to [Aim]

e.g.: As a Researcher I Want to be Able to Add Slides and Questions In Order to Make Up a Questionaire.



Assessment Testing:

Generally Speaking:• The Sum of All Requirements (~ User Stories) Requested and to

be Met by the Developers.• The Process at the End of Each Programming Phase where

„Clients“ Check if Requirements were Met.

German Translation: „Endabnahme“.


Who are we

Alexander Pöschl

• Bachelor Thesis (Computer Sciences)• Console Application

Willi Döhring:

• Bachelor and Master Thesis (Computer Sciences)• Android Application

Haluk Erce Rodopman

• Employed Programmer• Project Management, Architecture, Administration, Refactoring, etc.


Motivation and Limitation of Given Software Solutions

Domain Specific (Psychological) Motivation (S. Diefenbacher, K. Bayer).

Given Software Solutions Didn‘t Offer Requested and Envisioned Functionality.


What were the (main) Limitations

• Reduced and ‚out of date‘ OS support.

• Minimalistic Functionality which did not meet Requests.

• Buggy Implementation with Poor Support.

• Dead Projects.

• Serious Data Security Concerns.

• No Given Software Solution Allowed the Requested Flexibility and Control Over Timing.

AND ...


All Ready-To-Use Solutions were Closed Source Implementations.

Therefore:

• Not Extensible (e.g. Timer).

• No Way to Debug.

• Impossible to Port Given Solutions to Contemporary OS versions.

• Slow to No Development Due to a Lack of Human Resources.

• Practically No Significant Documentation (Source Code).


Overall Structure and Architectural Decisions

• Project Guideline.

• Overall Structure.

• Architectural Decisions.

• Architectural Restrictions and Limitations.


Project Guideline

Open Source and Free Software (GPL v. 3).

Userfriendly Creation of Simple Studies.

Ability to Create Complex and Very Specific Studies by Experienced Developers.

Userfriendly Investigation of Study Results.

Possibility to Port On Any Available OS and Plattform.

Control on Timing.

Greatly Inspired by „PsychoPy“ (Hands-on).


Overall Structure

Online Data Base

Administrative Console

AppAppApp

Questionaire Design Results Questions Results

Results

Build


The Build Process

Two Options are Given for the Build Process:

• Compile to App:

• This Applies to Simple Studies.

• Prepare a Project Map:

• For Complex Studies.• For Adding New Functionality.


Architectural Decisions

Pros Cons

• Allows a Central Unit for Administration (Console).

• Flexibility.

• Full Control Over Data.

• Individual Control Over Each Study.

• Reliable Result Storage.

• Requires Network Access.

• Requires Advanced Programming Skills for Complex Studies.

• Full Responsibility Over Data.

• Each Study is Implemented as an Individual App (per default).

• Potentially High Energy Consumption.


Where are we

- Currently the Project is „Preliminarily Implemented“ (~ pre-alpha).

- Ca. 45.000 Lines of Code (Just Below „Enterprise Size“).

- 3 Seperate Programming Branches.


Overall Structure

Online Data Base

Administrative Console

AppAppApp

Questionaire Design Results Questions Results

Results

Build


Where are we

- Implementation of Most Functionality.

- Exception: Build Process.

- Android Implementation of Most Functionality.

- Main Exception: Data Base Controlled Timer.

Preliminary Implementation of Missing Functionality is Scheduled for November the 15th.


Some Technical Details

• Programming Details.

• Implementation Details.

• Project Details.


Programming Details

- Data Base:

- MySQL.

- Console:

- Currently Implemented in Java. Will Switch to Scala.

- (Android) App:

- Android Studio (~ Java).- Local Data Storage: SQLite.


Implementation Details

- Data Base:

- Communication Will be Provided Through JSON / PHP.

- This Part Will be Deployed as an Appliance (either docker.io or vagrant or both).

- Console:

- Will be Deployed Stand-Alone.


Project Details

- ‚git‘ Based.

- Repository Will be Either Self-Hosted (gitolite) or Hosted on github.com After Announcement.

- Console Will use ‚sbt‘ for Building.

- (Basic) Testing Will be Provided Through ‚xUnit‘ and ‚ScalaTest‘.


Perspective and Current Timeline

• Perspective.

• Current Timeline.

• Request For Help.

• Contact.


Perspective

- Implementation for IOs.

- Implementation For PCs.

- Simple Questionaires (Without Timing).

- Internationalizability (One App That Serves for a Range of Languages and „Alphabets“).

- Further App Widgets.

- Katrin Bayer Will Join Our Team (Domain Specialist, Project Owner).


Current Timeline

- 02.11.2015: Start of IOs Implementation.

- 15.11.2015: Functional Freeze; End of Preliminary Implementation (Console, Data Base and Android App).

- 15.11.2015 ...: Final Implementation and Refactoring.

- ~ January 2016: Alpha-Release.

- ~ January / Febuary 2016: Announcement.


Request For Help

After Announcement We Would be Glad to Receive Help by:

• Testing.

• Using.

• Programming Support.

• Provision of ‚User Stories‘ (~ Requests for New Functionality).

• Advertisment ;-)


Contact

• Technical Contact:

• Me: [email protected]

• Domain Specific Contact:

• Katrin Bayer: [email protected]

mailto:[email protected]

mailto:[email protected]

Documents

Experience Sampling Application Bayer, Katrin und Rodopmann, Erce | 24.10.2015