Create automatic background recording of interview in Collect

odk-collect

(Tino Kreutzer) #1

What is the general goal of the feature?

  • The goal is to create a complete audio recording of the entire interview (or parts of it) for quality control purposes (and for eventual integration with NLP mechanisms). This is not feasible at the moment as training interviewers to create parallel recordings in a different app and linking it with the correct interview is too complex.

What are some example use cases for this feature?

  • As a user I'd like to be able to record audio and submit them as part of the form without leaving the form page
  • As a survey administrator, I'd like to record entire surveys (or sections of a survey), not only single questions. The goal is to have a parallel audio file that would allow us to compare actual responses with how they were coded by the enumerator.

Feature details

  • The recording should be done in the background while the enumerator asks questions and receives responses
  • This should be a configurable setting (either at the form or app level-or both)
  • Ideally this should create separate audio files for each question instead of a single recording. New recordings could be started whenever the user swipes to the next question. This could be a setting as well, of course:
    Record entire interview (single file)
    Record separate questions/screens (several files)

What can you contribute to making this feature a reality?

Ideation, use cases, UX, potential funding.

NB: Obviously file size is an issue when submitting in some environments, but for this feature we should assume that sufficient bandwidth is available. A possible workaround would be a different Collect feature to submit without attachments, so that recordings can be copied offline without stopping regular submissions.


(Tino Kreutzer) #2

@yanokwa Are there any known technical reasons / Android OS restrictions that might prevent this feature from seeing the light of day? So far recordings are done outside Collect; not sure if this would require them to be done within the app instead.


(Yaw Anokwa) #3

The limitations I'm aware of are:

  1. Users must grant the application permission to record audio.
  2. Android 9 (API 28) or higher does not allow apps running in the background to access the microphone.

(Tino Kreutzer) #4

Thanks - that is super useful. Not being able to record in the background actually makes this feature more important, since for many enumerators the old method of recording with another app in the background while using Collect to administer the interview would no longer work.


(danbjoseph) #5

I think this is a good idea.

  • Would this feature just record audio, or would it record the phone's screen as well?
  • Would this be mostly automatic, something like an optional additional audit log feature?
  • Would it be like a question group with something like begin recording and end recording wrapping the question(s) of interest?
  • If a user leaves a question and then returns to the question, does the recording resume and append to the original recording?

(Tino Kreutzer) #6

Great questions, Dan!

  • No need to record the screen from my perspective. We know what the questions are and which responses were chosen from the dataset.
  • Yes, it should be automatic so enumerators don't need to remember/can't forget to record when required. Another optional setting would be to only record segments randomly, especially if bandwidth is a major issue (see above).
  • It could be a setting for the whole interview or a flag set at the question or group level
  • It could either 1) append to the first recording, 2) start a second recording, 3) do nothing. I would prefer (2) since joining files can be done later as well.

#7

Thank you @Tino_Kreutzer for bringing this up!

I'll add that this would be an incredibly valuable feature. From my point of view, the most useful would be to have a single recording from beginning to end of the data collection process. But I see how recording for specific questions, with separate file for each section recorded, would be useful as well. So @danbjoseph's suggestion of a begin recording and end recording wrapping sounds like a convenient and flexible way of dealing with this.