We are developing a from to count different plants on a farm field. Imagine a person inspecting the field and counting the different species on the go. This could be done quite handy with the new widget "counter" by listing the different species one below the other on the same screen.
Additionally the species could get preselected in a preceding select multiple question to limit the listed species to the relevant ones.
The downside of this approach is, however, that the form would have to be hard coded with every species for each question. But we are dealing with more than hundred different species. It would be difficult to maintain this as compared to an external csv list containing all the species and some other relevant information for sorting.
A technically more appropriate approach would be using repeat questions, with the important downside, that the repeat questions are each on a different screen, which results in a not user friendly form forcing the enumerator to switch every few seconds from one screen to the other.
Does anybody has an working approach to this? Or should this problem rather be in the "ideas" section of the forum: listing repeat questions on the same screen?
Thanks @wroos for the links to previous discussions. I have read some of them, but obviously the limitation of Collect to not being able to display repeat questions persists without any workaround. @LN: Is this issue on the list for future versions of Collect?
I’ve been in that situation before! Just sharing my experience - The workaround I used (not exactly a solution, but just a workaround as I had to do it anyways) was to rely on Enketo instead of ODK Collect.
I trained data collectors to submit forms using Enketo on their devices rather than ODK Collect. Since Enketo allows multiple repeat instances to be maintained on the same screen, all they had to do was scroll through instead of navigating separately for each repeat instance.
However, there was one major drawback I faced - I had to ensure that they had internet connectivity on their devices all the time, as Enketo requires real-time access to the ODK Central platform for submissions.
Just in case you missed it in the link - if you begin group after you begin repeat you can set your field-list appearance for the group within the repeat. (you can also have items outside the group, or multiple groups in the repeat.)
While I haven't had this exact issue I've had similar. Even though you have a species list of 100 different species, what is the maximum number of species that a single farmer is likely to have that you'd include in your form?
A slightly different approach which would require a select multiple question followed by an x number of paired integer (counter) questions w a calculate question. The calculate could calculate the name of the first,second,third, etc species selected in the select multiple and each one of those could be followed by the integer question. Essentially you're questions on the back end would just be numbered like species_observed_1 for the calculate question and qty_species_observed_1 for the integer and those would just be the first response selected by the user.
The main limitation here is you'd have to pick a limit to the number of species that are likely to be seen in the same field/area and enumerators wouldn't be able to surpass that. Since the order depends on what order the enumerators select, this wouldn't be consistent either.
You'd also end up with a lot of empty columns in your database if most farmers have let's say 3-4 species while a small percentage of farmers have 50+ species.
This does however avoid repeats and making a question for every single species. Does this solution make sense?
I actually thought about this solution too but droped it in the end. Limiting the number of plants per field would not be the main issue, since – you are right – just a limited number of species is planted on a field.
The main reason was, that with generic questions like plant_1/quantity_1, plant_2/quantity_2, etc. it is not assured, as you point out, that information about the same plant are stored under the same generic question name when the field is visited again.
The form will retrieve the last collected data (an enumerator visits the fileds several times over years). The form then calculates the new number of a particular species based on the old and new count.
The form allows various activities to be recorded: plants can be counted, planted or replaced. This results in different new numbers in each case.
I am currently working on a version that is based on repeat questions, even if they cannot be displayed on a screen. Since repeat questions currently are not possible to be used for entities, a script for pyodk will then retrieve the data from the form, store it in a csv and then automatically upload the csv at a certain regularity.
Once I have a working form I'll be happy to share it here together with the script.
@dast I truly understand your use case and i have faced challenges similar to these. Sometimes workarounds as a solution to problems turns out to be unnecessary round works. I understand first you want to map out the species in a repeat loop and then use them (using entities) later in counter questions. If the species is a text field, meaning you will have to clean them up to ensure consistency in spelling.
My thought is what is preventing you from having a lookup list of all the possible species? Then use the repeat loop for the farmer/data collector to add the ones they want to count. At this point putting a constraint that a species can only be added once. I believe this would be a select one question with a search appearance.
Lets say the look up list has thousands of species. There is no harm of including thousands of counter questions. This number should correspond to count in the lookup list. I have done surveys with thousands of questions with no crash. The advantage of yours is that the questions are similar in structure therefore you can use excel function to automate the process of form authoring.
Use relevant to display a specific species counter if it selectes within the repeat loop. All the thousands questions can be put within the begin group outside the repeat group therefore, its possible to have them appear on the same screen.The list will be manageable as you have hinted a farmer can have just a few to count as opposed to thousands added. To update the list simply add a species in the lookup list and insert a counter question corresponding to it. Are thousands of questions too labourious to add or you fear having empty database fields? I believe this direct approach will solve all the fear dimensions.
Thanky @Stephen_K_ojwang for your input. Your approach sounds reasonable and would absolutely work I guess and you are absolutely right, that often the simple approach is the best. But simple in our case means the objective, that the project datasets can get managed by people with no or just little experience with XLSForms.
That's why we try to keep the froms as generic as possible because we work on different projects with changing datasets. So we try to move values that can change (p.e. a list of trees and their properties) out of the form either (best solution) into entity datasets or csv (second best solution).
Because repeat questions are currently not yet supported with entitties we test a script for pyodk to automatically generate or update a csv based on submissions and then upload it to Central on a fixed schedule.
But to fully use the potential of entities for reccurring visits it would be important to extend entities to repeat questions. This, per exmaple, would made it possible to pull information about household members captured within repeat questions during the last visit into Collect without having to create or update csv's.
