Kapitel 25. Die Benutzeroberfläche

Abbildung 25.3. Starten des Robots

Das Startmenü bietet neben den regulären Möglichkeiten, ein Interview zu starten (test-, single-, multimode) auch die Option, einen Robot durch das Interview zu schicken. Dazu setzt der Server den dort installierten Browser Firefox ein, um ihn ohne sichtbare Rückmeldung von jedem Screen einen Screenshot machen zu lassen. Die Maske verlangt die Vorgabe einer URL, ab der der Robot einsetzen soll. Die Angabe eines Zeitraums zwischen den Aufnahmen ist optional. Mit den Skriptparametern ignoreFilter, ignoreAssert und ignoreNoMissing (s. „Skriptparameter“) lässt sich vom Skript aus beeinflussen, wie der Robot sich durch das Skript bewegt. Nach dem Durchgang bietet der Browser an, ein Zip-Archiv herunter zu laden, das die Screenshots als PNG-Dateien enthält.

Gedacht ist die Möglichkeit, den Roboter einzusetzen, zu Dokumentationszwecken um den vollständigen Fragebogen auszudrucken (dann sollten alle drei Skriptparameter mit »yes« eingeschaltet werden). Das sollte vor dem Start einer Studie geschehen, weil das Programm mit jedem Lauf ein eigenes Interview erzeugt. Außerdem kann der Robot verwendet werden, um ein konkretes Interview auszudrucken oder am Bildschirm nachzuvollziehen, wie es unter dem Menüpunkt [Data / Export] und dort unter [Native Data] möglich ist.

Man kann den Befragten auf diese Weise auch ermöglichen, den von ihnen ausgefüllten Fragebogen herunter zu laden. Die interne Variable _encryptedcaseid erlaubt es, die URL zu veröffentlichen, weil die Fallnummer nur verschlüsselt erscheint und so keine Rückschlüsse auf andere gültige URLs zulässt.

group grp_finished;
labels=
1 "Vielen Dank für Ihre Teilnahme. Ihren Fragebogen finden sie hier: http://server.de/SurveyServlet?action=printcase&survey=test&lfd=@insert(_encryptedcaseid)" (_finished eq 1)
2 "Vielen Dank für Ihr Interesse. Leider passen Sie nicht zu unserer Zielgruppe." (_finished eq 2)
3 "Vielen Dank für Ihr Interesse. Leider haben bereits ausreichend Personen mit Ihrem Profil an dieser Befragung teilgenommen." (_finished eq 3)
;
      

Der Link funktioniert auch ohne Anmeldung am Server und die Studie muss dazu nicht aktiv sein.

Zur Verfügung stehen nur aktive Studien. Studien, die über den [Survey Manager] der Web-Oberfläche angelegt wurden, sind automatisch aktiv, weil die Datei active.cfg beim Erstellen des Gerüsts für die Studie in das Fragebogenverzeichnis kopiert wurde. Die Datei dient Q. als Schalter: ist sie vorhanden, gilt die Studie als aktiv, ist sie nicht vorhanden, ist der Fragebogen nicht aktiv. Der Mechanismus erweist sich insbesondere dann als nützlich, wenn etwa die vorgegebene Zahl an Interviews erreicht ist und die Studie deaktiviert werden kann. Nachzügler sehen dann automatisch eine Nachricht, dass die Studie bereits geschlossen wurde (s. auch Konfigurationsdateien im Fragebogenverzeichnis).

Bei einem Klick auf Export wird die vollständige Studie (Fragebogen- und Medienverzeichnis) in einer Q.-Projektdatei archiviert und zum Download angeboten. Die Datei trägt zwar die Endung .qp, aber es handelt sich um ein Zip-Archiv.

Wenn in der Konfigurationsdatei qonline.cfg (s. „Konfigurationsdatei qonline.cfg“) der Parameter archivePath gesetzt ist (z.B. auf archive, dient das Verzeichnis archive in der Wurzel der Q.-Installation als Archiv. Wenn der Parameter nicht gesetzt ist, erscheint das Icon für [Archive] mit einem »Einfahrt verboten«-Schild und bleibt ohne Funktion.

Bei aktivierter Archiv-Funktion fasst Q. den Studien- und den Medienordner in einem Archiv zusammen, komprimiert die Datei und legt sie unter dem Namen der Studie mit der Endung .qp im Archiv-Verzeichnis ab. Vorsicht: Zugleich mit dem Verschieben ins Archiv löscht Q. die entsprechenden Verzeichnisse der Studie im surveys- und im media-Ordner.

Der Knopf [Reset] bereinigt das Studienverzeichnis und setzt die Studie auf den Ausgangspunkt zurück. D.h. Protokoll-Dateien werden entfernt, ID-Listen und Quoten zurückgesetzt, auch laufende Interviews werden gelöscht. In der Regel dürfte sich die Funktion als praktisch erweisen, wenn es darum geht, Testdaten zu beseitigen und die Studie für die eigentliche Befragung frei zu schalten. Wenn backupPath in qonline.cfg definiert ist (s. „Konfigurationsdatei qonline.cfg“.), legt Q. beim Reset eine Sicherungskopie im dort festgelegten Verzeichnis ab.

Im Lauf auch des Testbetriebs legt Q. Verwaltungsdaten im Fragebogenverzeichnis an. Dazu gehören die Dateien

Löscht die Studie (Fragebogen- und Medienverzeichnis), wenn die dazu erneut abgefragten Anmeldedaten korrekt eingegeben wurden.

Beim Skripten von Fragebögen gibt es verschiedene Möglichkeiten, sich bei der Fehlersuche zu behelfen. Neben der Ausgabe von Variablen in speziellen, zusätzlich eingefügten Debug-Fragen, leistet vor allem der Skriptcheck Hilfestellung. Q. prüft das Skript auf syntaktische Korrektheit und gibt entsprechende Fehlermeldungen aus bzw. warnt vor möglichen Fehlerquellen. Dazu gehören z.B. (sich überschreibende) Mehrfachzuweisungen von initActionBlock, resumeActionBlock, startActionBlock, etc. oder im Skript definierte Fragen, die gar nicht oder mehrfach im Befragungsablauf enthalten sind. Außerdem informiert der Skriptcheck über die Gesamtzahl der Screens und hilft damit beim Abgleich des Fortschrittsbalkens.

Änderungen am Skript können parallel vorgenommen und das Skript dann über den Knopf »erneut laden« wieder überprüft werden.

Fehler weist das Programm oben in der Seite im Bereich der Zusammenfassung als Link in dunkelrot aus. Der Link verweist auf die Fundstelle im darunter folgenden vollständigen Bericht. Eine konkrete Zeilenzahl zur Fundstelle des Fehlers kann Q. nicht liefern, denn bevor Q. das Skript abarbeitet, wird es aus den Einzelteilen, aus denen es bestehen kann, zusammengesetzt. Von daher muss man sich an dieser Stelle mit der ungefähren Fundstelle der Fehlerquelle, etwa den Hinweisen auf die Frage davor und danach, begnügen.

Warnungen gibt das Programm in chartreuse (einer Art hellgrün) aus. Dabei kann es sich um Hinweise auf Bezeichnungen handeln, die in der Blacklist auftauchen oder um Fragen, die zwar geskriptet sind, aber in keinem Block berücksichtigt werden. Das Programm warnt auch bei bestimmten Bedingungen, etwa Filter, die einen Array allgemein ansprechen und nicht einen konkreten Wert des Arrays. Ein Skript, das Warnungen verursacht, ist lauffähig. Allerdings kann es, gerade bei lax formulierten Filtern, Missverständnisse beinhalten, die zu Fehlern in der Befragung führen. Von daher ist eine seegrün unterlegte Bestätigung: Script check finished successfully! durchaus wünschenswert.

Über [ID settings] können die Bedingungen für die zu verwendenden IDs festgelegt werden.

Abbildung 25.5. Studie konfigurieren: IDs

Der Haken bei »Test mode enabled« legt fest, dass eine Studie auch im Testmodus aufgerufen werden kann. Der Haken bei »Accept unknown IDs« ermöglicht die Teilnahme, ohne dass die Befragten sich mit einer hinterlegten ID ausweisen müssen.

Der »URL Parameter« legt fest, mit welchem Variablennamen Teilnehmer-IDs in der URL bezeichnet werden (Voreinstellung: respid). Bei der Anbindung von Panels spielt das häufig eine Rolle, weil die Panels hier unterschiedliche Vorstellungen haben. Auch wenn der Parameter an dieser Stelle frei definierbar ist, wird innerhalb des Q. Skripts immer mit _respid auf die ID zugegriffen.

Über den Menüpunkt »Manage« können die einzelnen IDs eingesehen und weitere Aktionen vorgenommen werden.

Abbildung 25.6. IDs managen

Automatisch werden bis zu 10.000 IDs aufgelistet, außerdem kann gezielt nach IDs gesucht und die Ansicht mit Ein- bzw. Ausblenden der Häkchen auf Single IDs und Multi IDs sowie nach ihrem Status (»fresh« steht für noch nicht und »active« für gerade verwendete IDs, »cancelled« für abgebrochene und »finished« für beendete Interviews) gefiltert werden.

Die einzelnen IDs können in der Bildschirmansicht bzgl. ihres Status geändert oder gelöscht werden. Dies kann beispielsweise nötig werden, wenn IDs zu Testzwecken verwendet und ein ‚Reset‘ der Studie vergessen wurde – dann kann über diese Funktion auch nach Feldstart auf den Status der einzelnen IDs zugegriffen und auf »fresh« gesetzt werden. Auch Probleme mit ‚defekten‘ Links (beispielsweise falls Serverprobleme o.Ä. zu inkonsistenten ID Stati geführt haben) können so behoben werden.

Unter dem Menüpunkt »Add« können neue IDs per Zufallsprinzip generiert werden: Neben der gewünschten Anzahl muss für numerische IDs eine Spannweite definiert werden. Hierbei ist auf einen ausreichend großen Wertebereich im Verhältnis zur gewünschten ID-Anzahl zu achten, da die Software nach 100 zufällig generierten Duplikat-IDs den Vorgang beendet. Alphanumerische IDs werden nach Eingabe der gewünschten Anzahl automatisch 32-stellig aus Groß-, Kleinbuchstaben und Ziffern zwischen 0 und 9 erstellt. Außerdem können schon vorhandene ID-Listen hineinkopiert werden, Duplikate zu bereits bestehenden IDs werden erkannt und ausgelassen.

Mit »Delete« können vorhandene ID-Informationen (Single IDs, Multi IDs oder alle) passwortgeschützt und vollständig gelöscht werden. Dieser Vorgang (und generell alle Einstellungen in diesem Menü) berührt nur die ID-Informationen – Datensätze werden nicht verändert oder gelöscht!

Mit Klick auf die beiden Buttons »Single IDs« und »Multi IDs« werden die aktuellen ID-Informationen zum Download angeboten.

Zu den unterschiedlichen Befragungsmodi (Test, Single, Multi), der Struktur der Einladungslinks und Panelanbindung, siehe auch „Befragungsmodi“.

Welche Aspekte einer laufenden Umfrage im Reporting auftauchen sollen, ist konfigurierbar:

Abbildung 25.7. Studie konfigurieren: Reporting

Änderungen, die über die Web-Oberfläche vorgenommen werden, wirken sich in der Datei summary.cfg im Fragebogenverzeichnis aus, welche die fünf Variablen (overview, quota, stats, datamenu, tables) versammelt. Den Variablen wird jeweils yes oder no als Wert übergeben.

Wie die GESStabs Tabellen aussehen sollen, lässt sich über Anweisungsdateien bestimmen (*.tab-Dateien). Die Dateien können über den Upload-Mechanismus "GTC files" auf den Server kopiert werden. Das Verzeichnis gtc muss im Fragebogen-Verzeichnis vorhanden sein. Auf diese Weise können unterschiedlichen Nutzerkonten jeweils eigene Tabellen zugeordnet werden (»Login specific GTC tables«).

Abbildung 25.8. Studie konfigurieren: Quoten

Zum Quoten-Management auf der Administrationsebene gehören neben dem Editieren selbst auch das Hinzufügen und Löschen von Quotenvariablen. Die Variablen und Quotenstände müssen trotzdem innerhalb des Skripts deklariert und errechnet werden, Änderungen schlagen sich in der Datei quotavars.lst nieder.

Unter dem Punkt Filesystem gibt Q. Auskunft über die Dateien und ihre Codierung im Verzeichnis text. Früher, langjährige Nutzer werden sich erinnern, bildete das Nebeneinander von ASCII, DOS-Codepages und ISO-Kodierungen öfter ein Problem. Für Q. stellen unterschiedliche Kodierungen kein Problem dar, sie werden automatisch erkannt. Die Ausgabe von Q. erfolgt allerdings immer in UTF-8. Aus diesem Grund muss im Kopf des HTML-Templates zwingend die Zeile

<meta name="Content-Type" content="text/html; charset=utf-8"/>
	

erscheinen. Nur so ist gewährleistet, dass die Ausgabe im Browser mit unterschiedlichen Sprachen von Englisch bis Chinesisch kein Problem hat. Außerdem exportiert Q. auch die OPN-Dateien in UTF-8-Kodierung.

Alle Dateien der Liste bietet Q. zum Download an (zweite Spalte), .q-Dateien bietet die Oberfläche über den Schraubenschlüssel auch zum Editieren an, d.h. die Dateien werden direkt in dem Editor geöffnet, der als Standard für .q-Dateien festgelegt ist.

Abbildung 25.9. Studie konfigurieren: Zeichencodierung

Falls es wider Erwarten doch ein Problem mit den Kodierungen geben sollte, kann die automatische Erkennung von Q. mit dem Anlegen der Datei encoding.lst übergangen werden. Die Datei ordnet zeilenweise einer Datei eine Codierung zu in der Form

	    Dateiname Zeichensatz
	  

Nun gibt es zwar nicht so viele Zeichensätze wie Sand am Meer, aber die Tendenz geht dahin und nicht alle Zeichensätze werden zwangsläufig richtig behandelt. Die kurze Lösung wäre in dem Fall, generell auf UTF-8 auszuweichen.

Unter [User assignment] erscheint eine Liste aller dem System bekannten Nutzer. Die bereits mit einem Haken versehenen Konten haben schon Zugriff auf die aktuelle Studie. Weitere Nutzer können der Studie zugeordnet werden, indem die Checkbox am Anfang der Zeile mit einem Haken versehen und die Liste über den Knopf [Save] gespeichert wird.

Auf diese Weise lassen sich die Einträge in der Datei access.lst verwalten.

Die Zugriffsrechte der Nutzer auf die Studie werden duch die in der Nutzerverwaltung (unter »Main«, Menü-Punkt [Users]) dem Konto zugeordneten Rechte bestimmt (zum Thema Zugriffsrechte s. „Nutzerkonten und Zugriffsrechte: users.lst“).

Mit [Print] kann nun eine HTML Ausgabe für den geskripteten Fragebogen als PDF gespeichert oder gedruckt werden. Hier werden alle Asserts, Filter, Labelattribute dargestellt. [Print] ist ideal zum Überprüfen von z.B. Filterdefinitionen.

Eine Frage lässt sich als Datensatz verstehen, der verschiedene Felder beinhaltet: Text, Titel, Labels usw. Jedes dieser Felder hat einen eigenen Namen bestehend aus Fragename (z.B. f1) und Feldname (z.B, qqtext), so dass der Fragetext über das entsprechende Feld (f1_qqtext) erreichbar ist. Übersetzungen arbeiten tabellenbasiert: Dem Feldnamen in der ersten Spalte ist der Text in der zweiten Spalte zugeordnet. In welcher Sprache und mit welchem Alphabet der Text verfasst ist, ist dabei unerheblich und so kann für jedes Interview die gewünschte Sprache festgelegt werden, indem den Feldnamen die entsprechende Übersetzung zugeordnet wird.

Die Übersetzungstabelle mit einer Tabellenkalkulation zu erstellen, hat sich in der Vergangenheit zwar als machbar erwiesen, stellte aber auch eine Fehlerquelle dar: HTML-Formatierungen in den Texten gingen verloren, nicht alle Felder wurden übersetzt, weil viele mehrfach erscheinen usw. Daher bietet Q. einen eigenen Ansatz, Übersetzungen zu erstellen und zu verwalten. Das Grundprinzip bleibt dabei erhalten: Den Feldnamen wird in einer Tabelle eine Übersetzung zugeordnet. Aber Q. bringt darüber hinaus einige Besonderheiten mit, die das Übersetzen erleichtern.

Voraussetzung für das Sprachmanagement ist eine PostgreSQL-Datenbank. Auf welche Datenbank Q. wie zugreifen soll, legen Parameter in der Datei qonline.cfg fest (zu Einzelheiten s. „Konfigurationsdatei qonline.cfg“).

Abbildung 25.10. Sprachmanagement

Der Kasten »Native language« erscheint im Screenshot (Abbildung 25.10, „Sprachmanagement“) ausgefüllt, weil eine Übersetzung bereits angelegt wurde. Wenn keine Übersetzung existiert, enthält der Kasten nur ein warnendes Dreieck und den Schraubenschlüssel. Mit einem Klick auf den Schraubenschlüssel erhalten wir die Möglichkeit, eine Übersetzungstabelle anzulegen. Mit dem Klick auf [Rebuild & Save] erscheint eine Auswahl, mit der die im Skript verwendete Ausgangssprache festgelegt werden kann. Wenn die Auswahl getroffen ist, generiert Q. eine zweispaltige Übersicht: links die Feldnamen, rechts die Feldinhalte. Über den Download-Knopf kann die Tabelle heruntergeladen werden. Zurück in der Übersicht zum Sprachmanagement weist der Kasten »Native language« jetzt die Ausgangssprache aus und zeigt das Datum, an dem die Ausgangstabelle angelegt wurde.

Im Kasten daneben können wir über den Knopf [Add language] Tabellen für die Übersetzung hinzufügen. Der Klick öffnet erneut die Sprachauswahl, mit der wir das Kürzel für die Zielsprache dieser Tabelle festlegen können. Anschließend weist die Übersicht die Sprachkennung und die Sprache aus sowie das Datum, an dem die Tabelle zuletzt verändert wurde. Über den Schraubenschlüssel öffnet sich die Tabelle für die Übersetzung (s.u.). Über das Pfeilsymbol unter »Import« können vorhandene Übersetzungsdateien (.lrs) beim Anlegen einer neuen Übersetzung als Grundstock in die Datenbank importiert werden. Auf diese Weise lassen sich Sprachvarianten handhaben, wenn etwa eine vorhandene deutsche Übersetzung für die österreichische Variante importiert werden kann, bei der dann nur die Abweichungen korrigiert werden müssen.

Der Klick auf das Plus-Zeichen unter »Assigned Translators« erlaubt es, jeder Sprachtabelle einen oder mehrere Übersetzer zuzuordnen. Der Klick auf das Plus-Zeichen öffnet die Auswahl für die Übersetzer und weist die Nutzernamen aus, die mit der Rolle »Translator« in der User-Tabelle (s. „Users - Benutzerverwaltung“) eingetragen und über [User Assignment] (s. „User assignment - Nutzerkonten“) der Studie zugeordnet sind. Mit einem Klick in das weiße Feld öffnet sich die Liste der Übersetzer. Ein Klick auf den Namen ordnet die Auswahl als Übersetzer zu. Aus der Liste lassen sich die einzelnen Einträge über das »x« wieder entfernen,

Nach einem Klick auf das Diskettensymbol bietet Q. an, die Übersetzungstabelle mit dem Dateinamen [Sprachkennung].lrs (für Französisch z.B, »fr.lrs«) zu speichern. Das System hinterlegt die Tabelle im Skript-Verzeichnis, und dann kann sie im Skript über die Anweisung readTextRessource (s. „Actionbefehle“) eingelesen werden.

Bei einer Änderung der Übersetzung muss nur die Sprachtabelle erneut als als lrs-Datei erneut abgespeichert werden, damit sie beim nächsten Start eines Interviews eingelesen werden kann. Wenn dagegen der Fragebogen verändert wird, indem Fragen hinzukommen oder Fragenamen verändert werden, müssen wir die grundlegende Datenbanktabelle über den Schraubenschlüssel unter »Native language« durch einen Klick auf »Rebuild & Save« neu aufbauen. Ein Rebuild der Skriptsprache kann jederzeit vorgenommen werden. Neue Texte werden automatisch ergänzt, nicht mehr vorhandene entfernt (aber nicht aus der Datenbank gelöscht) und veränderte Texte werden orange gekennzeichnet. Ändert man also eine Frage von Single zu SingleGrid, dann bleiben Fragetext/-titel, Intervieweranweisungen etc erhalten solange der Fragename identisch bleibt. Ändert man auch den Namen der Frage, muss man sie komplett neu übersetzen. Ändert man im Skript alles zum Ursprung zurück, tauchen auch die alten Übersetzungsinformationen wieder auf (orange).

Das Übersetzungswerkzeug

Abbildung 25.11. Die Übersetzungstabelle

Die Abbildung 25.11, „Die Übersetzungstabelle“ zeigt eine Tabelle mit Englisch als Ausgangssprache im Skript (en) und der Übersetzung ins Russische (ru). Sortiert ist die Tabelle nach den Feldnamen; dadurch listet zeigt die Tabelle die Felder einer Frage in unmittelbarer Nachbarschaft. Q. hat in dem gezeigten Ausschnitt insgesamt 881 Felder identifiziert, die zu übersetzen sind. An 823 existierenden Übersetzungen hat das System nichts auszusetzen (links grün unterlegt). Bei acht Übersetzungen warnt Q. (gelb unterlegt), dass nach der Übersetzung der Quelltext noch einmal verändert wurde. Um die Warnung zu entfernen, muss die Übersetzung korrigiert oder bestätigt werden. Rot unterlegt das System die Anzahl der Übersetzungen, die einen möglichen Fehler enthalten, weil Elemente aus dem Quelltext (HTML-Formatierungen, Q.-Anweisungen) nicht oder fehlerhaft in die Übersetzung übernommen wurden. 50 Felder (weiß unterlegt) sind nicht übersetzt. Die Knöpfe mit der Anzahl der Felder funktionieren auch als Filter: ein Klick auf die gelb unterlegte acht zeigt in der Tabelle nur die acht noch zu überprüfenden Übersetzungen an. Ein Klick auf die 881 hebt die Einschränkung wieder auf und zeigt die erste Seite mit 250 Einträgen an.

Texte, die keinen zu übersetzenden Inhalt haben und nur aus Schlüsselwörtern wie @insert() oder HTML-Inhalten bestehen, werden automatisch gefiltert.

Mit einem Eintrag im Suchfeld und dem Klick auf die Lupe wird die Anzeige auf die Einträge eingeschränkt, die den Suchbegriff enthalten. Das gilt auch für die Feldnamen, so dass etwa die Suche nach »f1_« alle Felder ausweist, die diese Zeichenkette enthalten. Auch hier arbeiten die Knöpfe als Filter, und wir können die Anzeige mit einem Klick auf den gelben Knopf auf die Felder einschränken, deren Übersetzung sich noch geändert hat. Um die durch die Suche eingeschränkte Anzeige aufzuheben, muss das Suchfeld geleert werden. Der Suchbegriff QSYNTAX liefert alle Texte mit syntaktischen Besonderheiten (z.B. HTML, Q. Befehle) zurück.

Für die eigentliche Übersetzung müssen nur die leeren Felder in der rechten Spalte ausgefüllt werden. Dabei zeigen sich einige Besonderheiten: Wenn der Cursor im nächsten Feld platziert wird, überprüft das System die Eingabe. Handelt es sich um einen häufiger auftretenden Text bietet es an, wie Abbildung 25.12, „Nachfrage: Alle Vorkommnisse übersetzen?“ zeigt, alle Vorkommnisse des Textes mit der gewählten Übersetzung zu versehen.

Abbildung 25.12. Nachfrage: Alle Vorkommnisse übersetzen?

Zwischen dem Skript-Text und der Übersetzung bringt Q. mit kleinen Markierungen noch zusätzliche Informationen unter:

• Ein grün unterlegter Haken bedeutet ok.

• Ein rot unterlegtes Ausrufezeichen zeigt ein Problem mit der Übersetzung an und erläutert es, wenn der Mauszeiger darüber liegt.

• Das grau umrandete Uhrensymbol zeigt an, dass die Übersetzung geändert wurde. Ein Klick auf das Symbol zeigt die bisherigen Versionen der Übersetzung an.

Um Studien in mehreren Sprachen durchzuführen, müssen die Texte, die einen Fragebogen ausmachen, übersetzt werden. Über den Knopf [Language resource] kann eine Datei für die Übersetzung heruntergeladen werden (Voreingesteller Dateiname: def_lang.lrs). Die Datei besteht aus zwei Spalten: Die erste Spalte (bis zum ersten Leerzeichen) enthält die innerhalb des Fragebogens eindeutigen Bezeichner für den jeweiligen Text, der in der zweiten Spalte (nach dem ersten Leerzeichen) folgt.

Eine Übersetzung ordnet in einer separaten Datei den Bezeichnern (in der ersten Spalte) die übersetzten Texte in der zweiten Spalte zu - getrennt durch ein Leerzeichen. Eine solche Sprachdatei kann zu Beginn eines Interviews von Q. eingelesen werden, um den Fragebogen in der gewünschten Sprache auszugeben.

In der Regel spielt hier csv als Austauschformat eine Rolle, weil die Übersetzungstabelle gerne mit Tabellenkalkulationsprogrammen wie Excel bearbeitet wird.

Für die Fehlersuche kann es sinnvoll sein, sich das vollständige Skript anzusehen, so wie es Q. abarbeitet. Das bedeutet, alle Trennungen in verschiedene Dateien, die über include-Anweisungen zusammengeführt werden, alle Leerzeilen, die zur übersichtlichen Strukturierung im Skript eingefügt wurden, hebt Q. auf und zudem werden alle Makros expandiert. Das komplette Skript bietet Q. dann unter dem Namen skript_expanded.q zum Download an.

Im Fragebogenverzeichnis führt Q. anhand der einzelnen Interviewer-IDs Protokoll darüber, wann und bei welcher Frage Interviews begonnen, beendet oder abgebrochen wurden. Die entsprechende Datei surveylog.lst bietet der Knopf [Logfile] zum Download an.

Der Server für den Upload muss aus der ausklappbaren Liste gewählt werden. Den Inhalt der Liste bestimmt die Datei server.lst im config-Verzeichnis (s. „server.lst“).

Abbildung 25.13. Studien-Upload

Auf dem Zielsystem muss der Nutzer unter dem gleichen Login ebenfalls ein Konto haben, das dort mindestens über die Zugriffsrechte »reduced« verfügt. Falls die Studie bereits vorhanden ist, sie womöglich nur aktualisiert werden soll, muss sie vor dem Upload auf dem Zielserver deaktiviert werden.

Beim Upload auf den Server können einzelne Bestandteile der Studie ausgewählt bzw. ausgelassen werden:

Wenn Q. ein Android-Gerät am USB-Anschluss bemerkt, bietet es automatisch die Möglichkeit, die Studie auf das Gerät zu kopieren. Im Gegensatz zu den verschiedenen Server-Optionen kann die Studie nur vollständig auf Android kopiert werden. Als Option bietet das Programm nur an, das Medienverzeichnis beim Kopieren auszulassen.

Ist der zu kopierende Fragebogen auf dem Gerät bereits vorhanden, wird er durch den Upload nur aktualisiert, ansonsten wird die Studie neu angelegt. Der Unterschied macht sich auf Tablets vor allem bei den Fallnummern bemerkbar: Die Aktualisierung belässt es bei der fortlaufenden Zählung, bei neu angelegten Fragebögen beginnt die Zählung dagegen von vorn.

Am Anfang des Datenexports werden Sie folgendes sehen:

Abbildung 25.17. Erster Schritt zum Datenexport

Das heißt, dem System liegen noch keine Informationen vor, wie der Datensatz aufgebaut werden soll. Wenn Sie den Schraubenschlüssel drücken, liest Q. die Datei skript.q (die Datei, die Sie vorher einmal geskripted haben und mit der die Daten erhoben wurden) ein und verarbeitet sie.

Dabei erzeugt Q. eine Bespaltung und jeder Variablen wird ein fixer Platz im Datensatz zugeordnet. Sollten Sie einmal Ihr Skript verändern müssen, weil Sie vielleicht die erwähnten Fragen 2a und 2b mit aufnehmen möchten, müssen Sie anschließend auch eine neue colmap.lst erzeugen. Dabei zeigt sich die Stärke des individuellen Datensatzes für jeden Befragten.

Für die bereits erhobenen Daten gab es die Fragen 2a und 2b noch nicht. Die Variablen tauchen in dem jeweiligen Rohdatensatz also nicht auf. Diese neuen Fragen bleiben für diese Befragten im Gesamtdatensatz einfach leer, da die Zuordnung innerhalb des Datensatzes über den Variablennamen und nicht über eine feste Bespaltung vorgenommen wird.

Sie sollten es allerdings vermeiden, während der Feldzeit den Variablentyp zu ändern. Dadurch kann es zu unerwünschten Seiteneffekten kommen, z.B. wenn Sie aus einer Multiq eine Numq machen. Damit würde sich auch der Variablenname von z.B. F2 zu F2.1 ändern. Aus einer Singleq eine Multiq zu machen, funktioniert dagegen gefahrlos, in die andere Richtung wird es aber ebenfalls schief gehen.

Nach Drücken des Schraubenschlüssels erhalten wir folgende Ansicht:

Abbildung 25.18. Datenexport: colmap.lst erzeugen

An dieser Stelle können Sie eine colmap generieren oder auch eine selbst erzeugte hochladen. Beschränken wir uns an dieser Stelle einmal auf Rebuild & Save.

Nach dem Erzeugen der Colmap.lst sehen wir Folgendes

Abbildung 25.19. Inhalt der colmap

Im linken Teil sehen Sie den Inhalt der colmap (eine Reihe der in Kapitel 9, Interne Variablen angesprochenen internen Variablen schreibt Q. an den Anfang der Tabelle). Die 3 Knöpfe rechts sind selbsterklärend: Mit Rebuild & Save wird die colmap-Datei neu erzeugt, mit Download können Sie die colmap herunterladen, bearbeiten, um eventuell bestimmte Variablen nicht mit in den Gesamtdatensatz zu übernehmen und mit Upload können Sie diese wieder hochladen und für den weiteren Datenexport nutzen. Über den kleinen grünen Pfeil gelangen Sie wieder zurück und sehen anschließend folgendes Bild:

Abbildung 25.20. generierte Colmap

Im linken Kästchen sehen Sie, wann die Colmap erzeugt wurde. Mit der Colmap wird automatisch auch ein variable definition file erzeugt, das Sie mit GESStabs sofort weiter verarbeiten können.

Sehen wir uns einmal den Schraubenschlüssel im mittleren Kästchen an. Der Schraubenschlüssel führt uns zum Herzstück des Datenexports, der Variablendefinition, über die Datensätze in Kombination mit der Colmap im Gesamtdatensatz zusammengeführt werden.

Hier sehen Sie einen Ausschnitt aus der var.inc (die in Kapitel 9, Interne Variablen angesprochenen internen Variablen deklariert Q. um und setzt sys vor den Variablennamen).

Abbildung 25.21. Editiermöglichkeit für die var.inc-Datei

Mit Download können Sie diese Variablendefinitionen herunterladen.

Mit Rebuild & Save können Sie Variablendefinitionen noch an Ihre Bedürfnisse anpassen.

Abbildung 25.22. Optionen beim Speichern der var.inc-Datei

Bei Encoding können Sie die Kodierung (ANSI, UTF-8, UTF-16) einstellen, sie ist abhängig von der Plattform auf der Sie arbeiten. In der Regel müssen Sie hier nichts vorgeben.

Über den Punkt Language können Sie die Sprache wählen, in der die Variablendefinition ausgegeben werden soll. Haben Sie z.B. eine Internationale Studie in mehreren Sprachen, können Sie an dieser Stelle angeben, ob Ihr SPSS-Datensatz in der Native-Language, also der Sprache in der geskriptet wurde, ausgegeben wird oder in einer anderen Sprache, die in dieser Studie genutzt wurde.

Abbildung 25.23. Übersetzungsoptionen beim Speichern der var.inc-Datei

Bei dieser Studie können Sie beispielsweise einen deutschen oder einen englisch belabelten SPSS-Datensatz erzeugen oder einen ASCII-Datensatz mit einer deutschen oder englischen Datenbeschreibung.

Mit der Einstellung legacy bei Type entfernt Q. die Filter aus der für die Weiterverarbeitung zentralen Datei var.inc. Mit dieser Einstellung sollte der Export immer funktionieren. Mit der Wahl von normal versieht Q. die var.inc-Datei mit mehr Informationen und übernimmt z.B. die Filter aus dem Fragebogen. Die können allerdings auch Hürden für die weiter verarbeitenden Programme darstellen.

Da in Q. die Formatierungen der Befragungsscreens über HTML-Tags vorgenommen werden, diese aber nicht von jeder Software für die Weiterverarbeitung genutzt werden können, haben Sie hier die Möglichkeit, die HTML-Tags vorher zu entfernen. Das Gleiche gilt für Systemkommentare.

Abbildung 25.24. ASCII- oder SPSS-Datensatz speichern

Bleibt nun noch das rechte Kästchen, hier können Sie wählen ob Sie einen ASCII-Datensatz oder einen SPSS-Datensatz erzeugen möchten – an dieser Stelle empfehlen wir Ihnen unser Basic-Tutorial für die Tabellierung, das Sie ebenfalls auf unserer Homepage finden. Darin wird anschaulich der Unterschied zwischen ASCII- und SPSS-Datensatz erläutert (http://gessgroup.de/de/content/software/gess-tabs-dokumentation).

Interessant ist der Button OPN.

Q. unterstützt neben den klassischen Variablentypen (singleq, numq und multiq) auch noch andere Variablentypen, unter anderem den Variablentyp openq.

Dieser Variablentyp kann für offene Fragen genutzt werden, aber auch um z.B. Bilder, Tonaufnahmen oder Videos aufzunehmen. Voraussetzung dafür ist allerdings das Betriebssystem Android, das auf vielen Tablets oder Smartphones zu finden ist.

Nach Drücken des OPN-Buttons sehen wir folgendes:

Abbildung 25.25. Offene Nennungen speichern

Hier können Sie die wörtlichen Nennungen entweder als opn-Datei abspeichern, die von GESStabs direkt weiter verwendet werden kann oder als CSV um sie z.B. mit Excel weiter zu verarbeiten. Zusätzlich haben Sie die Möglichkeit, diese Dateien um weitere Variable zu ergänzen, z.B. bei der Nachfrage zur Präferenz können Sie den Codern noch die Variable mitgeben, in der das präferierte Produkt abgelegt ist.

Sollte es für eine Studie Photo-, Audio- oder Videodateien geben, werden diese übersichtlich für jeden Befragten als Links in einer Excel-Datei verwaltet, aus der diese Dateien direkt aufgerufen werden können. Q. sieht in dieser Excel-Datei neben den Links zu den Multimedia-Dateien auch Felder vor, in denen z.B. die Transkriptionen eingetragen werden können.

Ausgehend von einer vorhandenen GESStabs Installation (für Informationen hierzu sei auf die GESStabs Dokumentation verwiesen) sind im Q. Konfigurationsfile zwei Angaben zu machen: Der Pfad zum Studienverzeichnis gtcSurveyDir , der Pfad zur ausführbaren GESStabs Applikation gtcApp . Das Beispiel zeigt eine denkbare Konfiguration:

gtcSurveyDir=/home/gessuser/surveys
gtcApp=/home/gessuser/gtc/gtc
        

Jede Tabellierung in GESStabs startet mit der Ausführung eines .tab-Files, das sich im Studienordner neben text im Ordner gtc befinden muss. Erfolgt keine explizit andere Zuweisung (s. „Kundenspezifische Tabellen“) heißt das .tab-File per Default a.tab. Q. stellt für jede Tabellieranfrage Kopien der automatisch gepflegten ASCII und OPN Datensätze bereit, siehe „Daten und Export“. Zusammen mit einer Kopie der dort ebenfalls zu findenden Variablendefinition (var.inc) stellen diese Dateien die Datenbasis für GESStabs dar:

Die a.tab-Datei mit den Tabellieranweisungen kann hiermit nun frei definiert werden. Wenn sie nicht vorhanden sein sollte, hilft sich Q. indem es eine Standardvorlage dera.tab-Datei aus /CONFIG/gtc/ an seine Stelle kopiert und verwendet. Üblicherweise druckt dieser Standardfall eine einfache Auszählung über alle enthaltenen Variablen der Completes (s.u.). Wie der Standard aussehen soll, lässt sich wiederum frei definieren.

encoding = latin1;
splitchar = ~;
stylefile = style.css;
trimstrings = yes;
citefirstvar = TOPTEXT yvalid;

datafile = cmpl_tabs.dat;
casenumber = 31 30;
openqfile = cmpl_tabs.opn;

include = var_tabs.inc;
html = htmltabs;
codebook;
end;
        

Für verschiedene Kunden bzw. deren Logins können spezifische Tabellen hinterlegt werden. Dies lässt sich mit mehreren Tabellierdateien realisieren, die sich den Login IDs zuordnen lassen. Logins ohne explizite Zuordnung bekommen per Default das a.tab . Die Zuordnung ist optional und kann über die Benutzeroberfläche in der Studienkonfiguration vorgenommen werden.