1. What is the general goal of the feature?
In a nutshell:
- For longitudinal ODK Collect projects, allow one parent form to run in the background while filling in the other child forms.
- Allow recording a geotrace in the backgrounded parent form while filling in other forms (with their own geo widgets).
- Allow several projects in ODK Collect, each with their own modes (longitudinal or opportunistic).
In long form:
This is a write-up of a typical workflow that might work better as an entity-based data capture workflow.
This follows a discussion I've had with @LN on EBDC. Naturally, my example will be turtle flavoured.
For the past five years, I've used ODK on a field campaign that monitors turtle nesting beaches and uses the non-EBDC, "classic" ODK to capture nested entities.
Field sites (here: monitored turtle nesting beaches) are the light blue polygons as seen here. Substitute your own concept of "study site".
Our nested entities are:
- The survey: site visited, time started, time finished, person in charge of data capture, other persons present, photo of site at start, photo of site at end, comments on any environmental factors influencing data capture before and after survey.
- Encounters: observations of things (turtle nests, stranded turtles, footprints of predators, general disturbance, etc) are individual records, captured in individual forms, in the unpredictable sequence of how and where they are encountered.
The survey information is currently captured in two separate records, one "Site Visit Start" and one "Site Visit End" record. From these we reconstruct surveys and link them with the encounters. This is how we think downstream of the combined and nested entities (names hidden).
Ideally, we want to provide two data capture modes, survey and opportunistic.
In "survey" node, we want to:
- Enforce that a survey begins with a "Site Visit Start" record. These are too easy to forget.
- Capture the walked geotrace in the background. This is a good measure of area covered and could be used to correct statistical models for survey effort. In contrast to audio background recording, the geotrace should span the filling of several forms.
- The geotrace could be part of the "Site Visit Start" form running in the background.
- Enforce that a survey ends with a "Site visit End" record.
- It would be OK to fill in separate survey start and end forms, it's more important to make sure that our enumerators don't forget them.
- It would be OK to have the observations relevant to the Site Visit End point entered into the Site Visit Start form parked in the background.
So, we want to fill in individual forms for each encounter, but also want the survey to somehow span across the encounters within. We don't want one gigantic forms with nested sub-groups, as the individual forms are already nested with repeats, and messing up the one gigantic all-in-one form would mean losing the entire survey.
In "opportunistic" mode, we want to:
- Allow opportunistic capture of encounters with stranded/injured/entangled wildlife. This ODK form also participates in the survey mode.
2. What are some example use cases for this feature?
- Background geotrace across forms: useful to estimate survey effort, as in area covered with eyes open.
- Hierarchy of forms: enforce the parent form (survey = site visit start/end) to be captured while letting child forms (encounters) be captured as needed.
The user experience could be like this (I'm not a UX designer, bear with me):
-
Start ODK Collect
-
A new top-level main menu shows available projects (each in different modes):
- Marine Park Ranger (opportunistic mode, non-longitudinal)
- Turtle Nesting Census (survey mode, longitudinal)
- Form management (edit/send/get new/delete old)
When I select "Marine Park Ranger", I see the forms I can fill in.
When I select "Turtle Nesting Census", I see:
- The top-level/parent form ("Survey"), but all other nested/child forms are hidden.
- I can start the Survey form, enter the "Site Visit Start" fields and start the geotrace capture (or it starts automatically in the background).
- For the geotrace, I would want to configure capture parameters (frequency and minimum accuracy) in the form definition.
- At an exact point in the form, I can "park" the still running "Survey" form in the background using a new "park form" widget.
- The wording for the "park form" button should be defined in the form definition.
- Once the parent form is parked, I see the list of child forms (encounters) available to fill in, and an option to "end survey".
- The wording for "end survey" could be more generic, but ideally configurable by the form designer.
- I am able to fill in as many or as few of the child forms as required.
- The option "end survey" brings me back to the top level "Survey" form, where I stop the geotrace and fill in the "Site Visit End" fields, then save.
- The various encounter forms capture a reference to the top-level survey form (maybe the survey form instance UUID). I can use these to link encounters to the correct survey as an alternative to using the spatial and temporal overlap between the forms.
In ODK Central, longitudinal campaigns (subsets of forms within an ODK Central project) could show their submissions in a nested fashion similar to the second screenshot above.
ODK Central (or the XForms definitions) would need a way to designate parent and child forms.
Child forms wanting to store a parent form submission UUID would need to inject these into the form metadata.
I still want to be able to use forms across several campaigns, e.g. as a child form in longitudinal campaign 1, but stand-alone in opportunistic campaign 2.
3. What can you contribute to making this feature a reality?
UAT, test implementations in XForms, some example analysis and visualisations of the captured data using ruODK.