Ihre LimeSurvey-Version: 5.2.7 Community Edition
Genutzte Designvorlage: fruity, weitgehend vanilla
==================
Hallo zusammen,

folgende Gruppen-Relevanzgleichung funktioniert bei mir nicht wie vorgesehen:
(Tb01InfoEinwilligung == "n") or (Tb111DemoAlter < 16) or (Tb111DemoAlter > 80) or ((Tb21Inhalt_TN01 != 2) && (Tb23UsabDesig_TN02 != 5)) or (Tb302Selbstausschl == "n")

Erwartetes Verhalten: Zeige die Gruppe an, wenn...
- keine Einwilligung gegeben wird oder
- das Alter <16 bzw. >80 ist oder
- beide Aufmersamkeitscheck-Items falsch beantwortet wurden oder
- das Selbstausschlussitem mit "n" beantwortet wurde.

Tatsächliches Verhalten: Offenbar nur das Selbstausschluss-Item wird berücksichtigt.

Zu den Items (alles Pflichtitems, die natürlich vor der Gruppe mit der Relevanzgleichung vorkommen):

• Tb01InfoEinwilligung: radio list mit A[0]-1 = j und A[0]-2 = n.
  Dynamisches Ein-/Ausblenden einer Frage mit Tb01InfoEinwilligung == "n" funktioniert wie erwartet.
• Tb111DemoAlter: Numerical input, ganze Zahl.
• Tb21Inhalt_TN01 und Tb23UsabDesig_TN02: Teile von Matrixfragen; Aufmerksamkeitschecks, bei denen z.B. A[0]-2 = 2 = "stimme nicht zu" angeklickt werden soll.
• Tb302Selbstausschl: radio list mit A[0]-1 = j und A[0]-2 = n. Selbstausschluss-Item, bei dem j sinngemäß = "Ja, ich hab alles sinnvoll beantwortet."

Was mache ich falsch?

Du dürftest die Chance für Antworten erhöhen, wenn Du eine Demoumfrage mit den Fragen als LSS-Export hier dranhängst. Ohne LSS-Datei gibt es sehr oft lange Diskussionen und am Ende stellt sich dann schon mal raus, dass ein Tippfehler war oder in einer Gleichung HTML-Code durch Copy&Paste die Berechnung verhindert.

Ich würde mal lt,le,eq,ne,gt,ge anstatt <,<=,==,!=,>,>=, verwenden.

Was bedeutet z.B. "beide Aufmersamkeitscheck-Items falsch beantwortet wurden"
Zustimmung oder Ablehnung?

In der Gleichung steht "ungleich 2"
Tb21Inhalt_TN01 != 2
Also wird die Gruppe nur angezeigt, wenn zugestimmt wird.

Tb23UsabDesig_TN02 != 5
5??

Vielleicht erkennt jemand per Anstarren einen Fehler. Ich ziehe LSS-Exports vor.

Ich vermute ja dass das hier auch irgendwie Probleme bereitet:
((Tb21Inhalt_TN01 != 2) && (Tb23UsabDesig_TN02 != 5))

Wie Jelo, eine LSS nur mit den Relevanten Fragen für diese Problemstellung wäre gut, dann kann man auch mal damit "spielen".

Ich würde vermutlich eine Equation Frage verwenden um die Formel zu erstellen und zu testen und dann nur den Output der Equation für die Relevanzgleichung verwenden.

Aber ohne LSS ist das alles recht schwer zu beantworten.

Danke für eure Antworten schon mal.
Da habe ich mich an einer Stelle unglücklich ausgedrückt. Tb21Inhalt und Tb23UsabDesig sind Matrixfragen mit likert-skalierten Zustimmungsitems à la: 1 = stimme gar nicht zu .. 7 = vollkommen zu. Das sind recht viele "echte" Bewertungsfragen und dazwischen eingestreut zwei Items mit der Aufforderung, das jeweilige Kreuz an einer bestimmten Stelle zu machen, um Leute zu identifizieren, die sich von den Zeiten und vom Antwortmuster halbwegs realistisch durchklicken, aber trotzdem nicht lesen, was sie da 'beantworten'. Wenn beide Items nicht richtig angeklickt werden, gibt es einen Screenout.

jelo: Welche Vorteile haben lt, le usw. hier? Die Lesbarkeit leidet ja. Ich könnte mir noch komische Zeichensatz-Fehler vorstellen, habe die in LimeSurvey aber noch nie erlebt.

Ich schaue mal, ob ich heute Nachmittag dazu komme, einen lss-"Extrakt" zu machen, jetzt muss ich erstmal zu meiner anderen Arbeit.

lst jetzt anbei.


Ohne TN-Tabelle funktioniert natürlich auch die Auswahl der anzuzeigenden Website nicht (im ersten Teilnehmenden-Attribut hinterlege ich manuell eine Zahl von 1-30), aber das soll hier egal sein.

Auffällig finde ich, dass lange Relevanzgleichungen z.B. in der Gruppenübersicht für Gr 2.4 abgeschnitten dargestellt wird, beim Bearbeiten der Gruppe und in den Übersichten der darin enthaltenen Fragen (und im Codebuch) aber vollständig angezeigt wird:
 
 

Hallo,
zu Deinen Bildchen:
Wie @Jelo schon schrieb "Versuche"le, lt,..."
Der Editor hat nämlich manchmal die Idee die spitze Klammer eines "<" Zeichens sei der Anfang eines HTML-tags.
Mit "le" wird auch die gesamte Gleichung gezeigt.


Und was soll die Bedingungsgleichung in der Gruppenbeschreibung von "Screenout". Sie gehört doch wohl in die "Bedingung".
Daher ist es kein Wunder, dass sie immer angezeigt wird. die Bedingung steht schließlich einfach auf "1".

So, und jetzt noch zur anderen Frage der Redirects.
Es ist ja ziemlich unklug, sowohl die Screenouts wie auch die completes beide die Umfrage normal beenden zu lassen.
Für die Screenouts solltest Du lieber eine Quote setzen, oder mehrere.
Dann setzt Du den "Rausschmeiß-Text" in die Quotenmeldung und hast auch keine Probleme den richtigen Redirect zu senden.

Und mit Quoten ersparst Du Dir auch das Mitschleppen von solchen Bedingungen in jeder Gruppe wie "Tb01InfoEinwilligung == "j" && Tb111DemoAlter >= 16 && Tb111DemoAlter <= 80"
Die dies nicht erfüllen, sind dann nämlich schon längst raus.

Und als Letztes - nur als Anregung:
Gibt es einen Grund dafür, dass in Gruppen 2.1. - 2.4. die Frage in eine einzelne Textanzeige ausgelagert ist, die Frage selbst aber keinen Text hat?
Selbst wenn dies nur ein Prototyp ist, kannst Du doch im Fragetext selbst "unendlich viel" zaubern, mit tayloring und HTML.

Und ebenso: Gibt es einen Grund, nicht die eingebaute Möglichkeit der Zustimmung zur Teilnahme zu nutzen?
Dort hast Du doch dieselben Möglichkeiten?Und eine Quote gespart.

Zu den Fragencode-Ungetümen sage ich aber nichts

Joffm

P.S. Gerade gesehen, dass @holch die Quoten ja schon erwähnt hat.
 

Joffm wrote:

Hallo,
Der Editor hat nämlich manchmal die Idee die spitze Klammer eines "<" Zeichens sei der Anfang eines HTML-tags.
Mit "le" wird auch die gesamte Gleichung gezeigt.

Und was soll die Bedingungsgleichung in der Gruppenbeschreibung von "Screenout". Sie gehört doch wohl in die "Bedingung".
Daher ist es kein Wunder, dass sie immer angezeigt wird. die Bedingung steht schließlich einfach auf "1".



 

Danke für die Erklärung zum ersten Tipp, das probiere ich am Freitag aus (und: oh weia, was für ein Bug, falls es tatsächlich daran liegen sollte).
Bedingungsgleichung in der Gruppenbeschreibung: Ups, das ist ein Überbleibsel vom externen Testen. Die Frage sollte dort immer angezeigt werden, damit der Partner sie sieht. Ursprünglich war sie natürlich in der Bedingung, hat aber gerade da nicht funktioniert. Freitag dann auch noch Erklärung zum Rest.

Woran es letztendlich lag, kann ich nicht sagen. Jedenfalls habe ich für die Aufmerksamchecks eine Gleichung mit Ketten-ifs* gemacht um drei Fälle abzudecken (beide richtig -> 2 Punkte, sonst prüfen ob eins richtig -> 1 Punkt, sonst -> 3 Punkte == screenout) und den Rest über Quoten geregelt. Das funktioniert. Also danke euch!


Wer es genauer wissen will (warum auch immer):
Um das Alter (das als genaue Zahl erfasst wird) für die Quoten in Kategorien umzuformatieren, gab es eine noch hässlichere if-Schachtel**. Bei 7 Altersgruppen, 3 Geschlechtern und 4 formalen Bildungsstand-Gruppen waren das sehr, sehr viele Klicks im Quotenmenü. Und ich dachte, E*hust*F*hust*S Survey wäre manchmal umständlich.

*{if((TB21Inhalt_TN01.NAOK == 2 and Tb23UsabDesig_TN02.NAOK == 5), "2", if((TB21Inhalt_TN01.NAOK == 2 or Tb23UsabDesig_TN02.NAOK == 5), "1", "3"))}
**{if(Tb111DemoAlter.NAOK lt 16, "1", if(Tb111DemoAlter.NAOK le 20, "2", if(Tb111DemoAlter.NAOK le 24, "3", if(Tb111DemoAlter.NAOK le 39, "4", if(Tb111DemoAlter.NAOK le 59, "5", if(Tb111DemoAlter.NAOK le 80, "6", "7" ))))))}

Ich sollte mir eine Hilfskraft für so etwas zulegen, die versteht LimeSurvey vielleicht auch schneller als ich verrosteter Mann.. Und wenn ihr Vorschläge habt, wie man die if-Schachteln durch etwas Schöneres ersetzt, ändere ich das gerne beim nächsten Mal

Joffm wrote:

(...)
Und als Letztes - nur als Anregung:
Gibt es einen Grund dafür, dass in Gruppen 2.1. - 2.4. die Frage in eine einzelne Textanzeige ausgelagert ist, die Frage selbst aber keinen Text hat?
Selbst wenn dies nur ein Prototyp ist, kannst Du doch im Fragetext selbst "unendlich viel" zaubern, mit tayloring und HTML.

Und ebenso: Gibt es einen Grund, nicht die eingebaute Möglichkeit der Zustimmung zur Teilnahme zu nutzen?
Dort hast Du doch dieselben Möglichkeiten?Und eine Quote gespart.

Zu den Fragencode-Ungetümen sage ich aber nichts
 

Der Vollständigkeit halber, in kurz: Ja, beides hat Gründe. Insbesondere (aber nicht nur) erstens die Individualisierung der Kurzform des Fragebogens im Alltag durch Leute, die noch nie mit LimeSurvey gearbeitet haben und zweitens ein einfacheres Einlesen des so individualisierten Standardfragebogens durch ein dafür vorgesehenes R / Shiny Dashboard.
Auch die Fragencode-Ungetüme haben durchaus ihren Sinn, sie erleichtern hier insbesondere die Auswertung, weil hier verschiedene schon validierte Items und Skalen zusammen mit neuen Items getestet werden. Die beteiligten Wissenschaftler können die Items über die Fragen-/Variablencodes ohne weiteres Nachdenken sehr leicht identifizieren und sogar größere Teile bestehender Auswertungsskripte für diese Umfrage übernehmen bzw. zusammenkopieren. Darum eine Bitte: nicht alles belächeln bis abfällig kommentieren, das du nicht nachvollziehen kannst. Selbst wenn du die meisten Dinge in LimeSurvey schlicht besser weißt: So hat deine viele Hilfe immer wieder einen unschönen Beigeschmack.

Hallo,
noch einige Anmerkungen.
Zum ersten:
Wenn nur der Wert "3" zum ScreenOut führt, warum berechnest Du die beiden anderen zusätzlich?
Die benötigst Du doch in der Umfrage dann nicht mehr, oder doch?
Außerdem:
Hier hättest Du mit Assessment-Werten rechnen können, d.h. Bewertungsmodue einschalten und der 2. Antwortoption in TBInhalt den Wert 1 , allen anderen den Wert 0.
Entsprechend der Option 5 in TBUsabDesign.
Dann verkürzt sich diese Gleichung zu {sum(TB21Inhalt_TN01.valueNAOK,Tb23UsabDesig_TN02.valueNAOK)} und Du bekommst die drei Werte.

Und beim Alter liegt es im Grunde nur an den m.E, sehr willkürlichen und ungünstigen Grenzen (15,20,24,39,59,80)
Mit (15,20,25,39,59,79) und einem bisschen Arithmetik wäre es etwas kürzer gewesen (nur noch zwei IFs)
{if(Alter lt 26,max(2,floor((Alter-1)/5))-1,if(Alter lt 40,4,floor((Alter+60)/20)))}
Hier ist die Verrenkung bei den ganz jungen eigentlich überflüssig, da die "unter 15J." schon per Quote raus sind, oder?

Wobei man natürlich für sich entscheiden muss, ob man lieber etwas "Gehirnschmalz" investiert, oder in einem Texteditor die Teile schnell siebenmal kopiert und schnell anpasst (oder in Excel mittels VERKETTEN erzeugt).
Hier ist das Kopieren und Anpassen sicher der schnellere Weg.
Soll heißen: Wenn Du keine Gesetzmäßigkeit hast, hast Du keine andere Chance. Das können andere, kommerzielle Tools auch nicht.

Und zu den Quoten:
Willst Du wirklich 84 Quoten machen, also alle Kombinationen?
Oder doch nur 14?
Wobei ich dann wieder frage, wie Du die Quote ansetzt bei den Teilnehmern, die sich für etwas anderes halten als "männlich" oder "weiblich".
Sind es denn inzwischen mehr als 1000 in Deutschland, die im Geburtsregister "divers" haben eintragen lassen? Die wirst Du wohl ohne Quote einfach mitlaufen lassen müssen.

Aber auch da kann ich Dich trösten: Die musst Du bei anderen auch einzeln anlegen; wobei ich zustimme, dass hier die GUI nicht besonders benutzerfreundlich ist.
Sie scheint mir - genau wie der "Bedingungs-Designer" - noch aus der Zeit zu stammen, als es noch kein Expression Manager/Script gab. Heutzutage könnte man ein Quote ja einfach damit definieren:
Quotenname, Limit,Bedingung für "Raus", Meldung , end-url, aktiviert sollte genügen

Aber im Moment gibt es ja wieder eine Diskussion über eine neue, bessere GUI. Beteilige Dich, steuere Deine Erfahrung, Deine Wünsche und Ideen bei, um LimeSurvey "voranzutreiben".

Dies alles nur am Rande.

Joffm

Alles sinnvolle Anmerkungen.

• Warum die anderen beiden zusätzlich berechnet? -> 1. Für mich zum einfacheren Testen der Formel und 2. um den halb-automatisierten, datengetriebenen Qualitätscheck nach dem Datenexport noch etwas einfacher zu machen. Mit dem Bewertungsmodus habe ich mich noch gar nicht beschäftigt - sollte ich vielleicht mal machen
• Altersgrenzen: Einteilung kommt nicht von mir. Gibt aber auch dafür Gründe (z.B. Altersgruppen, die der Panelanbieter einladen kann).
• Hirnschmalz vs. einfaches Copy-Paste: Ich bin noch so unerfahren mit ExpressionScript, dass mir meine Variante sicherer ist. Solange das die Laufzeit nicht massiv erhöht (und danach sieht es bisher nicht aus), bleib ich dabei.
• Anzahl der Quoten: 16 sind es
• m/w/d: Gute Frage, die wir uns auch gestellt haben. Die Wahrscheinlichkeit, dass es so wenige nicht-binäre Teilnehmende gibt (die dürfen das übrigens auch ankreuzen, wenn das nicht amtlich hinterlegt ist), dass wir damit in der Auswertung herzlich wenig anfangen können, ist relativ groß. Die mir bekannten seriösen Schätzungen, wie hoch der Anteil in der Allgemeinbevölkerung ist, liegen zwischen 0,1% und 2%. Bei N = 2500 Teilnehmenden also Erwartungswert zwischen 2 bis 3 und 50. Aber wer weiß, vielleicht sind sie in gewissen Onlinepanels aus irgendeinem Grund auch überrepräsentiert. Bei entsprechend starker Abweichung von den Bewertungen von Cis-Männern oder Cis-Frauen (die wir nicht erwarten) und gleichzeitig geringer Varianz zwischen den meisten der 30 verschiedenen Websites könnte es unter Umständen einen sinnvoll interpretierbaren und statistisch halbwegs abgesicherten Effekt geben. Wenn wir es nicht testen, werden wir es nicht erfahren, und ich weiß in Deutschland von keiner methodisch hochwertigen, UX-bezogenen Forschungsliteratur dazu. Langer Rede kurzer Sinn: Wir haben insgesamt recht viel statistischen Puffer bei der Stichprobengröße. Ich habe die Quote darum erstmal auf 60 gesetzt, und falls sich andeutet, dass die übererfüllt werden könnte, schaue ich zwischendurch in die Daten, ob es sich lohnt, sie zu vergrößern.
• Diskussion um bessere GUI: Puh, ja, das sollte ich als UX-Forscher machen. Noch dazu als großer Nutznießer dieser Community! Familie sowie Hauptjob und zwei Nebenjobs (die alle drei zu >95% am Rechner sind) sprechen dagegen. Wo muss ich hin? Hier bei github scheint es nicht zu sein.