View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
07589 | Feature requests | Conditions | public | 2012-08-31 02:05 | 2021-03-07 21:01 |
Reporter | fsando | Assigned To | c_schmitz | ||
Priority | normal | Severity | feature | ||
Status | closed | Resolution | suspended | ||
Summary | 07589: Randomly select x out y questions (or x out of y groups) | ||||
Description | The idea is that I have a pool of eg. 20 questions, I want each respondent to answer 10 questions randomly selected from the pool of 20. I may have several such pools, where the respondent should only answer a random selection. I have a working implementation. It touches the core code but I have tried to make it as self-contained as possible. It is contained in its own class and only a 7 lines goes into to core code. The idea is the following: First the basic idea: 1) Add one or more attribute fields to token table 3) As relevance equation for each question in the pool I then add a regular expression to match the relevant field in the token table like this: Each such attribute column in the token table could in principle be filled by hand for each respondent, and in this way you could create custom routes through the questionnaire for each respondent. In the implementation (described below) the fields are filled by random patterns. Thus creating random routes that are specific to each respondent. It is possible to create several individually independent random selection pools, by creating more fields and associating each to a different group of questions, indeed there is no limitation to how one could construct one's selection pool. Basically this just creates the ability to randomly selct a specific number of items or options out of a larger set. I also achieves to make the presentation of each single question indepenent of the presentation other questions in the same randomization group. The way this work in practice is that one adds a field to the token table and makes sure its description follows a specific format. Then every time a new token is added a random pattern is also added, this pattern is then used to either show or hide individual questions. | ||||
Additional Information | A possible solution: Random selection of x out of y questions (or x out of y groups) The implementation: 1) Add one or more extra attribute fields to the token table RANDOM_PATTERN,3,6 Where "RANDOM_PATTERN" identifies it as a randomizer field and "3,6" are parameters for the "x" and "y". 2) Have a function automatically fill those columns with random 0/1 strings of length y containing x 1s and (y-x) 0s. This will effectively create one or more random "background" variables for each respondent that can be used as a selection condition both at question and group level. Specifically: The class is currently placed in application/controllers/ in order to be autoloaded updateRandomFields(surveyid) This function is called in two places: 1) when dummy tokens are added and when createTokens is called, that is, it is called when new token-values are computed. Every time the updateRandomFields() is called all randomizer fields are checked for validity and if found to valid randomizer fields but in a an invalid state they are recalculated. If the field How can they valid but in an invalid state? The are valid if They may be in an invalid state if the parameters were changed since last calculation: if the length of the current value differs from y or if the number of 1s differs from x. The way it works in practice is that one adds a field to the token table and makes sure its description follows the format. Then every time a new token is computed the validity of the random pattern is checked and if necessary (re)calculated. I do not fully understand how Yii works but I believe there are some filters or hooks that can run code before and after events. I have a feeling that this would probably be a more appropriate way to trigger the update than putting an extra function into Token_dynamic. If the implementation is found to be robust and useful the idea could easily be extended to other types of fields by simply adding other description formats and associated methods. | ||||
Tags | No tags attached. | ||||
Bug heat | 4 | ||||
Story point estimate | |||||
Users affected % | |||||
Date Modified | Username | Field | Change |
---|---|---|---|
2018-08-21 19:30 | SciDechse | Issue Monitored: SciDechse | |
2021-03-07 21:01 | c_schmitz | Assigned To | => c_schmitz |
2021-03-07 21:01 | c_schmitz | Status | acknowledged => closed |
2021-03-07 21:01 | c_schmitz | Resolution | open => suspended |
2021-03-07 21:01 | c_schmitz | Note Added: 62820 | |
2021-08-28 01:32 | guest | Bug heat | 2 => 4 |