When the enumerators click on “next” before the gray highlight of a select_one or select_many has vanished or if they interact with another one, the response is not saved. This is very inconvenient. Are other’s experiencing the same?
Would there be a way to prevent this? E.g., through CSS/js disabling of all interactive elements until the data is saved?
We have occasionally run into this, but primarily when going very fast through testing (when enumerators are actually reading questions in the field this is not usually an issue). It definitely relates to how many items and especially calculations or really complex choice filters you have on a screen, so we often break up longer/more intensive screens. There may be a better underlying tech fix as well.
One other possibility: we found it essential to turn off the “auto rotate” option on our tablets. If a form is only partially completed and auto-rotate is on, when the tablet is rotated (i.e., display changes from portrait to landscape) the partially recorded form is wiped clean of records and we have to start over on that record.
I am facing the same problem. I have some forms in which we need grid-screen type view for several questions, hence we have used custom screen handlebars to display them in a grid like structure. Any such custom screens that have very short question prompts (like 15-20 characters), they work fine, with reasonable speed. But for the questions even having 8-9 words (50-60+ characters) as prompt text, the choice options are not selected unless we wait for 3-5 seconds after a previous selection. It seems (even visually) that the screen is loading after every selection, and any option we select before the screen is re-loaded, is not actually selected.
We have some forms that have more than 20 such custom screens, and this issue is hugely slowing down data capture, plus it is frustrating for the interviewers as almost always they get a prompt or two for a required field that they must answer, but which they have already answered. So, for now if it happens, they toggle the other option, wait for 2-3 seconds, then select the original option again, then again wait a few seconds, and then only they can move on to the other question.
I checked to see what is happening in the background, and notice that for all such questions, I see a warning in chrome console - [Violation] ‘setTimeout’ handler took …ms. While this is no error, but it definitely indicates that some processes are taking longer than they should and could be optimized. We are using latest Samsung Galaxy Tab A8 tablet with decent processor and 4 gigs on ram, so I am sure it is not the device. Can someone suggest what can we do to make it reasonably faster to handle such use cases? Thanks.
The issue is that the system does not know if your next prompt depends on the answer of the previous so it saves everything and redraws. For example cascading selects, where you select the state, then the system has to re-query to get the new subset of the lists.
You will need to change the re-render function for your prompt to do the check you want, but hopefully you can optimize it.
Here is some of the system changes that improved performance for reference
Thank you so much, @W_Brunette I will check the github code.