Liebe Community,  

ich nutze Version 2.64 und erstelle eine Umfrage mit vier Experimentalgruppen. Diese Experimentalgruppen habe ich über eine Relevanzgleichung differenziert. Innerhalb jeder Experimentalgruppe werden drei Szenarien als jeweils einzelne Fragengruppe in randomisierter Reihenfolge präsentiert. Hier wird bei jedem Szenario von den Teilnehmenden eine Entscheidung getroffen, die ein rechnerisch bestimmbares Ergebnis hat. Die Berechnung dieses Ergebnisses nehme ich mittels Ausdrucksmanager vor. Nach der Bearbeitung der drei Szenarien präsentiere ich den Teilnehmenden ein Endergebnis, das sich als reine Addition aus den Zwischenergebnissen der drei Szenarien ableitet. Bis hierhin funktioniert alles einwandfrei.

Jetzt möchte ich der Versuchsperson allerdings zusätzlich nach der Bearbeitung des jeweiligen Szenarios ihr Zwischenergebnis auf einer neuen Seite präsentieren. Grundsätzlich möchte ich die Fragen pro Fragengruppe auf einer Seite präsentieren. Da die drei Szenarien allerdings in randomisierter Reihenfolge präsentiert werden, weiß ich nicht, wie ich das umsetzen kann. Hat hier jemand eine Idee? 
In jedem Fall soll die Präsentation des Zwischenergebnisses erst erfolgen, nachdem die Teilnehmenden eine finale und nicht mehr änderbare Entscheidung im Szenario getroffen haben. Gibt es notfalls eine Lösung bei der die vorherigen Fragen zum Szenario bestätigt werden und danach auf der gleichen Seite (und damit innerhalb der gleichen randomisierten Fragengruppe) das Zwischenergebnis angezeigt wird, ohne dass die Eingaben in den oberen Fragen noch änderbar sind?

Ich habe die Umfrage einfach mal angehängt. Weil es sich um mein erstes größeres Umfrageprojekt mit LimeSurvey handelt sind bestimmt noch einige ineffiziente Lösungen und ähnliche Probleme vorhanden. Ich hoffe, das seht ihr mir nach

Vielen Dank schonmal für eure Hilfe!

 

Da man in Limesurvey die Fragengruppen dazu missbrauchen muss, um "Seiten" zu generieren wenn man Gruppe für Gruppe anzeigt, sehe ich da keine einfache Möglichkeit.

Wenn die Fragen alle einzeln angezeigt würden, dann könnte man das über Fragengruppen lösen und halt einfach als letzte Frage das Zwischenergebnis anzeigen. Aber wenn du alle Fragen dieser bestimmten Gruppe auf einer Seite anzeigen willst, dann musst du diese in eine Gruppe packen und damit würde die "Ergebnisseite" ja bei der Randomisierung von der Fragengruppe getrennt.

Jetzt müsste man überlegen, ob man irgendwie abfragen kann, welche Fragengruppe vor der Ergebnisseite angezeigt wurde (ich glaube man kann die Position einer Frage/Gruppe ermitteln) und dann halt die entsprechende Fragengruppe analysieren. Das müsste man sich mal genauer anschauen.

Vielleicht fällt Joffm ja was Gutes ein.

Ach, danke @holch. Habe ich den Ball wieder?
Na gut:
Noch etwas roh gedacht.
Zunächst habe ich einmal umsortiert: Alle Gruppen zu einer "gleichung hintereinander.

Jetzt aber: Was heißt Zwischenergebnis?
Ist es das aufkumulierte Ergebnis der drei Szenarien, also nach dem ersten das Ergebnis dieses ersten Szenarios, nach dem zweiten die Summe der beiden Ergebnisse, und am Ende die Summe aller drei?
Das wäre recht leicht, indem hinter jede Gruppe eine Gruppe (ohne Randomisierungsgruppenname) gesetzt wird.
Darin eine Textanzeige mit immer demselben Code:
Ihr bisheriges Zwischenergebnis: 
ascore: {sum(if(is_empty(ascoreMAF1),0,ascoreMAF1), if(is_empty(ascoreMAF2),0,ascoreMAF2), if(is_empty(ascoreMAF3),0,ascoreMAF3))}

pscore: {sum(if(is_empty(pscoreMAF1),0,pscoreMAF1), if(is_empty(pscoreMAF2),0,pscoreMAF2), if(is_empty(pscoreMAF3),0,pscoreMAF3))}

Das meinst Du ber wohl nicht.
Wenn nach jedem Szenario das Ergebnis kommen soll, gibt es wohl zwei Möglichkeiten.
Beide hat @holch ja schon angedacht.
Die erste und sicherlich beste: 
Stelle die Fragen einzeln und nicht "gruppenweise". Es sind doch nur zwei.

Die zweite Möglichkeit ist jetzt noch ein bisschen grob geschnitzt, könnte aber funktionieren.
Man benutzt die Property ".gseq". Diese gibt die Nummer der Gruppe in sequentieller Reihenfolge an, und zwar in der Reihenfolge der Anzeige.
Wenn wieder zwischen die Szenariogruppen die Ergebnisgruppen kommen, haben die Szenatiogruppen die Nummern 1,3,und 5.
Dazu kommt in jede der Szenariogruppen eine zusätzliche "Gleichungsfrage", z.B. KIF1seq.
Darin der Code {MAF1a.gseq}
KIF2seq : {MAF2a.gseq}
KIF3seq : {MAF3a.gseq}

Dann kann man in die erste Ergebnisgruppe mit diesem IF-Konstrukt das Ergebnis anzeigen:
{if(KIF1seq==1,ascoreMAF1,if(KIF2seq==1,ascoreMAF2,if(KIF3seq==1,ascoreMAF3,0)))}
usw.

Mal sehen.
Ich darf @holch ja nicht enttäuschen.

Joffm
 

Vielen Dank an euch beiden für die super zügigen Antworten!  
Meine ideale Lösung würde sowohl das Einzelergebnis der Runde, als auch ein kumuliertes Ergebnis darstellen. Aber beide Optionen wären auch einzeln eine ordentliche Lösung. Ich werde morgen erstmal die kumulierte Lösung umsetzen und mich dann näher mit der ".gseq"-Property und dem Vorschlag dazu beschäftigen.

Ich darf @holch ja nicht enttäuschen.

Ich wurde nicht enttäuscht!

gseq war es also. Da hätte ich erst etwas recherchieren müssen, ich nutze LS nicht soo regelmässig.

Aber genau an sowas hatte ich gedacht, dass man abfragt welche Frage an welcher Position ist und dann eben nur die Fragen analysiert, die direkt vor der Teilergebnisseite stehen. An kumuliert hatte ich gar nicht gedacht, für mich hat es sich so gelesen, als ginge es nur um die Analyse der vorhergehenden Fragengruppe.

Bei zwei Fragen würde ich vermutlich auch keinen grossen Aufwand machen und die Umfrage "Frage für Frage" anzeigen und dann die Fragengruppen entsprechend nutzen können, aber man weiss ja nichts über die Fragen davor und danach (hatte keine Zeit mir die LSS anzuschauen).

Darüberhinaus:
Die beiden Fragen sind ja immer identisch.
Also sollte man die Beschreibung des "Vertrages" mittels "micro-tayloring" aufgrund der Zufallszahl einbauen,
und dann auch die Score-Berechnung mittels IF.
Dann hat die Umfrage viel weniger Fragen. Auch die vielen Gleichungen in "Fairness" kann mn kürzen.
Donnerstag morgen muss ich mir etwas anderes ausdenken. Danach mache ich einmal etwas.

Bis dann
Joffm 

Hallo, Laura,
hier also mein Beispiel.
1. Ich habe es nur in die erste Experimentalgruppe eingebaut (Rest is ja analog)
Daher ist die Zufallszahl auch fest auf "rand(1,1)" eingestellt.  Beachte dies!

2. Dein Endergebnis in "Debug" war ja bereits völlig klar.
Aber ich habe die "Gleichungs-Orgie" etwas gekürzt. Schau es Dir einfach an, wie ich die Matrix als Speicher benutze.

3. Noch zwei prinzipielle Dinge:
a. Vorsicht bei der Benutzung des "+" Operators. Dieser dient auch zur Verknüpfung von Texten wie "Adam" + " " + "Riese"  -> "Adam Riese".
Und so kann es passieren, dass aus 12+14 -> 1214 wird. Selten, aber kann.
Daher ist hier immer die Summenfunktion vorzuziehen. sum(12,14).
Habe ich unten in der Frage "eqScore" auch so gemacht.

b. Bitte, benutze NIE mehr diesen "Bedingungs-Designer". Heute arbeiten wir mit Relevanzgleichungen (hast Du ja auch gemacht bei der Auswahl der Exp.Gruppen).
Relevanzgleichungen sind flexibler, mächtiger, leichter zu handhaben.
Erstelle einmal eine Bedingung wie "(Q1=="Adam" ODER Q1=="Berta") UND (Q2>5 ODER (Q3 >3 UND Q3<6)) mit dem Bedingungs-Designer.
Außerdem lassen sich diese Bedingungen auch schlecht ändern - man muss sie zunächst entfernen und dann wieder erstellen.


Aber das nur nebenbei.

Ich habe in Version 3.x. die Änderungen vorgenommen, dann aber in eine Version 2.73.1. importiert und getestet.
Die angehängte lss ist also ein Export aus 2.73.
 

Ich sprach ja über micro-tayloring; ein Beispiel dazu kommt später.

Aber:
Sag Deinen Leuten einmal, sie mögen sich um ein Update kümmern.
Die Releases mit den Versionsnummern 2.64.0 bis 2.64.7 sind zwischen dem 7.3.2017 und dem 4.4.2017 herausgekommen.
Ich will jetzt nicht großartig über Sicherheitslücken und DSGVO reden.

Joffm

 

So, hier ein Beispiel, um zu zeigen, wie kurz es sein kann.
 

Ich habe jetzt vergessen es in 2.50/2.73 zu testen.
Aber es ist ja nichts Weltbewegendes darin.
Schau es einfach einmal an.

Joffm

Mir ist aber aufgefallen, dass in einigen Gleichungen kleine Tippfehler sind (kopiert und die letzte kleine Änderung vergessen); mal steht noch MAF in der MEF-Geschichte, und noch irgendwo anders.


 

Hallo Joffm, 

tausend Dank für deinen Einsatz! 

Ich konnte mich jetzt auch wieder dransetzen und habe mit deinem Input jetzt wirklich alles, was ich für die Umsetzung brauche. Danke dir  
Auch der Hinweis auf die Tippfehler ist super - das wären sehr ärgerliche Flüchtigkeitsfehler.

Oh und die LimeSurvey-Version wird Uni-weit bereitgestellt, da habe ich leider nicht so viel mitzureden.

Liebe Grüße
Laura

Oh und die LimeSurvey-Version wird Uni-weit bereitgestellt, da habe ich leider nicht so viel mitzureden.

Das ist klar, aber man kann ihnen ja manchmal einen Hinweis geben. Oft vergessen die das einfach für ein paar Jahre...