Rückmeldung zu "Workaround zu Mulilevel-Design funktioniert teilweise"

Question

Vielen Dank für Ihre Tipps - das Update des Fortschrittsbalkens konnte ich über option('progress', ...) korrekt umsetzen, war ein Verständnisproblem meinerseits da ich davon ausging dass bei bekannter Anzahl von Wiederholungen ein Update automatisch erfolgen würde.

Das Problem der doppelten Ausführung konnte ich nun ebenfalls identifizieren, tut mir leid dass ich Ihnen da unnötige Mühe bereitet habe: ich hatte letzte Nacht, um meinen alten PHP-Code zu "sichern" das alte PHP-Element auf die Folgeseite (mit einer größeren Anzahl Elemente) verschoben und gedacht, ich hätte den multiLevelDown(...)-Aufruf dort auskommentiert - hätte vermutlich besser schlafen statt coden sollen ;-). Nach dem Löschen des Blocks funktioniert nun alles wie erwartet.

Für alle, die mit ähnlichen Problemen (fehlender Weiterschaltung des Unterbogens bei Multilevel-Design, kein Update des Fortschrittsbalkens) konfrontiert werden noch mal kurz zusammengefasst die Tipps, die zum Erfolg geführt haben:

1. Im Unterbogen eine leere Seite mit einem PHP-Codeblock mit dem Inhalt multiLevelReturn(); hinter der eigentlichen Fragebogenseite einfügen.
2. Fortschrittsbalken im Unterbogen manuell mittels option('progress', ...) und dem passend errechneten Prozentwert für den Fortschritt updaten.

Herzlichen Dank nochmal für den schnellen und kompetenten Support am Wochenende!

Comments

Prinzipiell funktioniert der Bogen wie oben geschrieben nun - es kam allerdings von den beteiligten Kollegen im Test der Wunsch auf, innerhalb der Schleife einen Zurück-Button einzublenden um noch einmal auf vorige Eingaben zurückgehen zu können (noch schöner wäre es, wenn man manuell zu einem bestimmten Objekt zurückspringen könnte).
Sowohl im Hauptfragebogen als auch im Unterbogen sind die entsprechenden Einstellungen für "Zurück-Knopf anzeigen" gesetzt, zudem habe ich bereits versucht, per option('backbutton', true); sowohl im aufrufenden Code des Hauptbogens als auch im Unterbogen für eine Anzeige des Zurück-Buttons zu sorgen, leider ohne Erfolg. Ist das vor/zurückspringen an dieser Stelle bei Multilevel-Design schlicht nicht vorgesehen oder gibt es noch eine Möglichkeit, dies irgendwie zu aktivieren? Vielen Dank für Hinweise

Answer 1

es kam allerdings von den beteiligten Kollegen im Test der Wunsch auf, innerhalb der Schleife einen Zurück-Button einzublenden

Das wird beim Multi-Level-Design nicht ohne weiteres funktionieren. Denn Sie sehen ja die ganze Zeit nur den untergeordneten Fragebogen - und dieser startet ja immer auf der ersten Seite.

Allerdings mönnen Sie folgendes machen: Sie können im Untergeordneten Fragebogen 2 zusätzliche Seite einfügen. Die erste (Nr. 2) enhält ein multiLevelReturn(0) und die anderen (Seite Nr. 3) ein multiLevelReturn(1). Außerdem fügen Sie auf der Seite Nr. 1 mit dem Stimulus mittels buttonToPage() eine "Zurück"-Knopf ein, welcher auf Seite Nr. 3 verweist.

Im Hauptfragebogen bekommen Sie dann entweder den Wert 0 oder 1. Im zweiten Fall sorgen Sie mittels goToPage() dafür, dass es rückwärts geht. Allerdings müssten Sie ausprobieren, ob goToPage('back') oder goToPage(-2) funktionieren. Falls nicht, muss ich mir das nochmal genauer ansehen.

Comments

Vielen Dank für Ihre Tipps, leider passsiert beim Klick auf den eingefügten Button weder mit goToPage('back'); noch goToPage(-2); etwas.

Was ich gemacht habe:

- Auf Seite 1 des Unterbogens (Kennung sub) den Button oben eingefügt:  

   html(
      '<div style="text-align: center; margin: 2em 0"><br>'.
      buttonToPage('seite2return', 'Zurück zur vorigen App').
     '</div>');

- Neue Seite 2, Kennung seite1return mit Inhalt: `multiLevelReturn(0);`
- Neue Seite 3, Kennung seite2return mit Inhalt: `multiLevelReturn(1);

- Im Hauptbogen unterhalb des multiLevelDown(...)-Aufrufs folgenden Code eingefügt:

   $returnData = multiLevelResponse();
   debug(returnData);
   if ($returnData == 1) {
      // goToPage('back');
      goToPage(-2);
   }

(Die debug()-Ausgabe sehe allerdings aufgrund des bekannten Problems bei unserer Installation nicht, die für SoScisurvey Zuständigen bei unserem IT-Support habe ich leider noch nicht erreicht.)

---

Leider komme ich auch nach mehreren Tagen noch nicht weiter - habe jetzt auf Ihrem Server einen Test angelegt, um das Problem mit der auf unserer lokalen Installation nicht funktionierenden Debug-Ausgabe zu umgehen.

Dort bekomme ich nun jeweils nach klick auf den eingefügten Zurück-Button die Meldung "There is no page in the questionnaire with the following ID: back. The command goto() has therefore not been executed." bzw. "There is no page in the questionnaire with the following ID: 2. The command goto() has therefore not been executed.", je nachdem ob ich es mit goToPage("back") oder goToPage(-2) probiere. Kann es sein, goToPage sich hier vertut zwischen Haupt- und Unterbogen? Mir gehen etwas die Ideen aus, außer >100 Kopien des Bogens anzulegen (eine je Objekt), die dann der Reihe nach abgearbeitet werden müssen - das Anspringen bestimmter Bögen bzw. ein funktionierender Zurück-Knopf werden inzwischen von den Kollegen als essenziell angesehen...
Hätten Sie vielleicht noch weitere Tipps für mich? Vielen Dank!

---

Ich befürchte, das Problem liegt eher darin, dass die numerische Angabe des Sprungziels nicht implementiert ist. Aber einen Versuch war es wert.

Eine weitere Hürde wäre dann noch, dass bei einer Wiederholung ein zweiter Datensatz zum selben Stimulus entstehen würde - und dass die Angaben von der ersten Wiederholung nicht mehr einsehbar wären, sondern alles neu eingetragen werden müsste. Insgesamt keine besonders attrative Lösung, je länger ich darüber nachdenke.

In diesem Fall muss ich leider mitteilen, dass die Zurück-Funktion mit einem Multi-Level-Design aktuell nicht sinnvoll realisierbar ist.

---

> ein funktionierender Zurück-Knopf werden inzwischen von den Kollegen als essenziell angesehen

In diesem Fall müssten Sie auf das Multi-Level-Design verzichten und mit einer größeren Anzahl Variablen im Datensatz arbeiten.

Normalerweise würde ich versuchen, noch kurzfristig eine andere Lösung zu ermöglichen. Aber jeder Ansatz, der mir gerade einfällt, wirft neue Hürden auf. Wenn Sie bis 2021 Zeit hätten vielleicht...

---

Herzlichen Dank für Ihre Mühe, 2021 sprengt dann doch etwas unsere Zeitplanung ;-)
Wir werden intern noch mal beraten wie wir jetzt weiter vorgehen.

---

Noch eine kurze Rückmeldung wofür wir uns letztendlich als Workaround entschieden haben:
Wir haben nun "quick & dirty" > 100 separate Fragebögen angelegt (einen für jedes zu bewertende Objekt), die sich lediglich durch den Verweis auf den Key in der Datenbank für Inhalte unterscheiden. Diese sind nur für Zugriff per Seriennummer freigeschaltet.
Jeder Teilnehmer (zum Glück nur im einstelligen Bereich) bekommt nun eine Liste mit individuellen URLs zu allen Bögen (d.h. Fragebogen-Kennung und individuelle Seriennummer sind wie in der Doku unter "Der Link zum Fragebogen" beschrieben angegeben). Damit sind die erfassten Datensätze eindeutig identifizierbar, und, solange der jeweilige Bogen noch nicht vollständig abgeschlossen ist, auch noch einmal aufruf- und änderbar. Um ein unbeabsichtigtes vorzeitiges Abschließen eines Bogens zu verhindern haben wir auf den Bögen nach der eigentlichen Seite mit den Fragen eine Seite mit einem Captcha eingefügt.  
Zwar sicher keine perfekte Lösung, aber aufgrund des Zeitdrucks dennoch wesentlich komfortabler und schneller aufzubauen als alle Alternativen zum Bewerten der vorliegenden Daten (Mega-Excel-Sheet, selbstprogrammierte Lösung, ...).
Trotzdem noch einmal vielen Dank!

---

Technisch grausam aber findig und funktional ;)