Your LimeSurvey version: 6.12.4
Own server or LimeSurvey hosting: Own Server
Survey theme/template: Bootstrap Vanilla
==================
Last year i created a survey that ran over 3 days for a foodtasting. Each food serving was handled in one group of questions. The survey was set to "group-by-group" mode.
Each participant had an access code and the settings:
"Enable participant-based response persistence" and "Allow to update the responses using the access code" were turned ON.
Due to longer pauses and overnight we got some "session timeouts" in the questionaire where answers were lost. Mainly on mobile devices.
So in the end we switched to pen & paper and entered everything manually in limesurvey after the event.

I would like to give it another try and read a lot in the forums here.
But i'm still unsure how to handle this correctly, so i have some questions:
1. Is this scenario possible with limesurvey at all - due to the longer pauses that will happen?
2. Is it possible to persist each answer within a group directly into the database instead of the session?
3. Would it be sufficient to increase the session.gc_maxlifetime to eg 24hrs to mitigate the issue?
4. Would it be possibly, that limesurvey writes the data from the session into the database on session timeout?

Thanks in advance!

"Enable participant-based response persistence" and "Allow to update the responses using the access code" were turned ON.

So far you did everything right.

Due to longer pauses and overnight we got some "session timeouts" in the questionaire where answers were lost. Mainly on mobile devices.

That is normal and depends on your settings on your server. The session is usually configured in your PHP settings.

3. Would it be sufficient to increase the session.gc_maxlifetime to eg 24hrs to mitigate the issue?

In theory it should be, but I wouldn't depend on it. Because you don't just have technical / session issues, but also respondents who might close the browser tab, switch off / restart the device, etc.

I think your design of the survey / the questionnaire is flawed and with some simple modifications you could avoid data loss. For this you need to understand that data is only stored to the database when the respondent clicks either the "next" or "submit" button.

So if they just fill in the questions for one food serving and don't click on next, the data is not currently stored anywhere and can be lost of the session times out or if the tab is closed.

I personally find that your approach would work fine and be actually better when you just have one survey per serving. E.g. you allow more than one "use" for the token by setting "uses left" in the participant database to a higher number. You probably would also need a survey that collects some general data and then connect it via the token (e.g. you create 1 survey for the general data and then one for the iterations with a higher uses left. When you upload the participant list you can actually use the same token for the same person in both surveys.

Another option, if you want to keep everything in one survey, is to put "splash screens" in between. E.g.

Page 1: Splash screen with a text display type question, explaining the proceedure, etc. and then prepare them for serving 1

Page 2: Serving 1 and its questions, asking them to click next when they finished to respond

Page 3: Splash screen with a text display type question explaining the next step and that they should click next once they are ready for serving 2

Page 4: Serving 1 and its questions, asking them to click next when they finished to respond.

And so on.

This guarantees that they submit their answers for each serving and then "wait" on the splash screen. What happens if the session times out? They just click the link again and land on the respective last page, which should be the splash screen, which means their answers to the previous serving has been saved to the database. As the Text display question has no input but only allows you to present text, there is nothing that can be lost in terms of data. So if they click the link again they start where they left off and you have all the previous data in the database.

And another positive effect: I think it will structure your survey better and make it a lot clearer to respondents what to do and have clear separations between servings.

Thanks for the clarifying answer and the approaches how to mitigate.
Thanks for pointing out possible events like restarting the device or closing the browser(tab). Haven't thought of that, yet.

However I'm left in a little bit of a dilemma now.
Each food serving's question group consists of 8 items.
4 large free text field's and 4 0 - 100% number fields.
So if a user filled out eg 7 fields already and forgets to click the next button they need to re-type everything, which will happen for sure with so many users talking to each other during the tasting.

And this can happen for both ways you suggested.

But thanks a lot for your suggestions. It saved me a lot of testing.
I will discuss this upfront with the participants, if they think they're able to fill out everything in one go.
And my personal preference would be the second option with the splash screens in between, so that users can later on change their answers, if they have something to add or modify.

I think in general it could be an improvement to limesurvey if there was an option to directly store the single answers within a group. Not just because of my very scenario, but because it's was most users are used to from other tools nowadays. No modern forum, webmailer or even office program "looses" information due to session timeouts any more.

But i see that this is an edge case as most surveys are answered in one go.

Maybe i will input that as a feature request on the bugtracker.

Thanks again and best regards!

However I'm left in a little bit of a dilemma now.
Each food serving's question group consists of 8 items.
4 large free text field's and 4 0 - 100% number fields.
So if a user filled out eg 7 fields already and forgets to click the next button they need to re-type everything, which will happen for sure with so many users talking to each other during the tasting.

So the respondents are all in the same room and talk to each other? How can they run into session time outs? They need to talk a lot to each other or your session time on your server is set very, very low.

Good practice in survey design is usually to show question by question anyway. If this is an option, I would go down this route. If you need some questions on the same page you can always use question groups as "pages". You "loose" the logical concept of the groups, but with the right naming of the groups this shouldn't be a big issue.

Now to your idea of saving answers "on the fly" without the need to clicking next. I am not a developer, but to my knowledge this would requir ajax calls on each and every question, which might be an issue with so many fields and thus so many open Ajax connections. This might have an impact on the performance of such a survey. In a forum or a webmailer you usually only have few fields (e.g. subject and main text), while in a survey you could have a lot of fields on one page. As I said, I am not a developer, but I think this might be the reason why there is no such feature yet.

But feel free to make a feature request. If technally feasible without impacting performance too much, this would be certainly a nice to have.

However, you might want to look into your session time, because from your first post I understood that the issue might be over night. But then in this last post you mention that the respondents speak to each other, which gives me the impression they are in the same test environment? I mean, then they usually have a limited time to respond anyway and a session time of even 5 or 10 minutes should be enough.

In any way, I would try to split the groups into various pages if possible and then use the splash screen. Gives the questionnaire a good structure and the participants know where they are within the tasting session.

Also, I would recommend to instruct the respondents to fill in each tasting without much interruption. I mean 4 huge text fields and 4 scales from 0-100% shouldn't take too long. I don't know the context of your research or your tasting sessions, but generally it is good practice to avoid respondents to talk to each other during a tasting to avoid them influencing each other and creating a bias. But of course, as I said, this might not relevant in your case. For my tasting sessions I would try to avoid respondents to speak to each other as much as possible for above reasons.

But also have a look at your session settings in PHP, increasing the timing might already help you a lot.

I was aiming for logical groups - one page per serving, so that users could review their answers without navigating through 8 pages.
However i will take a look in the naming of the groups, maybe that's an option to make users aware were they are.

I will def take a look into the session timeout, because last time the timeouts happened quite a few times. You know, it's mostly a private social event and people are talking, drinking and eating together. Everybody prepares something, so it's nice to talk about it.
And forgetting to enter the data in a timely manner.
Users are users, when it doesn't work for them, they don't use it.

But last time this issue came surprising and this time we would be prepared. Could work.

Regarding the feature request. I think it's only a few hundred bytes at max, that need to be sent back. Should be fine with a normal network today.

Thanks again for your advice and your time.

You know, it's mostly a private social event and people are talking, drinking and eating together.

Got it! For our tastings we usually have a 100% research environment, so people are invited only for this purpose and are also receiving something for participating. So we can "control" things better and make them fill out their form.

Regarding the feature request. I think it's only a few hundred bytes at max, that need to be sent back. Should be fine with a normal network today.

The problem for sure is not the data itself, but from what I understand, each ajax call / listener would have to have it's own database connection open, I think this can impact the database performance quite a bit, especially if you have various concurrent participants, all with their survey open. But we'll see what the developers say, if they say something at all.

Here is an old thread about this
[url] forums.limesurvey.org/forum/can-i-do-thi...e-of-session-timeout [/url]
As far as I remember, there was another thread, a bit newer.

Anyway, in the thread the plugin "heartbeat" is mentioned.

A heartbeat plugin for LimeSurvey to ensure the session is kept alive during survey.

You find it here
[url] gitlab.com/SondagesPro/coreAndTools/HeartBeat [/url]

Joffm

 

Thanks for the tip!
I will test it out, when we proceed to use limesurvey for the tasting.
I see it has a merge to ensure 6.x compatibility.
Nice, that would cover the "server side" timeout.

@joffm
When i upload the latest master of the HeartBeat plugin and click install then i got the following error:
"The plugin could not be installed or updated: Could not parse config.xml file."
I tried changing the config.xml to reflect the 6.12 version, but no change.

However it was possible to directly git clone it into the plugins directory. And it's working perfectly.

Looking good now.

When i upload the latest master of the HeartBeat plugin

That's obvious.
You shouldn't upload a "master".
You have to unzip, rename the folder to "Hearbeat", zip again and upload as ressource.
Or you unzip, rename it and upload the folder directly into the plugin directory.
In the plugin directory the name of the folder has to be equal to the name of the php-file.

BTW:
I checked this morning.
I started a survey, answered a few questions. In the middle of a group I put the smartphone on the table, worked a bit in the garden for about an hour, answered some further questions, went for shopping, and at home again I completed the survey.
Without any problem.

Did you check the settings of your installation, the maxlifetime of the session in "php.ini", or the sessionexperationtime in "config_defaults" (default here: 2 hours")?