I can't see why the user has to enter ID manually when creating question groups or questions. There should be an option letting LS auto generate IDs which the user can override if needed.

I think sometimes it is useful to have possibility to have "one questions, one page" for the first part of the survey; and "more questions, one page" for the sopio-demographic questions.

So it will be useful to display questions in these different ways, in differen section of the same survey. If questionnaire requires it.


Regards,
Arnaldo

Use of the #answerNNXNNXNN id means code must be updated for all questions that are re-used, in order to re-target form elements. This is tedious, error prone, and frustrating.

The solution proposed does not suggest removing the #id, but adding an alternative for scripting targetting.

Today with right "Manage labels", user can delete/modify all labels.

It's frustrating for everyone involved when surveyors detect wrong answers in their post-submit "print answers" link, only to realize by then it's too late.

Such a feature would create more reliable and more user friendly surveys.

See more details in http://www.limesurvey.org/support/forums/20/52495

The idea is to develop a tree view like windows explorer with nodes to navigate more faster between Group, questions and subquestions

Currently responses are checked on the client. But HTTP can easily be tampered such that arbitrary values are sent to the server. (E.g. the value 5 when only 1 to 4 is allowed.)

Integration With Joomla 1.6

We should copy a whole group not just a question, then looping this group depending on a question.

For ex: how many pets do you have: 3

For each pet, you should have the possibility to answer the same question group.

In some circumstances it's quite difficult to statically configure the endURL of a survey.

An example of this is when hosting the survey in a portlet as part of a portal container. Portlet render URLs tend to be quite complex in construction and it's certainly inadvisable (and quite difficult) to construct them statically.

I am a manager at a small enterprise and I would like to ask my employees for completing a self-assessment form created using LimeSurvey. However, before forwarding it to the board, I would like to add at least some comments to each completed survey for each employer (alternatively a reply to 5-10 questions per completed questionnaire would also be ok).

For 'us psychologists' (researchers) it is often necessary to randomise participants over 'conditions' (in the research sense, not in the LimeSurvey sense). For example, we may want to present 50% with group 3 and 50% with group 4. To make matters a bit more, eh, challenging, it can sometimes be useful to make this randomisation dependent on earlier answers (i.e., only randomise participants with a certain profile; present all others with group 5), or to randomise different proportions of participants to different groups (i.e. 60% to group 3, 20% to group 4, 10% to group 5, and 10% to group 6).

So I thought it would be pretty cool if that could be implemented :-)

Sometimes when there is an array question containing an n-point scale with multiple subquestions, some of the subquestions need to be filtered out (e.g. if it is a scale of satisfaction with health, family, friends and job, if the respondent does not have a job then the "satisfaction with job" subquestion should not appear).
There is currently the option of "array filter" to synchronize a multiple answer type question with an array, but sometimes that is not enough, especially when only a few subquestions actually need filtering (e.g. in the previous example, there is no point to ask if the respondent has a family, friends or health, but it is necessary to ask if he/she has a job).
Therefore, it would be useful to include in the "conditions" tab the possibility of applying conditions not only to questions, but to subquestions.

I would like to see a tool that could toggle the "Mandatory" setting on all questions in the survey from "on" to "off" and vice versa.

This would make the Q/A process on long surveys much easier - one wouldn't need to answer every question just to check a fix on page 16 of a survey.

When creating / testing / editing a survey mandatory question are really annoying. I can think of these situations where making questions of a survey (temporary) non mandatory will be a great improvement:

1. (Developer) Testing possible bugs
When importing a survey for testing mandatory question can drive you nuts.

2. (User) Previewing a survey which is in development
You just want to take a look at the questions and survey design, having to answer all mandatory questions is a mess.

When i make a survey, LimeSurvey uses its internal ID to reference this survey in the URL. The idea is change this URL by a more easy.

Example: A survey with employees that did MBA.

"normal URL"
http://my.site.com/survey/index.php?sid=37424

"Clean/easy URL"
http://my.site.com/survey/mba

so, /mba is a alternative URL to /index.php?sid=37424.

Say to my user some thing like "Please, enter in 'my.site.com/survey/mba' and answer the survey!" is more easy (and mnemonic) that say a URL with text and numbers.

The assessment options in Limesurvey are currently reasonably limited, and a personality type assessment would be useful.

The type of survey I'm trying to build at the moment is a personality survey where a user goes through a number of questions, and based on the totals of their answers to options A, B or C, their personality trait can be identified.

eg Based on the percentage of A, B and C a particular trait might be highlighted. This trait would be then displayed to the survey participant, as well as being recorded as the result of the survey along with the answers and assessment score ideally.

> 50% A = Type X
> 50% B = Type Y
> 50% C = Type Z
> 40% A & > 40% B = Type XY
> 40% B & > 40% C = Type YZ
> 40% A & > 40% C = Type XZ
> 30% A & > 30% B & > 30% C = Type XYZ

When using this I make mistakes with my spelling and I think that one needs to be added. It would be a nice feature.