The server will run the scheduling logic, and when the server determines that it’s time for the app to take a survey, it will send a push notification to the app, which will make the phone display a notification that it’s time to take a survey. The data in the push notification body will contain either the full survey content or a link that the app will use to download the full survey content as soon as it receives the notification.
• We will be able to run more complex scheduling logic, and this architecture will make it easy to add new types of scheduling logic in the future without requiring participants to update their apps.
• When a researcher changes a survey during an active study, those changes will immediately propagate to the participant phones. There won’t be any stale surveys stored on participant phones.
• Debugging survey notification problems will be easier, because we’ll be able to see the scheduling logic running on the server, and we’ll be able to keep records of when the server sent push notifications. However, this won’t make any change in how we record whether and when the phone received and displayed those push notifications.
• While it’s beyond the scope of this feature, this new survey scheduling framework would make it easier to eventually add a feature that tracks and displays (through the researcher’s web interface) each survey event that a participant should have received, what the survey content was on that survey event, and what the participant responded for that particular survey event.
The app currently allows surveys to be sent at specific times (with one-minute resolution) on specific days of the week- we’ll preserve that functionality. We’ll also add new survey schedule types:
• Surveys on specific calendar dates
• Surveys on relative dates: a specific number of days following participant enrollment, or a specific number of days following an “intervention” date, where the intervention date can be set to a different date for each participant
- Beiwe team