View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|11687||Feature requests||[All Projects] Survey design||public||2016-09-20 16:04||2016-11-11 11:11|
|Target Version||Fixed in Version|
Looping lets you specify a list and a group of questions to be asked for each member of that list.
|Tags||No tags attached.|
Like label sets, but bind at survey creation.
I have seen an hacked 1.92 version with "multiple group" : in some group you nhave "Add one more" : clicking on it add a group with exactly same question.
It's for event : in an event you can have 1,2,3 ... bands for example.
The code is very dirty ..... (and broken)
So, here what was my idea:
It's possible to do this solution with the current database structure.
I remember a feature request, where the copy and paste of questions should be automated. Better automated then doing it manually.
But the typical real world example is a multiple choice question with brands.
The Step 4 in your idea would work with additional lists.
When it comes to looping things can start to become really boring for respondents. In my example a respondent could have checked every brand, which would result in a lot of questions. In real world the looping is often done with a limit. The generated list for looping is manipulated to prevent too many questions. Often you have rules applied to the list. E.g choose 4 brands from the chosen ones. If there are main competitors chosen, keep them. If not, select randomly to fill up the slots. That is more about the dynamic list building ( https://bugs.limesurvey.org/view.php?id=11688 ), but it is heavily used in combination with looping to keep a question limit.
This feature request is about the same:
I like the idea for "loop a complete group" : think it's more easy for LS developper.
Exemple of GUI usage : in group edit:
I think nthe second group can be saved in the same table with : all other value to "null", but fille the session by the original survey.
The survey line have a "original srid" column (and maybe "group copy id" too)
Just to give an impression how looping is offered in a webbased gui take a look at this compact tutorial:
A "complete" looping function would allow the following example:
@jelo about qualtrics system seems not a real looping :
A real looping must allow "infinite" looping.
PS : ok edited : "To Loop based on a Number"
@DenisChenu: I don't understand the intention of your last note?
Since there are members of LS team which didn't know the term looping I provides some examples. Once the ground idea is clear, a concept suitable for LimeSurvey might be developed.
There are infinite and finite situations. And there is difference between providing a questions generator to save copy and paste work and a "real" looping routine in the code.
Hi @jelo : i updated my comment. But infinite looping and finite looping are really completely different in DB andf in developpement.
The first example of qualtrics seems available today with some hack via a plugin, te infinite looping is not really doable without major hack.
@DenisChenu: Wouldn't it be more fruitful to discuss feature requests in three steps:
1.) Focus only on the nature of the feature request. Goal would be to get an common sense of what the feature should provide. And define a scope and possible limits.
2.) Focus on the current codebase and the implication for developing the requested feature. Goal is to get a feeling, if the feature request can be done 1:1 with the current codebase. If a 100% realization isn't possible, define what is possible with the current codebase. And define what's needs to be changed at the core, database and third-party stuff to get it done 100%.
3.) Often we would end up with two feature requests. One, that is possible "today", one that needs a different codebase. Over time we'll get a better picture how a major overhaul of the codebase should look like. Goal would be to get more feature requests, which are ready for implementation. For current and future codebase.
To tag feature requests with e.g. "Codebase LS2.5" or "New codebase needed" would help to sort feature requests.
When it comes to looping I don't think step 1 is finished.
But let's say we limit the feature request on static looping.
Your point 1) depends on 2)...
First iteration of point 1): we want a looping system, "kinda like" the one of qualtrics. That's precise enough for a first iteration. Then come the first iteration of point 2): is it possible with the current core/database? Will it need a lot of work?
From the answers to this point 2, we go back to point 1: it's possible, now, without too much effort, but it implies a workflow different from the qualtrics one. Two workflows have been proposed: a/The Denis group copying system, b/My system of copying survey. The pro and the cons of each one should (still) be debated. Also, we should debate if any of those solutions is good enough, and if we should rather make deeper changes in the kernel and the database before doing a true loop system (that's the Carsten POV)
Then, we'll go back to point 2/ for a second iteration: which one would be the easiest one to implement? How to implement it, etc.
Then, when start the dev, again we need new cycles.
|2016-09-20 16:04||jelo||New Issue|
|2016-09-20 16:14||ollehar||Note Added: 40858|
|2016-09-20 19:25||DenisChenu||Note Added: 40863|
|2016-09-21 10:45||LouisGac||Note Added: 40874|
|2016-09-21 11:38||jelo||Note Added: 40875|
|2016-09-21 11:38||jelo||Note Added: 40876|
|2016-09-21 11:39||jelo||Note Added: 40877|
|2016-09-21 11:49||DenisChenu||Note Added: 40878|
|2016-09-22 00:09||jelo||Note Added: 40910|
|2016-09-24 11:57||DenisChenu||Note Added: 40936|
|2016-09-24 11:58||DenisChenu||Note Edited: 40936||View Revisions|
|2016-09-24 12:53||jelo||Note Added: 40939|
|2016-09-24 13:11||DenisChenu||Note Added: 40940|
|2016-09-24 17:36||jelo||Note Added: 40941|
|2016-09-26 10:42||LouisGac||Note Added: 40953|
|2016-09-26 10:43||LouisGac||Note Edited: 40953||View Revisions|
|2016-09-26 10:44||LouisGac||Note Edited: 40953||View Revisions|