Please help us help you and fill where relevant:
Your LimeSurvey version: Version 3.27.19+210928
Own server or LimeSurvey hosting: Server meiner Uni
Survey theme/template: Fruity
==================
Hallöchen an alle, bin neu hier und hoffe jemand kann mir etwas helfen

Ich muss mich noch etwas in LimeSurvey einarbeiten und wollte fragen, wie genau man eine Art von Randomisierung bewerkstelligen könnte? 

Kurz: Meine Umfrage umfasst 100 Personen, welche gleichmäßig auf 5 Gruppen verteilt werden sollen.
Wäre es nun möglich eine Liste mit Zetteln zu erstellen, wo jeder Zettel randomisiert aber trotzdem gleichmäßig häufig gezogen wird, sodass eine ungefähre Gleichverteilung der Teilnehmer auf 5 Gruppen erfolgt?
Und wenn ja, wie? 

Vielen Dank schonmal im Voraus!  

Wie immer, willst du echten Zufall, dann ist eine absolute Gleichverteilung eher selten. Du kannst in einer Equation-Frage eine Zufallszahl generieren und basierend darauf deine Teilnehmer einer der 5 Gruppen zuweisen. Wie man das macht wurde hier im Forum schon tausend Mal beschrieben. Einfach mal suchen. Allerdings, wie gesagt, wie es der Zufall so will, nähert sich die Anzahl der Leute in den Gruppen erst bei grossen Zahlen aneinander an. Da musst du halt dann wenn es zum schluss kommt die Quoten manuell anpassen.

Zettel ziehen geht natürlich nicht, denn wir sind ja online.

Wenn du deine Teilnehmer kennst, dann könntest du Tokens / Zugangsschlüsse verweden und den Zufallschlüsseln schon eine Gruppe zuweisen (Custom Attribute in der Tokentabelle). Aber auch da hast du dann ein Problem: Nicht jeder der eingeladen wird, der beendet die Umfrage auch. Sprich auch da können die Gruppen unterschiedlich gefüllt sind.

Insgesamt rekrutiert man ja sowieso immer ein paar mehr Leute und kann das dann darüber später anpassen.

Das mit der versteckten Gleichungsfrage kann ich schon bei Limesurvey, das ist ja wirklich zum Glück easy. Aber wie du schon sagtest, ist ja die Schwierigkeit, dass eine ungefähre Gleichverteilung bei einer geringen Stichprobe rein zufallsbedingt, unrealistisch -für meine Analysen jedoch notwendig-ist.
Daher die Frage, wie man es einstellen kann.

Bei anderen Umfragetools ist es ja auch möglich, daher denke ich, dass es bei Lime wohl auch gehen sollte.
Bei einem anderen Umfragetool ist es z.B. so, dass es einen Zufallsgenerator gibt der aus einer festgelegten Liste von Elementen (Zetteln) wie eine Urne standardmäßig dafür sorgt, dass alle Zettel gleichmäßig gezogen werden. (Dropouts werden damit auch nicht berücksichtigt, aber das wäre schon in Ordnung).

Wie kann ich es so in Limesurvey einstellen?

Bei anderen Umfragetools ist es ja auch möglich, daher denke ich, dass es bei Lime wohl auch gehen sollte.

Nein, Limesurvey hat kein eingebautes "least filled bucket" System. Ich habe schon von Leuten gelesen, die so ein System in Limesurvey umgesetzt haben, ist aber vermutlich mit etwas Aufwand verbunden. Da du mit LS3 arbeitest kannst du auch nicht per expression manager auf die Statistik zugreifen, jedenfalls nicht ohne ein Plugin, und das wirst du in der Uni-Installation nicht installiert bekommen. Bleibt eben noch das händische eingreifen, wenn eine der Gruppen "voll ist", dann leitet man die Leute auf eine Gruppe die noch recht leer ist weiter. Das funktioniert eigentlich ganz gut, wenn die Umfrage recht langsam beantwortet wird.

Und nein, Limesurvey kann auch nicht "Zettel gleichmässig ziehen". Du könntest die Gruppenverteilung auf der SAVEDID basieren, sprich je nach der letzten Nummer der der SAVEDID verweist du die Leute einer Gruppe zu. Aber wenn du keine Zielgruppe hast, bei der wirklich fast alle die den Fragebogen aufrufen auch wirklich ausfüllen, dann hast du am Ende eigentlich genau das gleiche Problem wie bei der echten Zufallsauswahl. Die Gruppen werden vermutlich ziemlich ungleichmässig gefüllt werden, weil du Neugierige hast die einfach mal die Umfrage aufmachen und dann wieder weg sind oder Leute die mitten drin abbrechen. Aber das gleiche Problem hast du beim Zettel ziehen. Wäre interessant das mal zu testen, aber je nach Zielgruppe dürften die Resultate der reinen Zufallsauswahl und dem "Zettel"-Ansatz ziemlich gleich ausfallen, was die ungleichverteilung angeht. Wenn du davon ausgehen kannst, dass 80%+ die du einlädst / die Umfrage starten auch abschliessen, dann ist der Zettelansatz vermutlich im Vorteil. Alles drunter sehe ich keinen Vorteil.

Du hast aber nicht beantwortet, wie deine Teilnehmer eingeladen /rekrutiert werden. Je nach dem wie das passiert kann man sich eventuell eine Lösung via Tokens ausdenken, aber auch das ist nicht perfekt.

Aber genau dieses Thema wurde hier schon mehrmals diskutiert. Ich meine mich zu erinnern, dass Joffm darauf sogar in einem seiner Tutorials eingeht.

So, hier gefunden:

forums.limesurvey.org/forum/german-forum...nd-andere-f%C3%A4lle

Da hat Joffm einiges der Diskussionen im Forum zum Thema mal etwas strukturiert und zeigt mehrere Möglichkeiten auf und geht auch für beide Ansätze auf die Problematik ein. In der Praxis wird der Zettelansatz nicht viel besser abschneiden, wenn überhaupt, als der Zufalls-Ansatz. Denn der Zufall spielt ja weiter mit, eben beim Faktor wer zieht es durch und wer bricht ab.

Was besser ist, was funktioniert, etc. hängt einfach sehr von deinen Teilnehmern ab. Wenn du dir sicher bist, dass von deinen sagen wir 100 eingeladenen Teilnehmern 95 die Umfrage auch abschliessen, dann ist der Zettelansatz sicher besser als der reine Zufall. Aber wenn du eine offene Umfrage hast und jeder teilnehmen kann, dann wirst du meist eine sehr hohe Abbrecherquote haben, und zack ist der Zufall schon wieder richtig mit an Bord.

Hi Holch und kleines Lama,

sorry, dass ich mich hier mit einschalte, aber ich bin grade erstaunt und sehr begeistert darüber zu hören, dass man die "Zettel-Randomisierung" (die ja wirklich bei anderen Umfrageanbietern standardmäßig verfügbar ist), tatsächlich auch in Lime möglich sein soll. Habe gerade mal Joffm Tutorial dazu angesehen und muss zugeben, dass ich den "Urnenteil" noch nicht ganz verstehe (mein Verständnis für Programmierung und javascript sind leider sehr begrenzt..). Bevor ich mich damit näher beschäftigen werde, bzw. das angegebene javascript verstehen und erproben werde, daher nochmal nachgefragt: Es ist also wirklich möglich mit einer älteren Lime Version (einzige Voraussetzung javascript-Berechtigung) die Zettel Lösung zu implementieren, um eine ungefähre Gleichverteilung von Experimentalgruppen bei kleineren Stichproben, wie kleines Lama es beschrieben hat, zu erreichen ???

Lieber Gruß von (einer schwer begeisterten) Nala

@Nala Kein Problem, bin froh dich zu haben und dass du mir bei der Umfrage hilfst

@Holch Genau es ist wie du sagst, von den 100 Personen beenden wahrscheinlich um die 90 die Umfrage, das Urnenmodell wäre dann die beste Variante. Wenn ich das richtig verstehe, dann wäre das mit unserer Uni Version mit einem Javascript auch möglich?
(Schade dass es nicht eine Standardversion bei Lime ist.)

LG und nochmals vielen Dank für die Hilfe!

Als erstes: "least filled" ist nicht umständlich zu implementieren, wenn man davon absieht, dass für Version 3.x  das Plugin installiert werden muss, was wohl wieder an "Uni" scheitert

Sorry, aber jetzt bin ich sehr konfus.

Wieso redet jemand jetzt von einem "Urnenmodell"?
Dieses "Urnenbeispiel" im Tutorial dient doch einem anderen Zweck.
Oder was meinst Du?
Außerdem müsste die "Urne" außerhalb gespeichert sein; sonst ist sie ja bei jedem Teilnehmer wieder neu gefüllt.

Dann sollte mir jemand die "Zettel-Methode" erläutern. Das habe ich ja noch nie gehört.
Oder ist das ein neuer Begriff im Sinne von "Neuer Wein in alten Schläuchen"?
Und dass sie bei anderen standardmäßig verfügbar sein soll, halte ich für ein Gerücht.
Oder anders gefragt @KleinesLama, bei welchen?
Dies sind meist Ansätze, bei denen von idealen Versuchspersonen ausgegangen wird.
Oder man gibt einem Kind einen Namen, den es nicht verdient.

Mit keiner Methode bekommst Du eine Gleichverteilung hin.
Jeder, der dies behauptet, geht von sehr akademischen Bedingungen aus.

Du kannst ja einmal nachspielen mit den verschiedenen vorgestellten Methoden.
Nehmen wir einmal drei Gruppen an, auf die die Leute zu verteilen sind.
Personen A, B, C, D, Und E beginnen mehr oder weniger gleichzeitig mit der Umfrage.
D beendet nach der ersten Seite
F und G beginnen
B beendet seine Umfrage
H beginnt
F bricht die Umfrage ab.
A und C beenden ihre Umfrage
I und J beginnen
G und I beenden die Umfrage
K beginnt mit der Umfrage
E beendet seine Umfrage.
H unterbricht die Umfrage um am nächsten Tag fortzufahren.
L beginnt mit der Umfrage
J beendet die Umfrage.

So, jetzt bestimme einmal, wer in welcher Gruppe ist, und wie die einzelnen Gruppen besetzt sind.

So, und jetzt als Quintessenz:
Zufall bleibt Zufall, sonst würde er nicht so heißen.
Menschen sind auch nur Menschen; Du kannst von ihnen alles erwarten, nur kein erwünschtes Verhalten.

Ich finde diese ellenlangen Diskussionen hier auch  absolut überflüssig.
Mach eine Zufallszahl, lass die Umfrage laufen und beobachte die Verteilung.
Wenn eine Gruppe voll ist, passe die Gleichung zur Erzeugung der Zufallszahl an
Zum Beispiel: Drei Gruppen, also anfänglich
{if(is_empty(randnum),rand(1,3),randnum)}

Ist Gruppe 3 gefüllt und Du willst noch ein paar mehr in den anderen beiden, ändere sie zu
{if(is_empty(randnum),rand(1,2),randnum)}

Ist Gruppe 1 gefüllt und Du willst noch ein paar mehr in den anderen beiden, ändere sie zu
{if(is_empty(randnum),rand(2,3),randnum)}

Ist Gruppe 2 gefüllt und Du willst noch ein paar mehr in den anderen beiden, ändere sie zu (ein bisschen Arithmetik)
{if(is_empty(randnum),2*rand(1,2)-1,randnum)}
Durch die Multiplikation mit 2 erhältst Du entweder 2 oder 4, subtrahiere 1, -> 1 oder 3

Oder, wenn Deine Oma zur Verfügung steht:
Lass die Umfrage laufen, bis Du in jeder Gruppe die gewünschte Zahl erreicht hast.
Denn eine gewisse Overquota benötigst Du sowieso, um "Schwachsinn-Interviews" rauszuschmeißen. Es gibt immer irgendwelche Spaßvögel.
Den Rest der Overquota eliminiert Deine Oma. Sie bestimmt, wer noch gelöscht wird.
Mit der Oma meine ich eben eine Person, die nun wirklich gar nichts mit der Umfrage zu tun hat; sie kann dann einfach sagen, "der 4., 24. und 51. werden gelöscht"

Joffm

Jetzt noch ein Gedanke zum Schluss, der natürlich nur bei Installation auf einem eigenen Server durchführbar ist.
Ein meiner Ansicht nach wirklich gutes Modell wäre wohl nur mit zwei ajax-calls oder einen externen script und einer separaten Datenbank zu realisieren
Beim Start wird in einer Datenbank, in welcher meinetwegen
100 Datensätze mit "1"
100 Datensätze mit "2"
100 Datensätze mit "3"
​​​​​​​gespeichert sind, nachgeschaut, welche Gruppe noch die meisten Nummern enthält - also ein "least filled"-Verfahren.
In diese Gruppe wird der Teilnehmer gesteckt.
Dieser Datensatz wird nun gesperrt und die SAVEDID ebenfalls dort gespeichert.
Am Ende, wenn der Teilnehmer die Umfrage beendet, wird der Datensatz gelöscht, ansonsten wieder reaktiviert.
Wenn der Teilnehmer die Umfrage abbricht, wird er wieder reaktiviert, damit diese Nummer wieder zur Verfügung steht.
ABER: Wie erkennt man, dass der Teilnehmer beendet hat bzw. einfach den Browser geschlossen hat.
Zum Erkennen des Beendens könnte man (umständlich) per end-url auf ein kleines Progrämmchen verlinken, welches dies bewerkstelligt.
Da die SAVEDID gespeichert ist, kann es nachsehen, ob die Umfrage beendet wurde und an dieser Stelle die Nummer löschen.

Einfacher, man erstellt einen zweiten ajax-call auf der letzten Seite des Fragebogens. Wenn der Teilnehmer dort den Browser schließt, kann man ihn ja trotzdem als "complete" ansehen
Beim Abbruch ist es schwieriger. Hier müsste man wohl das "Unterbrechen und später fortfahren" verbieten, und jedesmal um Mitternacht ein kleines Programm laufen lassen, welches gesperrte Nummern wieder reaktiviert.

Dies ist noch etwas ins Rohe gedacht, würde aber klappen. Ist aber genau so wie alles andere "mit Kanonen auf Spatzen geschossen"



 

@Holch Genau es ist wie du sagst, von den 100 Personen beenden wahrscheinlich um die 90 die Umfrage,

Und wir wissen immer noch nicht wie diese Teilnehmer eingeladen / kontaktiert werden. Da du aber relativ genau weisst, wieviele eingeladen werden und wie hoch die Teilnahmerate ist, vermute ich jetzt mal, du hast eine Liste und die können per Email und einem individuellen Link eingeladen werden.

In diesem Fall würde ich den "Zufall" einfach nach vorne verlagern und bereits beim erstellen der Teilnehmerliste die Leute zufällig auf die Gruppen verteilen. Ansonsten: Wie Joffm.

Hallo Holch und Joffm,

erstmal vielen lieben Dank für eure ausführlichen Antworten! Auch nochmal herzlichen Dank, dass ihr mir damals bei meiner Umfrage (die sehr gut gelaufen ist) so geholfen habt, ohne euch wäre es nichts geworden, ganz ehrlich!!
Ich glaube es ist manchmal schwierig einfach das auszudrücken, was eig. simpel umsetzbar wäre. Daher einfach mal der Text eines anderen Umfragetools, bei dem "Zettel ziehen (Urnenmodell) möglich ist, denn besser kann man wohl nicht erklären. Und vllt. habt ihr dann noch Tipps, wie es umsetzbar wäre, denn wie ihr schon sagt, wahrsch. ist es ganz leicht nur als Laie kommt man nicht so darauf... also hier, was gemeint ist:

"Der Zufallsgenerator ist ein funktionaler Baustein für den Fragebogen. Das Element zieht aus einer vorgegebenen Liste von Elementen (Zettel) eines und speichert dessen Wert in eine Variable. Der gezogene Wert kann mittels value() ausgelesen und in einem Filter verwendet werden, um Inhalte des Fragebogens zufällig zu variieren. So lassen sich Teilnehmer etwa zufällig zu Experimentalgruppen zuordnen (Randomisierung).

Der Zufallsgenerator sorgt standardmäßig dafür, dass alle Zettel gleich häufig gezogen werden (Option Art der Ziehung). Das ist vor allem dann wichtig, wenn die Experimentalgruppen gleich groß sein sollen. Bei einer uneingeschränkten Zufallsauswahl hingegen kann es (gerade bei überschaubaren Stichproben) passieren, dass die Gruppengrößen massiv abweichen." --> das ist also gewünscht
"Je nach Weiterverwendung der Werte des Zufallsgenerators muss dieser passend im Fragebogen platziert werden. Dazu muss die Frage beim Fragebogen zusammenstellen auf eine Seite gezogen werden. In jedem Fall muss der Wert vor einem PHP-Code platziert werden, bei dem der Wert ausgelesen werden soll. Wenn der Wert des Zufallsgenerators einmal gezogen wurde, kann dieser Wert im Fragebogen jederzeit wieder ausgelesen werden." Dropouts werden natürlich dabei nicht berücksichtigt, wie kleines Lama schon meinte, aber das wäre ok.. (hier sonst auch nochmal der Link wo ich die Sachen jetzt rauskopiert habe: www.soscisurvey.de/help/doku.php/de:create:questions:random

Das Problem am "feintuning" also die Gruppen anpassen (nicht 1 bis 4, sondern z.B. 1-60 ) (was leider bei meiner Umfrage auch kritisiert wurde letzlich) ist letztlich folgendes:

"Warnung: Das Nachjustieren der Zufallsauswahl sollte nur dann erfolgen, wenn die Teilnehmer kontinuierlich und aus derselben Grundgesamtheit rekrutiert werden. Sonst besteht die Gefahr einer Konfundierung: Man stelle sich ein Experiment mit 4 Gruppen vor, bei dem die Teilnehmer alle an einem bestimmten Tag eingeladen werden. Nachdem 2/3 der Teilnehmer den Fragebogen ausgefüllt haben, bemerkt man, dass in Gruppe 1 überdurchschnittlich viele Fälle bereinigt werden müssen. Also werden ab sofort mehr Teilnehmer der Gruppe 1 zugeteilt. Nun liegt eine Konfundierung vor, denn Teilnehmer, die auf eine Einladung später reagieren, können sich signifikant von Teilnehmern unterscheiden, die schnell reagieren. Also würden sich die Teilnehmer in Gruppe 1 nun a-priori von Teilnehmern in anderen Gruppen unterscheiden – und damit wären Unterschiede in den abhängigen Variablen nicht mehr alleine auf den experimentellen Stimulus zurückzuführen."

Viele liebe Grüße von Nala

naja, die Probleme beim Nachjustieren sind schon sehr, sehr an den Haaren herbeigezogen. Aber gut, möglich ist alles. Im Normalfall spielt das aber alles keine echte Rolle.

Für mich hört sich dieses Zettel-Verfahren nach einem 'least filled bucket' Verfahren an, denn sonst hast du ja das Problem mit dem Zufall wieder mit drin, bei denen die vorzeitig abbrechen.

Und die Anpassung der quote würde ich natürlich nicht erst am Ende machen, sondern immer zwischendrin mal wieder eingreifen, wenn es wirklich mal irgendwo sehr voll/leer ist im Vergleich zu den anderen.

Für ein solches 'least filled bucket' Verfahren bräuchte man aber entweder einen Ajax-call (könnt ihr bei der Universion gaaaaaaaaaaaaaaaaaanz sicher nicht mache) oder eben das entsprechende Plugin um auf die Daten aus der Datenbank zugreifen zu können (Statistiken per Experession Skript auslesen). Das werdet ihr auch nicht installieren können. In LS5 sind diese Funktionen schon drin.

Mal sehen, ob Joffm was gutes dazu einfällt. Aber ich glaube der ist da mit mir auf einer Wellenlänge. Dieses Zettelverfahren macht vermutlich im Prinzip auch nichts anderes als die Zufallszahl während des Feldes anzupassen. Wenn du jetzt alle Teilnehmer gleichzeitig einlädst (was man ja eigentlich nicht machen sollte - darauf geht dein Text gar nicht ein), und du erwartest, dass sich alle wie die Verrückten darum schlagen deine Umfrage auszufüllen, dann wird es mit der manuellen Anpassung natürlich schwer. Das ist aber doch meist im akademischen Umfeld nicht der Fall.

Noch was zu der Kritik bzw. die Warnung:
- Wenn alle Teilnehmer an einem bestimmten Tag eingeladen werden - da fängt es doch schon an. Schon alleine damit hast du doch schon einen Bias in der Stichprobe. Was ist mit den Leuten die an diesem Tag nicht können? Vielleicht würden die ja ganz anders antworten als die die können? Du hast auf einaml nur Montagsleute in der Stichprobe. Zwar schön über die Gruppen verteilt, aber der Bias ist dann halt auch schön über die Gruppen verteilt. Also auch Mist.
- Wenn du die Einladungen alle morgens verschickst. Zack, ist die Stichprobe voll mit Leuten, die morgens Zeit und Lust haben Umfragen zu beantworten. Ich z.B. würde sowas eher erst am Abend anschauen.

Ich finde da wird ein Problem angesprochen, das durchaus gegeben sein kann, dafür werden aber tausende von anderen Variablen gar nicht beachtet, die mindestens genauso die Stichprobe versauen könnten.

Alleine von wo deine Teilnehmer kommen kann dafür Sorgen, dass die ganzen Daten Müll sind, über alle Gruppen hinweg. Da würde ich mir wesentlich mehr Sorgen darum machen, als über ein Nachjustieren der Zufallsauswahl. Denn es ist ja meist wirklich nur ein "nachjustieren". Die Gruppen sollten ja schon irgendwie ein halbwegs vernünftig verteilt werden, durch die Zufallsauswahl.

Ich würde halt erstmal einen Softlaunch machen, mit n=20 z.B.. Dann schaust du dir die Verteilung an. Wenn eine Gruppe wirklich sehr viele oder sehr wenige Leute drin hat, dann passt du an. Wenn es im Rahmen liegt schickst du die nächsten 20 in den Fragebogen usw. Damit ist die Nachjustierung nicht am Ende und es besteht auch nciht die Gefahr, dass alle gleichzeitig beantworten und du hast keine Zeit zum nachjustieren.

Ideal wäre ein bucket system, aber ich denke das wird mit eurer Uniinstallation einfach nicht funktionieren.

Hallo, Nala,
danke für den Artikel.
Als ich "php" und "Fragebogen zusammenstellen" las, war mir schon klar, dass es sich um SoSciSurvey handelt.

Aber wie ich schon schrieb: Es ist nichts anderes als das hier bereits Beschriebene. 

Art der Ziehung
Machen Sie sich vorab Gedanken, welche Ziehung Sie benötigen. Standardmäßig ist eine Gleichverteilung vorgesehen. Dies ist für die meisten Fälle sinnvoll.

• Die gleichverteilte Ziehung kann bei einer hohen Abbrecherquote zu ungleichen Gruppen im bereinigten Datensatz führen. Es ist daher sinnvoll, den Zufallsgenerator weiter hinten im Fragebogen zu platzieren, z.B. dort, wo der Stimulus präsentiert wird. Zur Korrektur siehe  Ziehung nachjustieren .

Dies ist ja die simple Benutzung der SAVEDID. Die ist absolut sicher, WENN alle den Fragebogen beenden. Brechen viele Leute ab, KANN es - wie auch das Brot immer auf die Marmeladenseite fällt - zu schiefen Ergebnissen kommen, tut es aber meistens nicht.

Und

• Wichtig: Wählen Sie die Option „Gleichverteilung in abgeschlossenen Fragebögen“ nur dann, wenn die Erhebung sich über einen längeren Erhebungszeitraum erstreckt und der Fragebogen in kurzer Zeit abgeschlossen werden kann (FINISHED=1). Wenn viele Teilnehmer und Teilnehmerinnen in kurzer Zeit (gemessen an der Zeit zwischen Zufallsziehung und Abschluss eines Interviews) teilnehmen, kann dies sonst zu Ungleichverteilungen führen. Wählen Sie dann lieber die normale gleichverteilte Ziehung.

Und dies ist der Ansatz - nur "completes" einzubeziehen. Hier wurde ja auch schon darauf hingewiesen, dass erst nach dem "Absenden" hochgezählt wird.
Daher ist hier wichtig, dass man nicht alle Leute auf einmal einlädt, sondern nach und nach in batches

Und das oben erwähnte "Nachjustieren" ist ja auch nichts anderes als ein "least filled" Ansatz. (Und ich muss auch noch die Häufigkeitstabelle selbst anlegen)

Einfach gesagt: Alle 6 in SoSci angebotenen "Arten der Ziehung" sind in LS ebenso darstellbar.
Das erstgenannte Procedere ist ja mit einer einzigen Formel erschlagen (siehe noch einmal mein Tutorial),
für die beiden anderen benötigt man entweder Version 5.x. oder eine Version 3.x. inklusive der Rechte Plugins zu installieren. (Bedeutet also wohl, man muss irgendwo Webspace anmieten)
In der Version 5.x. ist alles Benötigte enthalten.

Der große Nachteil von LimeSurvey ist dummerweise, dass man es herunterladen und auf dem eigenen Server installieren kann.
Daher ist so oft bei vielen Universitäten noch "eine alte Krücke" im Einsatz, die nie ein Update erfahren hat, und daher einige Features (noch) nicht beinhaltet.
(Und zusätzlich noch ein übereifriger Admin die restlichen Sachen verbietet)
SoSci liegt grundsätzlich auf deren Server und ist daher immer uptodate

Dann bietet SoSci auch "eingebaut" bereits viele Fragetypen, die man in LimeSurvey nachbauen kann/muss (z.B. Lückentexte offen und geschlossen, Zoom, IAT, Graphische Positionierung, Cardsort), die meist in meinem Tutorial "Gimmicks" enthalten sind.

Aber es spricht ja nichts dagegen, SoSci zu benutzen (es ist ja ebenfalls kostenlos).
Persönlich bin ich nicht so auf "Du und Du" mit dem Programm; liegt einfach an der seltenen Nutzung. Daher ist die Oberfläche ungewohnt.
Und das Forum scheint nur ein Dialog zu sein zwischen dem Fragesteller und jemandem bei SoSci.  Anscheinend fühlen sich andere User nicht besonders animiert etwas beizutragen.

Aber, wie ich schon öfters sagte:
Es ist alles mehr oder weniger ein "Streit um Kaisers Bart" oder mehr mit Shakespeare "Viel Lärm um Nichts".

Gerade bei kleinen Gesamtstichproben kann man es doch laufen lassen, bis alle Gruppen voll bzw. übervoll sind.
Dann kommt die Qualitätskontrolle, und zu guter Letzt schmeißt die Oma die dann noch Überzähligen hinaus.

So, damit ist jetzt von meiner Seite Schluss zu diesem Thema.

Joffm


 

Und noch ein Punkt: ich will euch da nichts unterstellen, ich kenne eure Fragebögen ja nicht, aber aber bei vielen Fragebögen die ich in letzter Zeit so von Bachelor, Master und Co so gesehen habe ist das Sampling sowieso völlig egal. Da kannst du das beste Sample der Welt haben, bei den Fragebögen können oft gar keine vernünftigen Daten dabei rauskommen. Da fragt man sich schon manchmal, wie das bei den Professoren und Assistenten durchgegangen ist. Wenn sich da genauso viele Gedanken bei der Erstellung des Fragebogens gemacht würden wie für das Sampling (was natürlich wichtig ist, versteht mich nicht falsch!), dann wären viele Daten wesentlich besser. 

Natürlich sollte man sich über solche Sachen wie die Zufallsverteilung Gedanken machen, aber da gibt es andere Faktoren die meiner Meinung nach ein viel, viel grösseres Gewicht für eine erfolgreiche Umfrage und eine gute Datenbasis haben. Die Gefahr eines Biases wegen Nachjustieren ist für mich eher theoretischer ("akademischer") Natur und kommt wohl eher nur in seltenen Fällen vor, zumindest wenn man bei der Stichprobe halbwegs aufpasst. Aber manche Fragebögen sorgen eigentlich garantiert für schlechte Daten (zu lang, zu langweilig, zu kompliziert, falsche Frageformulierung, schlechte Formatierung, falsche Fragenauswahl, etc.).

Aber gut, das ist ein anderes Thema.

Ach @holch, da haben wir wieder gleichzeitig geschrieben.

Und natürlich sind wir auf einer Wellenlänge.
Wir kommen ja aus demselben Stall, sprich "langjährige und langerfahrene Markt- und Meinungsforscher".

Joffm


 

holch wrote:

Für ein solches 'least filled bucket' Verfahren bräuchte man aber entweder einen Ajax-call (könnt ihr bei der Universion gaaaaaaaaaaaaaaaaaanz sicher nicht mache) oder eben das entsprechende Plugin um auf die Daten aus der Datenbank zugreifen zu können (Statistiken per Experession Skript auslesen). Das werdet ihr auch nicht installieren können. 

Ich greife das Thema hier noch einmal auf, weil es inzwischen bessere Lösungen für einen Least-Fill-Ansatz in LimeSurvey gibt.
Es ist korrekt, dass bei vielen Universitäten oder auch in der Cloud-Version keine Plugins installiert werden können. Das ist eine unschöne Einschränkung, die bei unserem professionellen LimeSurvey-Hosting nicht gegeben ist. Da aber trotzdem viele von diesen Restriktionen betroffen sind, möchte ich einmal auf einen Ansatz verweisen, der statt eines Plugins angepasste Least-Fill-Fragethemes nutzt.
Darüber ist es möglich, innerhalb der Umfrage abzufragen, welche Optionen bisher die wenigsten Zuweisungen haben. Basierend auf diesen Daten kann dann später eine Anzeige der Folgefragen entsprechend gesteuert werden. Ihr könnt euch das unter dieser einfachen Demo-Umfrage einmal anschauen: ls600demo.survey-consulting.com/index.ph...55?newtest=Y&lang=en
Es gibt auch eine erweiterte Version, für welche wir ebenfalls eine Demo-Umfrage erstellt haben: ls600demo.survey-consulting.com/index.ph...49?newtest=Y&lang=en

Bei Fragen zum Setup oder Bereitstellung der Fragethemes bitte einfach melden .