The implementation of "other" with single choice and dropdown is working as it should.

Very old issue : wok like this since 1.81 and maybe before.

Then : more a feature than a bug.

Yes, I know that this is an old one, but nevertheless something that really wrong (I use the word wrong only in rare cases - but this is really wrong, wrong, wrong).

Wrong!

Would this affect the way in which data is currently collected by LS users? I see Frederik's point and I agree to it (from a methodological perspective)

In mine template (since SkeletonQuest) : i hide the opther checkbox since it was not a real checkbox.

And there are nbo checkbox (for other) in Multiple choice with comment : https://demo.sondages.me/47483?lang=fr#

There is currently no datafield in LimeSurvey to store the state of the select box.
Fixing this would require to remodel this part, also will require fixing of all existing response tables because the data structure of these would change ( an additional field will be needed for each multiple choice questions present in the survey).

This is a major issue for me as well. I have identified that this is the primary cause of people dropping out of surveys (as they think they can't choose other when the checkbox doesn't tick). It is also certainly resulting in under-reporting of other. I need respondents to be able to choose other without entering text if they don't want to.

This has a flow-on effect that when exporting to SPSS you need to generate a variable for other to run multiple response tables. This can be done with a syntax, but it is added time and complication.

@tixeon : can you try with

.checkbox-text-item .other-checkbox[aria-hidden] {
    display: none;
}

in your custom.css and see if it's better

Capture d’écran du 2020-11-18 08-14-10.png (14,870 bytes)   

Capture d’écran du 2020-11-18 08-14-10.png (14,870 bytes)   

I agree that this makes no sense, what so ever. Even if it was always like this, this doesn't make it right.

I think we need to allow people to tick "other" and then the survey admin must be able to decide if the text box for other should be mandatory or not.

I don't think the way it currently is, is a good solution, especially as it usually works differently in other survey tools. "Other" should always be just a normal answer option, because usually we need to include it also into analysis. So I am not sure why some one thought it would be a good idea to not treat it like a normal answer option.

But while we are at it and have to fix the database structure anyway: Why not make it really right and flexible? I think we should have the possibility to put a text field for any of the answers. Currently this is done via workarounds by hiding text boxes from a mutliple with comments. We could actually get rid of this whole question type if we offer the option to show a comment box to any of the answer options / subquestions and the survey creator decides by ticking a check box for which of the answeroptions / subquestions they want to show an additional text box and if it should be mandatory to fill the text box, if the option was chosen.

I agree that being able to append a free text box to any subquestion (answer option) is needed to ensure Limesurvey keeps up with other survey applications. I have an account with another online survey tool that I use if a survey requires free text boxes on 2 or more (but not all) answer options because the work-around in limesurvey is too annoying for questionnaires with lots of questions of this type (and I can't always get it to work).
Also, I was given a workaround for other specify in the forum that works really well, and have now switched to always using this work-around for other specify on multiple response questions (won't bother using the built-in option). https://forums.limesurvey.org/forum/can-i-do-this-with-limesurvey/122927-multiple-response-other-that-can-be-ticked

The change is quite big as underlined by Carsten earlier. Smth to be discussed later (for LS5)

I agree with all that had been said. I used LimeSurvey quite a bit in the last few years, and that is an issue that, if solved, would make it easier for respondents to fill in questionnaires without getting more annoyed than necessary, I think ;)

Thanks for the discussion so far!
It would be great, if you could keep this point in the backlog, Dorin.

Should we label this as a feature request?

Well, then we could just go and delete it. When was the last time a feature request made it into Limesurvey? ;-)

Just burn it all! Lol
Well, it is just better for handling bugs, and hence, for handling feature requests :)

;-) Just saying.

The "feature request" section very much works like the "round paper storage basket" under to your desk. ;-)

I understand...