What is the general goal of the feature?
Be able to track the time that has passed since between pressing a "Start" button until a "Stop" button is pressed.
What are some example use cases for this feature?
An important indicator in health facilities is the time it takes for a patient to receive attention. This is usually done tracking a patient and measuring the time taken between areas (ex. How much time it takes for the patient to go through the Admission Area)
I work with Ona, and we are working with a client, Early Learning Outcome Measure (ELOM).
ELOM is an easy to administer South African pre-school child assessment tool. It indicates whether an Early Childhood Development (ECD) programme is effective in preparing children for Grade R, and identifies areas for programmatic improvement. It is an innovative tool has been developed for government, funders, programme developers, ECD providers and monitoring and evaluation specialists, who need valid evidence of programme effectiveness.
In the assessment, a handheld stop watch is used, and certain item have stop rules which depend on time. For example, in one item, a child is required to stand on one foot. The stop watch is used to record the amount of time the child is standing on one foot. Another example, a child is given 10 beads and a shoelace with a knot on one end to prevent beads from coming off. A stop watch is started. Then, hildren are to place 10 beads on the shoelace, but the child is stopped when the stop watch reaches 40 seconds and scored accordingly.
The ELOM team has found it is very difficult to get accurate usage of stop watched by highly trained assessors. Therefore, we think it would be very useful to integrate a simple timer widget which allow a user to start and stop within the ODK form interface, similar to image or audio widgets.
How would we go about starting to integrate such a tool into the ODK Collect data collection tool?
Hi @Megan_Schroeder! I combined your message with a recent one from @jruizc since they are very similar.
This seems general-purpose enough to me that it would be worth including in Collect as an appearance for the decimal type.
I think the next steps would be to propose a quick UI sketch here in this thread and to write a quick post to the Development category to propose a name for the appearance (stopwatch?). We'll give a little time for comments and then it should be ready to get integrated unless there are any objections.
@Megan_Schroeder@jruizc If the process I outlined feels a bit heavy for a simple feature like this, feel free to go straight to submitting a pull request or pointing to a branch with a proposed implementation!
After reading @Megan_Schroeder post and talking with colleagues, I have listed the following questions that would be interesting see answered by the community:
Time measurement
Would it be recorded in seconds or would it be considered to also save it with milliseconds/minutes/hours?
In Mega case, I think she measures up to a few minutes. In my case, following a patient might take up to 3 hours of waiting time in only one part of the complete process of health care.
I mention milliseconds as I have seen most stopwatches to measure up to those. Personally, it would be interesting to have it.
Laps?
In my case, it could be interesting as a way to measure the output of users or patients from some areas of a health center. However, this could also achieve with a repeat group.
Constraint min/max times if necessary, or would we need to consider a countdown?
In both cases, it might be possible that the task may be completed in less than the limit contemplated (ex. 40 seconds). Thus, the measurement doesn't have to exceed 40 seconds time but could stop before the end. The result would be anything between 0 and 40. The same applies for tasks that might be "infinite" and where the participant will only stop when you tell them to do so. Thus, you wouldn't be able to advance the form if you haven't reached the required time (40 seconds must pass).
Two buttons. Maybe three?
How I imagine it working, it would be one button for play/pause and the second one for stop/reset.
While the 1st button is showing "Play" the 2nd button would be grayed out with "Stop" .
Once you press "Play" the 1st button would show "Pause".
When paused, you would be able to either resume with the 1st button or stop with the 2nd button.
If you Stop, the 1st button is grayed out in "Play" and the 2nd button would show "Reset".
Reset cleans everything back to the 1st button showing "Play" and the 2nd button grayed out in "Stop".
(I would consider a third button if we add laps. However, it could also be added here instead of "Pause") Example of a three buttons stopwatch Example of a two buttons stopwatch
@jruizc Thanks for providing more details on your need!
Saving in milliseconds would be the simplest and most useful, I think. We could display in more human-friendly formats.
I think the way to do this would be to use separate questions for the different "laps", possibly in repeats as you say. Otherwise we can't make the stopwatch a simple appearance on top of a decimal and we have to decide on what data type to save. It could quickly get quite complex and hard to analyze.
While I do think a simple stopwatch would be a good addition to ODK clients, I want to point to another possibility: using an external stopwatch app that can return values through intents. Read more at http://docs.opendatakit.org/form-widgets/?highlight=external#external-decimal-widget. This would allow you to use an arbitrarily complex stopwatch app without breaking the flow of the form too much.
This one is a little tricky. You could certainly add a constraint to validate that at least 40 seconds have been recorded between start and stop being pressed. But an arbitrary amount of time could have passed between the enumerator pressing stop and swiping out of the question. You'd want to make sure you provide clear guidance on what to do if a value is rejected. Take another measurement, I guess? Perhaps more helpful would be building a relevance calculation off the time and show/hide certain questions as appropriate. For example, "The latest task took too long so the survey is now over."
Either of those sounds good to me! @Megan_Schroeder do you have a sense of what your users would find most intuitive?
Dears i was looking at this conversation and felat like the issue of adding stop watch in ODK was possible finally. If so could any one share me ,xlsx form so that i see how it works as i was developing a questioner that needs monitoring the response of beneficiary over 1mnt time
i mean i would like the interviewer to view the stop watch on the tablet to see how much the beneficiary has read in 60 seconds
@Babera26, I don't think this feature ever made it past the discussion phase. Your input and suggestions for what would be useful can help guide the discussion if people revisit this, so thank you for expressing interest!
Could something like this perhaps be more readily accomplished via leveraging a (simple) external timer app (aka "User Application") using ODK Sensors?
Then I designed an app based on the ODK Counter app, which did the same thing, but using a temporizer instead of a manual counter and it works wonders.