Why answers in multiple choice questions are not called answers but subquestion?
I have tested that, they are not some subquestions but tick-able answers!
Is it just my version 2.5 is strange or some kind of translation from German issue?

I also lost my answers straight after changing single answer option to multiple answer version.

Hi, Milosz,
this is the explanation:
For a single choice question there is one field in the dataset containing the code of the given answer.
This is different in multiple choice questions. Here for each of these "subquestions" there is a field in the dataset containing "1" meaning "selected" or "0" (or blank) meaning "not selected".
So in the dataset for each of these "questions" there are several "subquestion" fields.

And that's also the explanation that you loose the text.
It's a different structure in the database.
Once it's the label of an answer option, once it's the "question text of the subquestion" (and the label of the answer option are "Yes"/"No" or "selected"/"not selected" or so.

And to answer your other thread: Even monkeys should be able to read the manual - and be able to accomplish the transfer from 2.0 to 2.5 screenshots

Best regards
Joffm

Joffm wrote: in the dataset containing the code.....

You are talking about the developer point of view. User interface is for users not for programists. It's hard to explain to a normal person that a subquestion is actually an 'answer' because it is something exactly opposite. Sorry just trying to help for future updates to help the great software be more intuitive.

Joffm wrote: Even monkeys should be able to read the manual - and be able to accomplish the transfer from 2.0 to 2.5 screenshots

Yes, sorry I did my homework and went through that:
www.limesurvey.org/manual/Creating_surve...nistrative_interface
but as in the software the instructions kind of stopped on the question topic and not followed with the information how to add the answer to the question. But I found it elsewhere since then, thanks. Via Google because from the manual page: www.limesurvey.org/manual/LimeSurvey_Manual I didn't know where to click to.
But about making the transfer of the screenshots, how was I to transfer the look to current look:
www.limesurvey.org/manual/Adding_answers_or_subquestions
(no big green or other colour icon looking like this, trust me I looked for it)

Sorry, I am just a user and just trying to help make the software even better. The Less people are frustrated and the easier the software the more users will use it (and less will Bounce, using Google analytics language).

The manual is a wiki, which means anyone can help to make it better.

Milosz wrote: You are talking about the developer point of view. User interface is for users not for programists. It's hard to explain to a normal person that a subquestion is actually an 'answer' because it is something exactly opposite. Sorry just trying to help for future updates to help the great software be more intuitive.

If you can do your best to understand the concept, it's not so hard to explain... As said by @Joffm this is highly related with the overall survey logic & db structure:
If you have a question expecting a unique value (e.g. numeric, text, radio, dropdown), this question require only a valid answer & one field in the db.
If you have a multiple question, all "answer options" are in fact subquestions requiring a yes or not answer. Each subquestion requires a column in the db .

IMHO the "subquestion" term is fully valid and the matter is not if GUI should be designed for users OR for programists. Only have to be both: valid AND intuitive (user-friendly)

I can see where Milosz comes from. But the subquestions are called subquestions for sooo long now, that it would cause probably quite some problems if this would be changed now.

The answer options vs. subquestion discussion is in fact more attributed to development. But I think it is not so hard to understand that we should go through a process to change this now. And as they are in fact different (but basic users might see it as the same) it is good to have some differentiation, as soon as you get deeper into it. Nevertheless, I can understand that it might seem unintuitive at the beginning. I still wouldn't change it at this point, as it has been used for a few years now and it has not caused bigger upsets among new users.

I’m not sure which language version of LS Milosz uses but this may be also a problem of translation. For example, I had difficulties with translating the “subquestion” term into Polish and I’m not very happy with the translation (subquestion =subpytanie, question=pytanie). This is not beautiful Polish but I decided to use this literal translation because this seemed to me functional for users, especially those who use a manual in English. Nevertheless, Polish linguistic purists may feel not satisfied with this. On the other hand, this is obvious for me that subquestions and answer options should be clearly distinguished. And this is important not only from a developer point of view but also for a user if he/she wants to use more advanced functionalities (for example expressions).

Ben_V wrote: Only have to be both: valid AND intuitive (user-friendly)

Are you still talking about LS
There is currently no sign that LS will start from scratch, but I would bet that the db structure would be changed a lot.
The legacy code is already a technical debt. Thousands separator come to my mind.

As long as relevance equations are not applicable to answers you want to see sub-questions everywhere.

...and the matter is not if GUI should be designed for users OR for programists.

It has been suggested that future versions have a "basic" and an "advanced" admin GUI.

tpartner wrote:

...and the matter is not if GUI should be designed for users OR for programists.

It has been suggested that future versions have a "basic" and an "advanced" admin GUI.

Seeing how Tammo's effort is/was taken into consideration I would guess that this will not happen in the next decade or so.