Longitudinal Capabilities?

Feedback & Feature Requests
1

I am conducting a large longitudinal study, and I would like to be able to present everyone’s wave 1 alter list to them for wave 2, to see who has been retained/dropped etc. I imagine that this will probably be most efficiently managed as a hybrid process, potentially using other apps for some of the work.

But I wanted to check with you what is, or might in future be, available within Network Canvas to facilitate checks on past alters.

2

This is a feature that we know there is a significant amount of pent up demand for, and are definitely actively exploring. Unfortunately, at present we simply do not have the resources to implement a neat end-to-end solution.

Longitudinal data collection was very much part or our initial scope for the project, but it is extremely complicated to design a system that meets a wide variety of needs. Our initial ideas were based on on our “three app” model, where we expected Server would eventually be able to also send back data to interview devices. As it turns out, we now believe that moving to a cloud-based platform would be a better fit for most researchers. This would of course make longitudinal tractable, but it also requires a big multi-year grant to get it done.

In the immediate term, I do actually think it would be possible to implement a feature that would fetch an asset (in this case a network file) from a remote resource. This could be used to create a kind of longitudinal workflow, in the following way:

  1. You build a very simple app based around a web server. This web server listens for requests for a resource, and then replies with the JSON file representing a prior interview. To access a resource requires the request contain a specific key, as well as a unique participant identifier.
  2. We implement the ability to define a “remote” asset in your protocol, which should be fetched at runtime (during the interview). The functionality includes a “templating system” which allows you to include arbitrary data in the request, including variables from the interview itself. You build your protocol to include a new roster based on bringing in this remote asset.
  3. The interview begins with the interviewer entering the specific secret “key” on an ego form interface. Separately, the interviewer enters the participants unique study identifier. This must obviously be verified somehow (likely double entry, using our validation function).
  4. When you arrive at the new roster screen, the app uses a templating system to construct a URL to fetch the remote resource. Your server app responds with the interview JSON of the specified participant, and displays the roster.

The above is definitely doable, but would need to be implemented by an external researcher, or produced through a formal collaboration with the Network Canvas project team.