[limesurvey-developers] Group preview modification, what do people think?

[Jason Cleeland]

Hi everyone,



Long time no chat (sorry).



I've written a modification to the group preview feature in LimeSurvey to
address a problem that a few people have complained to me about, and I want
everyone's opinion on how to implement it.



The problem is this:



When you have questions within a group that have conditions based on
questions in OTHER groups, they don't display when you preview the group.
They don't display because the conditions haven't been met (obviously) but
they can never be met because group preview doesn't allow other questions to
display.



I wanted to fix this so that any conditions based on questions OUTSIDE the
preview group were ignored. In other words, conditions within the group
would work normally, but conditions OUTSIDE the group would be considered as
met.



And that's what I've been able to do. I did it by hacking the relevance
setting for any conditions outside the preview group and changing them to "1
== 1" (ie: always met)



When I spoke to Carsten about it, he said that this issue had been raised
before and that I should make it user-selectable.



When I looked at the existing code, I think the way it has been solved
before is to simply make every single question in a group show up - the same
way it works for question previews.



I can see why this would suck - sometimes you want to test the conditions
functionality when previewing a group, and if all the conditions are
ignored, then you can't test them. But my modification means that any
conditions within the group still work.



Personally I think this means the change would meet everyone's needs and
doesn't create any new problems - only removes an existing annoyance. And if
that's the case, then adding any extra controls (ie: an option that lets you
turn this on and off) just clutters up the interface, and for something that
I don't think anyone would ever really need.



What do you think? I can add something to make selectable on a case by case
basis , but I think that may be over the top



Jason Cleeland

[Denis Chenu]

Hi Jason,

I like the idea, but (there are allways some but).

Actually : you have a solution to see question with condition based on
precedent group.
If you have q question with condition : G1Q1=="Y" and G2Q1=="Y" in
Group2, then preview group 2 with /G1Q1/Y (or &G1Q1=Y) in URL set the
value of G1Q1 to Y. Like prefilling URL system. There are a lack of
documentation on this ....
I think it's good to have this solution and not forcing relevance to 1.

You have another issue : with array_filter : we need too to have a way
to force array_filter (in 2.06 : all subq relevance). Have to think of
this too (but when we have time).

Maybe the best solution can be:
- Make a clean documentation on preview URL params (assign to me)
- If no extra URL parameters is set : force relevance to 1 ONLY if there
are condition in other group : a lot of time user have conditon in same
group : and showing all question seems really a bad idea for me (same
for token too : this one is great).
- Add a parameters (relevance=1) to force all question relevance to 1 (?
not needed surely)

Then : you don't have any new option in GUI but you have a solution to
allow condition with precedent group to be used.

Denis

Post by Jason Cleeland
Hi everyone,
Long time no chat (sorry).
I’ve written a modification to the group preview feature in LimeSurvey
to address a problem that a few people have complained to me about,
and I want everyone’s opinion on how to implement it.
When you have questions within a group that have conditions based on
questions in OTHER groups, they don’t display when you preview the
group. They don’t display because the conditions haven’t been met
(obviously) but they can never be met because group preview doesn’t
allow other questions to display.
I wanted to fix this so that any conditions based on questions OUTSIDE
the preview group were ignored. In other words, conditions within the
group would work normally, but conditions OUTSIDE the group would be
considered as met.
And that’s what I’ve been able to do. I did it by hacking the
relevance setting for any conditions outside the preview group and
changing them to “1 == 1” (ie: always met)
When I spoke to Carsten about it, he said that this issue had been
raised before and that I should make it user-selectable.
When I looked at the existing code, I think the way it has been solved
before is to simply make every single question in a group show up –
the same way it works for question previews.
I can see why this would suck – sometimes you want to test the
conditions functionality when previewing a group, and if all the
conditions are ignored, then you can’t test them. But my modification
means that any conditions within the group still work.
Personally I think this means the change would meet everyone’s needs
and doesn’t create any new problems – only removes an existing
an option that lets you turn this on and off) just clutters up the
interface, and for something that I don’t think anyone would ever
really need.
What do you think? I can add something to make selectable on a case by
case basis , but I think that may be over the top
Jason Cleeland

[Sam Mousa]

Hi Jason,

I have thought about this several times before.
In my experience most routing is usually based on a few questions (in
market research the demographics often decide which questions you'll see).

To properly preview a question or a group, ideally you want to do all
questions that are relevant to the group / question being previewed.
If you create a graph, starting at the target question or group and
iteratively adding all questions that appear in their relevance equations,
you could identify a relevant subset of the survey with respect to your
target question or group.

By setting the relevance of all other questions / groups to 0 you would
effectively create a slimmed down version only targeting the question or
group you actually want to test.

The advantage of this approach is that everything would work properly for
the previewed questions: array filter, text substitution and so on.


To take it one step further you could even check simple relevance equations
and prefill those questions while setting them to be always hidden.

This way of previewing would in my opinion be best served via a 2nd preview
button.

Other future improvements could be generating valid traces for the survey
and picking 1 that contains the target question or group.


With respect to your actual question (how to make it available) in my
opinion the best way is just to add a button to the group bar; this way
it'll be easily accessible and we can phase out the first button if we
discover it is not being used. Hiding it as a configuration option will
guarantee noone uses it because they simply won't know about it.

Cheers,

Post by Denis Chenu
Hi Jason,
I like the idea, but (there are allways some but).
Actually : you have a solution to see question with condition based on
precedent group.
If you have q question with condition : G1Q1=="Y" and G2Q1=="Y" in
Group2, then preview group 2 with /G1Q1/Y (or &G1Q1=Y) in URL set the
value of G1Q1 to Y. Like prefilling URL system. There are a lack of
documentation on this ....
I think it's good to have this solution and not forcing relevance to 1.
You have another issue : with array_filter : we need too to have a way
to force array_filter (in 2.06 : all subq relevance). Have to think of
this too (but when we have time).
- Make a clean documentation on preview URL params (assign to me)
- If no extra URL parameters is set : force relevance to 1 ONLY if there
are condition in other group : a lot of time user have conditon in same
group : and showing all question seems really a bad idea for me (same
for token too : this one is great).
- Add a parameters (relevance=1) to force all question relevance to 1 (?
not needed surely)
Then : you don't have any new option in GUI but you have a solution to
allow condition with precedent group to be used.
Denis

Post by Jason Cleeland
Hi everyone,
Long time no chat (sorry).
I’ve written a modification to the group preview feature in LimeSurvey
to address a problem that a few people have complained to me about,
and I want everyone’s opinion on how to implement it.
When you have questions within a group that have conditions based on
questions in OTHER groups, they don’t display when you preview the
group. They don’t display because the conditions haven’t been met
(obviously) but they can never be met because group preview doesn’t
allow other questions to display.
I wanted to fix this so that any conditions based on questions OUTSIDE
the preview group were ignored. In other words, conditions within the
group would work normally, but conditions OUTSIDE the group would be
considered as met.
And that’s what I’ve been able to do. I did it by hacking the
relevance setting for any conditions outside the preview group and
changing them to “1 == 1” (ie: always met)
When I spoke to Carsten about it, he said that this issue had been
raised before and that I should make it user-selectable.
When I looked at the existing code, I think the way it has been solved
before is to simply make every single question in a group show up –
the same way it works for question previews.
I can see why this would suck – sometimes you want to test the
conditions functionality when previewing a group, and if all the
conditions are ignored, then you can’t test them. But my modification
means that any conditions within the group still work.
Personally I think this means the change would meet everyone’s needs
and doesn’t create any new problems – only removes an existing
an option that lets you turn this on and off) just clutters up the
interface, and for something that I don’t think anyone would ever
really need.
What do you think? I can add something to make selectable on a case by
case basis , but I think that may be over the top
Jason Cleeland

------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

[Tony Partner]

Hi Jason,



I like it. Period.



Having read Denis’ and Sam’s replies and understanding their concerns, I still think simplicity is the approach to follow.



Having spent a fair amount of time in the forums, I suspect most users would have a hard time spelling “URL”, let alone appending parameters to view questions rendered irrelevant by previous groups.



Cheers,



T.





From: Sam Mousa [mailto:***@mousa.nl]
Sent: September-19-14 3:29 AM
To: limesurvey-***@lists.sourceforge.net
Subject: Re: [limesurvey-developers] Group preview modification, what do people think?



Hi Jason,



I have thought about this several times before.

In my experience most routing is usually based on a few questions (in market research the demographics often decide which questions you'll see).



To properly preview a question or a group, ideally you want to do all questions that are relevant to the group / question being previewed.

If you create a graph, starting at the target question or group and iteratively adding all questions that appear in their relevance equations, you could identify a relevant subset of the survey with respect to your target question or group.



By setting the relevance of all other questions / groups to 0 you would effectively create a slimmed down version only targeting the question or group you actually want to test.



The advantage of this approach is that everything would work properly for the previewed questions: array filter, text substitution and so on.





To take it one step further you could even check simple relevance equations and prefill those questions while setting them to be always hidden.



This way of previewing would in my opinion be best served via a 2nd preview button.



Other future improvements could be generating valid traces for the survey and picking 1 that contains the target question or group.





With respect to your actual question (how to make it available) in my opinion the best way is just to add a button to the group bar; this way it'll be easily accessible and we can phase out the first button if we discover it is not being used. Hiding it as a configuration option will guarantee noone uses it because they simply won't know about it.



Cheers,





On Fri, Sep 19, 2014 at 8:43 AM, Denis Chenu <***@shnoulle.net> wrote:

Hi Jason,

I like the idea, but (there are allways some but).

Actually : you have a solution to see question with condition based on
precedent group.
If you have q question with condition : G1Q1=="Y" and G2Q1=="Y" in
Group2, then preview group 2 with /G1Q1/Y (or &G1Q1=Y) in URL set the
value of G1Q1 to Y. Like prefilling URL system. There are a lack of
documentation on this ....
I think it's good to have this solution and not forcing relevance to 1.

You have another issue : with array_filter : we need too to have a way
to force array_filter (in 2.06 : all subq relevance). Have to think of
this too (but when we have time).

Maybe the best solution can be:
- Make a clean documentation on preview URL params (assign to me)
- If no extra URL parameters is set : force relevance to 1 ONLY if there
are condition in other group : a lot of time user have conditon in same
group : and showing all question seems really a bad idea for me (same
for token too : this one is great).
- Add a parameters (relevance=1) to force all question relevance to 1 (?
not needed surely)

Then : you don't have any new option in GUI but you have a solution to
allow condition with precedent group to be used.

Denis

Post by Jason Cleeland
Hi everyone,
Long time no chat (sorry).
I’ve written a modification to the group preview feature in LimeSurvey
to address a problem that a few people have complained to me about,
and I want everyone’s opinion on how to implement it.
When you have questions within a group that have conditions based on
questions in OTHER groups, they don’t display when you preview the
group. They don’t display because the conditions haven’t been met
(obviously) but they can never be met because group preview doesn’t
allow other questions to display.
I wanted to fix this so that any conditions based on questions OUTSIDE
the preview group were ignored. In other words, conditions within the
group would work normally, but conditions OUTSIDE the group would be
considered as met.
And that’s what I’ve been able to do. I did it by hacking the
relevance setting for any conditions outside the preview group and
changing them to “1 == 1” (ie: always met)
When I spoke to Carsten about it, he said that this issue had been
raised before and that I should make it user-selectable.
When I looked at the existing code, I think the way it has been solved
before is to simply make every single question in a group show up –
the same way it works for question previews.
I can see why this would suck – sometimes you want to test the
conditions functionality when previewing a group, and if all the
conditions are ignored, then you can’t test them. But my modification
means that any conditions within the group still work.
Personally I think this means the change would meet everyone’s needs
and doesn’t create any new problems – only removes an existing
an option that lets you turn this on and off) just clutters up the
interface, and for something that I don’t think anyone would ever
really need.
What do you think? I can add something to make selectable on a case by
case basis , but I think that may be over the top
Jason Cleeland

[Thomas White]

good ideas.

Given the dependencies on other questions, is there a way to let people
dynamically set those values to ensure that the on-page group behavior is
appropriate? One option is to identify all the immediate dependencies and
display those questions in addition to the group pages so that users can
use the normal GUI approach to set those other variables and have the
results cascade to the group preview. Another (perhaps easier) option is
to have a single extra question that lets authors manually change the value
of variables - e.g. a text entry box where one can enter "q1_b = 'Y'",
press a button, and have that call the appropriate EM routines to process
the equation, set the values, and then call the javascript to refresh the
on-page EM routines. I've taken this last approach in the past (in a
different software), and it worked well and the authors liked it.

/Tom

Post by Denis Chenu
Hi Jason,
I like the idea, but (there are allways some but).
Actually : you have a solution to see question with condition based on
precedent group.
If you have q question with condition : G1Q1=="Y" and G2Q1=="Y" in
Group2, then preview group 2 with /G1Q1/Y (or &G1Q1=Y) in URL set the
value of G1Q1 to Y. Like prefilling URL system. There are a lack of
documentation on this ....
I think it's good to have this solution and not forcing relevance to 1.
You have another issue : with array_filter : we need too to have a way
to force array_filter (in 2.06 : all subq relevance). Have to think of
this too (but when we have time).
- Make a clean documentation on preview URL params (assign to me)
- If no extra URL parameters is set : force relevance to 1 ONLY if there
are condition in other group : a lot of time user have conditon in same
group : and showing all question seems really a bad idea for me (same
for token too : this one is great).
- Add a parameters (relevance=1) to force all question relevance to 1 (?
not needed surely)
Then : you don't have any new option in GUI but you have a solution to
allow condition with precedent group to be used.
Denis

Post by Jason Cleeland
Hi everyone,
Long time no chat (sorry).
I’ve written a modification to the group preview feature in LimeSurvey
to address a problem that a few people have complained to me about,
and I want everyone’s opinion on how to implement it.
When you have questions within a group that have conditions based on
questions in OTHER groups, they don’t display when you preview the
group. They don’t display because the conditions haven’t been met
(obviously) but they can never be met because group preview doesn’t
allow other questions to display.
I wanted to fix this so that any conditions based on questions OUTSIDE
the preview group were ignored. In other words, conditions within the
group would work normally, but conditions OUTSIDE the group would be
considered as met.
And that’s what I’ve been able to do. I did it by hacking the
relevance setting for any conditions outside the preview group and
changing them to “1 == 1” (ie: always met)
When I spoke to Carsten about it, he said that this issue had been
raised before and that I should make it user-selectable.
When I looked at the existing code, I think the way it has been solved
before is to simply make every single question in a group show up –
the same way it works for question previews.
I can see why this would suck – sometimes you want to test the
conditions functionality when previewing a group, and if all the
conditions are ignored, then you can’t test them. But my modification
means that any conditions within the group still work.
Personally I think this means the change would meet everyone’s needs
and doesn’t create any new problems – only removes an existing
an option that lets you turn this on and off) just clutters up the
interface, and for something that I don’t think anyone would ever
really need.
What do you think? I can add something to make selectable on a case by
case basis , but I think that may be over the top
Jason Cleeland

------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

[Holger Rothemund]

Hi!

Good discussions. With more and more features in Limesurvey we should
really think about the preview options.

[Marcel Minke]

[Brad Murphy]

Tammy,

Now I'm confused :-) I'll keep it just in case I decide to use it after I receive the color match you're working on.

BTW, can you tell me how much flattener I should be adding?

Thanks,

Brad


________________________________
From: Marcel Minke <***@web.de>
To: limesurvey-***@lists.sourceforge.net
Sent: Monday, September 22, 2014 3:26 AM
Subject: Re: [limesurvey-developers] Group preview modification, what do people think?



Hi everyone,

@Jason: I consider this a very useful feature. Thanks for developing
it.

Regarding the implementation I like Holger's suggestion to just have
some kind of configuration bar on top at the group preview where you
can switch the feature on/off. We should only show it if conditions
based on other groups exist.
This doesn't add additional complexity to the admin backend and
allows users to easily switch between the different modes.

Best regards,
Marcel



Am 19.09.2014 um 14:54 schrieb Holger Rothemund:

Hi!

Good discussions. With more and more features in Limesurvey we should really think about the preview opt

[Jason Cleeland]

Hi Everyone,



Thanks for the replies J

[Thibault Le Meur]

Hi guys,
Sorry I couldn't jump into this thread earlier.

I agree with your proposal Jason.


Thibault

Post by Jason Cleeland
Hi Everyone,
Thanks for the replies J

[Jason Cleeland [mailto:]]

Can I propose the following:



1) I apply my initial patch, which simply nullifies any specific
conditions from outside the displayed group - and that becomes the default
scenario



2) I/We/Someone develop a small interface that allows users to set /
nullify specific conditions while they are previewing a group - this could
be done by having a css/floating interface on the group preview page that
reloads the preview page using the URL prefilling that Denis mentioned





Jason



From: Jason Cleeland [mailto:***@cleeland.org]
Sent: Friday, 19 September 2014 11:59 AM
To: limesurvey-***@lists.sourceforge.net
Subject: [limesurvey-developers] Group preview modification, what do people
think?



Hi everyone,



Long time no chat (sorry).



I've written a modification to the group preview feature in LimeSurvey to
address a problem that a few people have complained to me about, and I want
everyone's opinion on how to implement it.



The problem is this:



When you have questions within a group that have conditions based on
questions in OTHER groups, they don't display when you preview the group.
They don't display because the conditions haven't been met (obviously) but
they can never be met because group preview doesn't allow other questions to
display.



I wanted to fix this so that any conditions based on questions OUTSIDE the
preview group were ignored. In other words, conditions within the group
would work normally, but conditions OUTSIDE the group would be considered as
met.



And that's what I've been able to do. I did it by hacking the relevance
setting for any conditions outside the preview group and changing them to "1
== 1" (ie: always met)



When I spoke to Carsten about it, he said that this issue had been raised
before and that I should make it user-selectable.



When I looked at the existing code, I think the way it has been solved
before is to simply make every single question in a group show up - the same
way it works for question previews.



I can see why this would suck - sometimes you want to test the conditions
functionality when previewing a group, and if all the conditions are
ignored, then you can't test them. But my modification means that any
conditions within the group still work.



Personally I think this means the change would meet everyone's needs and
doesn't create any new problems - only removes an existing annoyance. And if
that's the case, then adding any extra controls (ie: an option that lets you
turn this on and off) just clutters up the interface, and for something that
I don't think anyone would ever really need.



What do you think? I can add something to make selectable on a case by case
basis , but I think that may be over the top



Jason Cleeland


------=_NextPart_000_0110_01CFD64C.D69EBEA0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:432285137;
mso-list-type:hybrid;
mso-list-template-ids:233459206 201916433 201916441 201916443 201916431 201916441 201916443 201916431 201916441 201916443;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>Hi Everyone,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Thanks for the replies </span><span style='font-family:Wingdings;color:#1F497D'>J</span><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>

[unknown]

This is a multi-part message in MIME format.
--------------020005070606040602050001
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi everyone,

@Jason: I consider this a very useful feature. Thanks for developing it.

Regarding the implementation I like Holger's suggestion to just have
some kind of configuration bar on top at the group preview where you can
switch the feature on/off. We should only show it if conditions based on
other groups exist.
This doesn't add additional complexity to the admin backend and allows
users to easily switch between the different modes.

Best regards,
Marcel

Post by Holger Rothemund
Hi!
Good discussions. With more and more features in Limesurvey we should
really think about the preview options.