View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|15105||Feature requests||Other||public||2019-08-04 14:35||2022-03-09 20:45|
|Summary||15105: "no answer" is preselected|
No answer option is preselected but should not be preselected on load.
|Steps To Reproduce|
just check any question with presentation option "show 'no answer'" = on
|Tags||No tags attached.|
Isn't this a feature request? just checked now in 2.7x , and it is always preselected. Shall the behaviour be changed?
No, from a methodological point of view this is a bug. Because "no answer" implies that a respondent chooses to say "I do not want to answer that question". However, there are many other possibilities why the person did not check any other response (e.g., did overread the question or none of the response options provided is a good answer).
Normally, I am not very strict and try to balance arguments for or against something. But pre-selecting any answer (even if it is "no answer") is really bad survey design. So either LimeSurvey is bad by design - which I doubt - or this is a definitely bug.
@f_funke : Disable «Show no answer» didn't fix the issue ?
In radio list : the «No answer» option is same than an empty text box, or «Please choose …» in a dropdown.
In HTML : a dropdow NEED an empty answer (else the 1st is selected).
15104 was a different issue ("no answer" was displayed, even if was set to no in the options).
In a dropdown, the first (and visible) option should always be "select here" (or something like that) and if you want to an additional "no answer". But also in dropdown the first option should never be "no answer" as this implies that no answer is a perfectly fine answer (which it is not because it should only be the very last choice). However, in a select list (technically a HTML dropdown with all response options visible) the "select here" is not necessary.
A more elaborate way of dealing with "no answer" response option would be in combination with madatory questions. On load there are only the substantial response options (e.g., A, B, C). When continuing without choosing an answer respondents are prompted ("Please select an answer.") and the additional response option "no answer" (or additional options like "don't know", "choose not to say", "depends on") is displayed (e.g., A, B, C, no answer). But I guess that relevance equations on the response level would be necessary for that?
Dropdown non mandatory : 1st seen : «Select answer … », move next, move previous : «No answer» selected
Else : in my opinion : If you need a clean solution : just set your radio list question as mandatory … : no default value, no «No answer» etc …
Else : we can have different look for No answer and answer (see screenshot)
Capture d’écran du 2019-09-19 10-46-12.png (26,593 bytes)
Capture d’écran du 2019-09-19 10-46-12.png (26,593 bytes)
About : dodn't display the 1st time : i'm TOTALLY against this …
Choice : Yes/No/No answer (non mandatory question)
I talked to @c_schmitz. We will move it (for the moment) to feature requests. There are some other things that need to be dealt with first.
I do not consider this a bug. It is the default Limesurvey behavior for > 10 years and we should NOT change that unless there are very good reasons for it.
@holch, what's your opinion?
I consider the whole feature of "no answer" nonsensical. Why force someone to have this "no answer" option anyway? If I want a "no answer" option I'll put it in the question (and with the answer code that I want and need for analysis (e.g. 98 or 99, which is fairly standard). But I understand Denis' point: If you click something in a question
But I also don't see why any answer needs to be pre-selected in this case anyway.
So I am probably the wrong person to ask.
But just because we have always done it doesn't mean we can't change it. But a change needs a good reason.
@f_funke: Limesurvey has a bunch of historically grown things that don't really make sense. You need to know that LS grew from a one man coding project to something a lot bigger. There was never really much of a strategy, it is always just developed one problem per problem. So many old "features" have never changed, if they make sense or not. And of course it is always dangerious to change something that has been there for ever, no matter how stupid it sounds. There will always be some that are used to it and will be against the change. This is just the nature of things. Humans are "Gewohnheitstiere"...
I totally understand that there is something like a history and that some things should not be changed.
But a preselection of an answer (even if the answer is a nonsubstantial answer) is such a big no go that in my eyes this is a bug and this implementation ignores a very basic principle in surveys. Sorry for my harsh words, but this is what you learn in the first lesson in a survey methodology 101 class.: Never ever preselect an answer option.
@Mazi: That this behavior exists for 10+ years is no justification for a bad survey design. That users didn't complain is no valid argument either. I'd guess that most people just don't use that feature. And LimeSurvey's options and defaults should help users to make good survey - the current implementation goes in the opposite direction.
For goodness' (and backward compatibility's) sake, there could be three options for "no answer" in the future:
@holch: The no answer option could make sense if it was combined with a certain presentation style (e.g., separated from the sustantial answers, or a smaller or lighter font). And it could also be nice for the expression manager if you could formulate a condition based on no answers. But I think in the long run it would be good to add in the admin backend a checkbox for every answer option if this answer is a no answer (e.g., don't know, won't tell, doesn't apply). At least this is how other survey software handles the issue.
@f_funke: I am not saying it shouldn't be changed. I am just saying why these things are there sometimes and why they haven't been changed so far.
But from what I understand is, your problem is with the pre-selection only. The rest seems to be fine for you. And I agree. I avoid pre-selection where ever possible and I also don't see much of a good reason for pre-selections, maybe only in case that you already have information and you just want them to confirm if this is still valid or want to show what they have answered previously. But else, I would avoid it.
So I actually vote for "yes" here. Take the pre-selection out. It doesn't aggregate anything and is just causing problems eventually. If someone doesn't tick anything, that is already "no answer" anyway...
Thanks for the clarification. These are very reasonable arguments and therefore I am also persuaded that changing this makes sense. But we should handle this with care. Maybe the following is possible:
Maybe also introduce a global setting like we do for other features and then the user is able to adjust this on survey level.
f_funke, can you ask if this is doable for LS 4?
|2019-08-04 14:35||f_funke||New Issue|
|2019-08-05 15:21||cdorin||Assigned To||=> p_teichmann|
|2019-08-05 15:21||cdorin||Status||new => assigned|
|2019-09-09 10:07||c_schmitz||Priority||none => urgent|
|2019-09-09 10:16||c_schmitz||Assigned To||p_teichmann => lime_release_bot|
|2019-09-09 10:17||c_schmitz||Status||assigned => new|
|2019-09-09 10:42||c_schmitz||Tag Attached: sprint|
|2019-09-18 15:29||cdorin||Note Added: 53629|
|2019-09-19 09:00||f_funke||Note Added: 53648|
|2019-09-19 09:54||DenisChenu||Note Added: 53651|
|2019-09-19 10:12||f_funke||Note Added: 53652|
|2019-09-19 10:48||DenisChenu||File Added: Capture d’écran du 2019-09-19 10-46-12.png|
|2019-09-19 10:48||DenisChenu||File Added: Capture d’écran du 2019-09-19 10-46-20.png|
|2019-09-19 10:48||DenisChenu||Note Added: 53653|
|2019-09-19 10:50||DenisChenu||Note Edited: 53653|
|2019-09-19 10:53||DenisChenu||Note Added: 53654|
|2019-09-19 11:11||cdorin||Project||Bug reports => Feature requests|
|2019-09-19 11:11||cdorin||Tag Detached: sprint|
|2019-09-19 11:11||cdorin||Priority||urgent => normal|
|2019-09-19 11:11||cdorin||Severity||@60@ => feature|
|2019-09-19 11:14||cdorin||Note Added: 53655|
|2019-11-25 15:49||Mazi||Note Added: 54773|
|2019-11-25 17:23||holch||Note Added: 54778|
|2019-11-29 09:33||f_funke||Note Added: 54886|
|2019-11-29 14:21||holch||Note Added: 54890|
|2019-11-29 15:28||Mazi||Note Added: 54891|
|2022-03-09 20:45||andyrue||Issue Monitored: andyrue|
|2022-03-09 20:45||andyrue||Bug heat||10 => 12|
|2022-03-09 20:46||guest||Bug heat||12 => 18|