Process for adding our own Timer widget?

Background: We would like to use ODK in a health care scenario where a Community Health Worker is administering a rapid diagnostic test (RDT) on a patient. Currently ODK can do most of what our custom app currently does, which is collect some patient data (symptoms, demographics) and walk the CHW through a few instruction screens on how to set up the RDT, then have a button that says "Start Timer" and the app forces the CHW to wait 10 minutes before proceeding to the next screen with instructions on reading the RDT.

The main gap in functionality if we switch to ODK seems to be the timer function. I would like to know how easy/hard it is for our team to add such a widget/function.

Base requirement: A button that says "Start Timer" and on click starts a countdown of n minutes. User cannot proceed to next screen of app until the time elapses.

Even better: Button says "Start Timer" and on click starts counting internally, but allows the user to proceed through some more screens (e.g., so that CHW can collect patient symptom and health history data during the RDT processing time of 10 minutes). Then forces the user to stop before a certain screen (the "Read the RDT Now" screen) until the time elapses.

Based on browsing the forums, it seems that to add timer functionality, we either need to (1) contribute this code to the ODK Github repository, or (2) take the source code and modify it ourselves. Am I correct that there are only these two options?

If we were to contribute to ODK, what is the process for getting the functionality added not only to ODK source but also specifiable via XLSForm and XForm?

I'm new to ODK so apologies this is vaguely worded. I did check posts like Adding a timer/clock to my form, How to add a widget?, Stopwatch Widget but they didn't really help. Thank you so much!

This is an interesting requirement that I have not seen before!

I think what you may be wondering is whether there is some type of plugin option that might not require modifications to the core app. There is support for launching other apps and receiving values from them. This would make the less desirable "start the timer and be blocked until 10mins have passed" option possible. You could build a small timer app that initiates a countdown when launched and returns a certain value (1, "done", whatever) when the required time has elapsed. You could then make the visibility of the question(s) to ask after the rapid diagnostic test based on that returned value. This would guarantee that the data collector had to let the full time elapse before proceeding.

That is something you could do without having to modify any Collect source. However, I don't think it can enable the better user experience of constraining a single field or group of fields based on the time elapsed.

For features that will become part of core ODK Collect, the process is to describe the requirements in detail in a post in the features category. This could either start high-level as you've done here or include a specification. This allows users with similar requirements to chime in and members of the technical steering committee to evaluate whether the proposed functionality is general-purpose enough to be included in the core.

As you note, this particular feature would almost certainly require additions to the form specification. The form syntax would need to be proposed and reviewed by the TSC.

If you do want to further explore adding such a time constraint to Collect, I'd suggest copying your functionality description into a features post. If possible, it would also be very helpful to include the user experience your custom application provides through screenshots or a screen capture.

1 Like

LN,
Thank you very much for your kind and informative reply.
I was able to play around with ODK intenting out to a stub app and getting values back. As I understand, launching an external timer app would be a way to force the user to wait as you noted, but would not enable the user to fill out other questions in ODK during that time as the external app would be in the foreground until its activity finishes.

Thanks for the tips on proceeding with a feature proposal -- it answers my question at this point. I'll loop back with my team and see how we want to proceed.

Terri

3 Likes