ODK TAB Call - 2021-11-10

These calls bring together the Technical Advisory Board for the ODK suite (@TAB) to discuss roadmaps, working groups, and other issues of technical governance. Everyone is welcome to come to these calls, but only TAB members may talk.

The calls are held every four weeks in our Dialpad room. We put the agenda, audio, and transcript of every call in this document.

Our next call will be Wed, ENTER_DATE_ONLY_HERE. The meeting time should be shown in your timezone above.

The agenda is tentatively as follows:

Facilitator: @chrissyhroberts
Note taker: @Tino_Kreutzer

  1. Introduction

  2. Warm up

  3. Agenda review

  4. Review action items from last meeting

  • @yanokwa was going to look at Aug 18 notes and ask questions (re: TAB activities, risks to the project)
  • @yanokwa thought that @LN had a sketch and spec for Collect grid view. Was going to try to find and share.
  • @yanokwa to triple-check with the team about Briefcase API depreciation.
  1. Roadmap check-in
  • Several Proposed Briefcase things may be removable
  1. +/Δ
  2. Next meeting date (time is always 1700 UTC)
  3. Review action items

The agenda can also be seen in the agenda document

If there are topics you would like to add to the TAB's agenda, please comment below. :point_down:

1 Like

I do have some spec concepts I’ve worked through but when discussing them with @seadowg and @eyelidlessness they brought up a lot of great questions about the user experience. Grids bring value to paper forms because they enable things like verifying that rows or columns add up. Most of what we can think of that requires context can be automated in an ODK form. Having to tap into cells and have a keyboard pop up is not a great experience on touch devices, even ones with large screens so the benefits have to be significant. We’d want to do user interviews and user testing before proceeding so this is again on the back burner. Will be interested in reading what you all discuss. It seemed like a slam dunk addition to me but having thought about it more I’m not as sold. If you have examples of grid interfaces that you have found helpful on mobile, that would be good to look into.

My ideal UX for grids are click counters of things in 2 by 2 categories.

My concrete example are turtle tracks. While I'm capturing a geotrace in the background, I walk along a beach and tap to add one count to a relevant cell. My columns are turtle species, the rows are types of tracks.

I want to use each cell as a click counter (value plus one) and also be able to correct a misplaced click (value minus one). For this, I need to see the value (an integer number), a large plus button and a smaller minus button.

1 Like

This is the case discussed here :

So it would be really useful for such species list monitoring (punctual/linear abundance indexes)

1 Like

In my experience when people ask for grid views, they mean one of two things.

  1. The first is a true grid based data entry, like the one @Florian_May described. Here you have different fields in grid positions and the orientation in a grid format is simply a device to simplify data entry and reduce the currently very substantial need to be swiping all over the place when there's lots of options. Grids are essentially just very efficient.

Example 1 : Turtles

Track type 1 Track Type 2
Turtle species 1 1 [+][-] 0 [+][-]
Turtle species 2 12 [+][-] 25 [+][-]
Turtle species 3 3 [+][-] 5 [+][-]

Example 2 : Visual acuity measurements of left and right eye in a single individual

Left Eye Right Eye
Visual Acuity 0.7 0.4
IOP mmHg 12 25
CD ratio 0.3 0.8

In example 1 the data entry tool (the clicker) is really simple so lends itself well to phone based data collection

In example 2 the popup keyboard, number pad, drop-downs or scrolling would be needed, but this would not necessarily be a horrible thing, especially if using a tablet (which is our normal for most fieldwork).

  1. The other type of grid people ask me about is really a way to present repeats side by side in a single view (let's assume we are using a tablet here because there's a need for serious screen real-estate)

Example 1 : A daily clinical observations form

Time of assessment HHMM HHMM HHMM
Temperature 39.0 38.4 37.0
Respiratory Rate 88 76 60
Heart Rate 120 110 90
LOWEST Consciousness (AVPU) A A A

Example 2 : A household structure survey (note here the repeats go down, this is abitrary)

Age Biological Sex Tb infection
Person 1 44 MALE ACTIVE
Person 2 49 MALE ACTIVE
Person 3 15 FEMALE NONE

Example 1 has the benefit that a clinician can look at the patient's progress over time. It works best when the number of repeats is fixed, or you'd need a scrolling canvas!

Example 2 has the benefit that data entry for different 'repeats' can be done in non-linear manner, for instance enumerator could get all the names and sexes down for everyone before doing the individual tests for infection. This would vastly simplify a lot of data entry, but clearly would need fundamental changes to Collect.

Note that using Enketo via a browser can achieve lite versions of both of these approaches, so functionality in Collect is perhaps less a requirement for these rather more specialist use cases. The only issue is the relatively less well developed/less certain off-grid functions of Enketo and lack of easy way to enable browser caching of forms when internet is unavailable. The clinical observations form is something I have been asked about many times, especially for things like emergency hospital units where internet is unreliable. Is there any case for (optionally) replacing the front end of Collect with Enketo, but back-ending it with the existing infrastructure?