I have recently built a case list application with a registration form and 4 follow-up forms, (one follow-up form has 11011 questions grouped in 520 question lists, this form is too much slowing down when it uploads), please if any good practice to be advised for to assist me upgrading the performance of this form.
Having so many questions is generally not a good approach in form building as you can run into such issues.
You can try splitting your form further into multiple forms with each form having reasonable number of questions. You can use your Question List grouping logic to split the form into different forms. You can link these forms using End of Form navigation .
Only catch with using 'End of Form Navigation' is that a user may chose to exit in the middle of one of the form and data will still be submitted by forms which have already been submitted by the user.
Also make sure that you are not using any complex logic for default value calculations of each questions (if any). Many times, forms are also slowed by default value logics, heavily loaded repeat groups etc. So that also something that needs to be kept on mind.
Hello Ashish,
It sounds very good advice. Also, is that good way if I could aggregate numbers of question lists in various question groups?
However, many thanks for kind support
@bwadi : can you please ellaborate on what you mean by 'aggregate numbers of question lists' ?
As I mention in my first post, I have 11011 question in 520 question list which is a very big number for a single form. Instead, now I am thinks if I could put these (520) question lists in (30) groups (groups of questions lists), as another level of aggregating questions . in other words, putting these 520 question lists into 30 question groups within the same form.
@bwadi : You certainly can do that but it form still will be bulkier to load and you will still be facing the same issue.
I can't imagine a situation where this is absolutely needed.
can you tell us more about these questions? why do many? are they the same question being asked 11011 times? are they the same questions about less number of things?
ideally in a situation where you have so much data to collect, you would want to split up the task into multiple tasks that correspond with real life activities.
if indeed, the enumerator is going to sit there and fill the responses for 11011 questions that are
1- different
2- about different things that cannot be grouped in any way
3- have different responses
4- collected at the same interaction
you've kinda run out of luck. I can see that the issue you are having is during upload.
I can tell you that having so many elements in an upload essentially means a LARGE xml payload. which is going to be heavily affected by the internet bandwidth you have at the upload time.
this cannot be avoided if you have all that data in a single form submission as the submission won't go through until it ALL goes through. partial upload will not land on the server. so, it makes sense that the app would struggle. it is prioritizing uploading all that data over whatever else you are trying to do, and it's a lot of data.
I will recommend that you look at the points above and see if you can split up this task into:
1- different forms
2- different interactions "less questions to answer each visit"
3- different way to get the information you need.
I am super curious to know what this data is for.
Hi Mazz,
the data is for following up a health facility for recording monthly health facility consultations (there are 520 morbidities expected to be reported disaggregated by sex and 7 categories of age which lead to a total of 11011 questions-including hidden totals).
However, I am very pleased to get countless support.
Looking for farther advices possible
Many thanks Ashish for your advice, now things are going to be clear for me
First I suggest you make morbidity into a drop down list. have each morbidity as its own submission - makes it easier to upload because each record is much smaller
you can also just have a repeat group question with the morbidity as a drop down and then they can enter all.
you can do some fancy code and use a calculation to pre-load the morbidity in the repeat iteration
but it sounds like just doing a separate submission "new form" for each morbidity would totally solve the performance issue or at least make it more reliable to upload data.
you can use end of form navigation to come back to just the previous screen and call it a day