Hello All,

I do not feel the 3rd situation Carsten listed is an actual issue since the user explicitly selected an answer, even if that selection is an indication that there is no selection, the user did respond. So that cuts it down to 2 situations. At the heart of this issue is how do we handle questions that were never presented to the user due to the conditionals system. For this situation I agree, in part, with Jason's comments below.

If the question was never presented to the user is should not be in the result set (note: result set => list of results in the report) for that user, on the other hand if the user was presented the question and elected not to provide an answer than it should be in the result set for that user (a response of nothing or NULL). For a given user's result set if the user saw a question and did not answer it the question would be present with no response, if the user never saw the question it would not even appear in the result set.

So the question seem to be how to record or identify which is the correct situation. Recording something in the database associated to a users response just for the sake of tracking if the user saw the question/input or not seems a little overkill especially given a survey where there were there are no required questions thus the user could elect to not answer any of the question. This would results in a response being recorded for every question for that user even though the user gave no responses. It would seem to me that this would be better suited as a function of the conditional system.

The conditional system could provide a mechanism to replay a given state of a user (this is needed for resuming a survey anyway) in a 'reports mode' (bad name) such that the output would be a result set (reminder: result set => list of results in the report) that contains all the questions the user saw and his/her respective answers (or lack there of).

Anyone else have suggestions/comments here?


M

-----Original Message-----
From: limesurvey-developers-bounces@lists.sourceforge.net on behalf of Jason Cleeland
Sent: Mon 5/26/2008 6:16 AM
To: limesurvey-developers@lists.sourceforge.net
Subject: Re: [limesurvey-developers] Not answered questions in LS2

Hi Carsten and everyone,

In regards to questions that never displayed, it was always my opinion that
it would be obvious by the answers to preceding questions that this question
would not have been offered - so trying to indicate something in that answer
would only complicate matters.

So I think it is best to leave the answer empty where a question has never
been offered.

The "No Answer" option was only ever added to allow people to "unselect" a
radio button group if they accidentally clicked one. So if it weren't for
the problem of radio button groups, this option wouldn't need to exist. In
my opinion, the "No Answer" choice should save exactly the same as if the
participant had not selected anything.

I think a NULL should be recorded in any question that has not had a
deliberate answer recorded. There should be nothing recorded at all, if the
question was never displayed.

The NULL would indicate a positive response of nothing. An absence of any
value would indicate, without complicating matters, that the question was
never offered.

Jason

-----Original Message-----
From: limesurvey-developers-bounces@lists.sourceforge.net
[mailto:limesurvey-developers-bounces@lists.sourceforge.net] On Behalf Of
Carsten Schmitz
Sent: Monday, 26 May 2008 7:48 PM
To: limesurvey-developers@lists.sourceforge.net
Subject: [limesurvey-developers] Not answered questions in LS2

Hello!

I had a short talk to Michael on this subject last week and just wanted to
write down my thoughts on this.

In LimeSurvey 1 we have currently the problem that there is no flag for
unanswered question.
This leads to the problem that the results of an unanswered question does
look exactly the same like a question that was not seen or touched by  the
user.

So how do we handle different types of unanswered questions? Yes.. there are
different types, lets see:

1) Unanswered because it was not seen due to conditions
2) Unanswered because the user saw it but he/she did not click an option
3) Unanswered because the user marked it as 'No Answer',

None of these cases is easy to grab. Why?

to 1.) Unanswered because it was not seen due to conditions: This should be
marked in the result output as 'Not seen' because any 3rd party program ( to
where the results are exported to) does not know about the
conditions/branching. I propose to fill these database fields with 'NULL'.
Not recording anything is an option when the export does handle it
accordingly but makes it alot harder to do SQL evaluations right on the
result tables.
to 2.)Unanswered because the user saw it but he/she did not click an
option: Does sound easy? Yes.. you could just fill the databse field with an
empty string.. But what about single option radiobuttons? You cannot
un-check them in case you have accidentally clicked an answer option. This
is strongly connected to option 3:
to 3.) Unanswered because the user marked it as 'No Answer': So do we force
the user to mark a no answer then?  Letting the 'no answer' option be a
normal choice and record it accordingly may bite with the Radiobutton
problem.

Some solution proposals:

Case1: NULL on export/database
Case2: Some kind of 'not-touched' flag on DB save/export to indicate the
user did ignore the question??  Especially with default question this is a
problem. Remember that the non-touched flag will also be important in the
future to catch 'survey racers' who run through a survey and don't click
anything or just click anything to get through with it. We should discuss if
every question should be mandatory in that way that the user has to click at
least 'No answer' for a question.
Case3: Non-Mandatory question should always have an "No Answer"
equivalent option.

Any thought, opinions on this? It would be great if we can design this from
the start as future-proof as possible

Regards

Carsten.






-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
limesurvey-developers mailing list
limesurvey-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
limesurvey-developers mailing list
limesurvey-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers