@maxeber has been having problems with a form he created and I've asked him to share it publicly because it has 10,000(!) questions and I've never seen a form this large.
Truth be told, I don't think the form needs to be this big, and I'd like to ask our community's greatest form design minds to suggest improvements. My hope is that this process will be a learning opportunity for everyone. I'd like to:
Help form designers who find this topic learn more about how to make efficient forms
Help core developers make improvements to the tools (or the docs) to handle large forms
Thank you Yaw for posting this on my behalf! I very much appreciate any ideas that people may have on how to shorten the survey but preserve the idea.
I would just like to give some supplemental information on what I am trying to do (and why it is currently so long!):
This survey is to be used for attendance digitization and, for the ease of the people doing the digitization, I wanted them to be able to enter a full class worth of data in one survey. Otherwise I am concerned that it is easy to lose your place and accidentally duplicate or skip data. It is currently so long because I built it to be flexible with regard to the number of students in the class and the number of weeks of available data (currently accommodates up to 100 students and 50 weeks of data). I would imagine it may be possible to do this using repeat groups conditional on the entered number of students and weeks instead of using new questions with relevant fields as I've currently done, but I am unsure how to do so.
Happy to hear any ideas or suggestions you may have -- Thank you all for your help!!
Onething I instantly see can be done differently is to put blocks of questions into repeats. For instance, student1 (row 14) - student100 (row 212) can be put in a repeat. This can save you so many questions.
Resizing the form depends on data collection practice. If one want to capture all students basic information first and then attendance status in that case attached form may effective repeat_index_repeat.xlsx (23.5 KB)
There may be an issue with repeat for your case though: the last time I checked, ODK Collect became u responsive after about 25 repeats. Iām not sure how well it performs nowadays.
@ARIF_AZAD_KHAN That looks like a nice solution! I was only thinking to capture the basic information prior to the attendance because I thought it would be easier for the data entry people to not lose track that way -- the forms they will be digitizing are quite messy.
I will try to test your repeat group solution and see if it runs into the repeat limitation problem that @Trung suggests. I will follow up with what I learn!
To followup on @Trung, any time you are writing a form and end up with something like:
integer | studentnum | Number of students in this class section:
text | student1 | Enter name of student #1:
select_one female | sex1 | Is ${student1} male or female?
text | student2 | Enter name of student #2:
select_one female | sex2 | Is ${student2} male or female?
...
you can convert this to a repeat group, eg
integer | studentnum | Number of students in this class section:
begin_repeat | studentlist | repeat_count = ${studentnum}
calculate | num | calculation = position(..)
text | student | Enter name of student #${num}:
select_one female | sex | Is ${student} male or female?
end_repeat
thereafter, to reference any specific repeat result - eg a particular student's name or sex (previously ${sex1}, ${sex2}, ...) - you would instead use an indexed-repeat() function; eg
indexed-repeat(${sex}, ${studentlist}, ${i})
will give you the sex entered for the i-th student.
If you find you are repeating the same set of questions over and over, you are almost always better off using a repeat group to capture them, and using an indexed-repeat() to access them elsewhere in your form. Commit https://docs.opendatakit.org/form-repeats/ to memory!
If you go thru your form doing this, I suspect you may be able to reduce its size by 2 orders of magnitude...
