Create automatic background recording of interview in Collect

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.

@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.

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.

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.

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?
2 Likes

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.

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.

Got to this discussion after raising a similar issue here https://community.kobotoolbox.org/t/is-it-possible-to-use-2-widgets-parallel-at-the-same-time/5176/3.

So, if having audio recording in the background is an Android Limitation, would that background execution be possible in the case of other types of widgets, more specifically, would this background procedure be possible for GPS data (lines)?

Thanks

It may be of interest that the audit log can be configured to record location:
https://docs.opendatakit.org/form-audit-log/#location-tracking

When recording within the geotrace widget the survey needs to stay on that question's screen. I don't think you can have a geotrace and audio widget running at the same time. Are you able to have 2 survey devices for the interview?

Thanks for your suggestion.

Yes, I can, but than that is no different than using two apps (ODK for geotrace and some audio recorder) in one single phone.

I see your point, and for my corner use case it should work. Anyway I see this idea of of allowing certain widgets to run in the background as an interesting development for ODK.

Cheers

For reference, the old issue #24 on Github and some previous posts also discuss this feature, though things moved on in favor of the audit and location tracking.

I believe the major change that would need to happen to implement this feature would be to record sound natively within Collect--rather than depending on an external app such as RecForge. This means this change could apply for the existing per-question recordings as well as the future background recording feature. Some thoughts on the implication:

  • A user should be able to choose between the internal and external recording methods (since external apps will always have more bells and whistles)
  • The advantage of recording natively is that users wouldn't depend on external apps (esp. the need to purchase RecForge Pro for > 3 min recordings) and their challenges (see e.g. 1, 2, 3, 4)
  • Users would need to grant the permission to allow recording audio
  • Users would be less likely to make mistakes trying to record audio through external apps

I suggest that this is a per-form setting to allow recording (audit) the entire form, not for specific sections (which quickly gets complicated when users move around the form, see this comment. It should be the survey administrator setting this so that enumerators don't have to activate it. For example:

type name label appearance
audit_audio audit_audio record=TRUE sampling=44khz
..
survey

In Collect there could be a new setting to disable audio auditing (or to disable uploading audio files with the submission), even if a form requires it. This may be important if someone is collecting data in a remote area with particularly bad connectivity. For example:

4 Likes

+1 to the idea of an audio_audit as an additional tool alongside the excellent audit log.

I really like this proposed feature.

I think having the flexibility to wrap questions of interests (I guess no nesting would be allowed) or to set a maximum time for the recording (or until form is closed) would be really nice.

Would a full audio recording of the entire interview work for your use case @dr_michaelmarks? Could you describe your specific use case?

Even if we record the entire interview (e.g the way I proposed above), timestamps from the audit feature can mark exactly where each question (screen) starts and ends, so extracting audio for only specific questions would be possible that way.

Another option would be to require audio for the survey, but then add a per-question parameter that would explicitly require audio only for those questions.

My feeling is this would be more difficult to implement but I understand how it could be important for some use cases.

Full recording would be fine.