Branching Tales – How to tell a story?
Geschichten erzählen ist seit Jahrtausenden Bestandteil unserer Kultur. Was früher ein gemeinsames Lauschen am Lagerfeuer war, wurde während dem Laufe der Zeit Bücher, Hörspiele und Spielfilme. Was fast alle in gemein haben, ist eine erzählerische Linearität. Doch das ist eine Limitation, die wir heute nicht mehr haben. Und deswegen gibt es Branching Tales, ein Werkzeug, um interaktive Geschichten im Web zu erstellen.
How it started
Ursprünglich ist dieses Projekt aus dem Bedarf, animierte Comics und Scrollytelling-Geschichten im Web ansprechend und einfach darstellen zu können. Einsatzort: Forschungskommunikation an der Fernfachhochschule Schweiz (FFHS), produziert durch uns in der MediaFactory der FFHS. Es gibt verschiedene Webtechnologien, um so etwas ähnliches umzusetzen, doch keine erfüllte die spezifischen Bedingungen für unsere Projekte. So habe ich beschlossen, ein eigenes Tool zu konzipieren und entwickeln – ein Tool, dass unser Team nutzen kann. Das hier ist nicht dieses Tool.
Die erste Version dieses Webtools entstand während eines Sommers. Über die letzten drei Jahren haben wir sie genutzt und eingesetzt. Auch habe ich sie kontinuierlich weiterentwickelt und neue Features hinzugefügt – allem voran die Möglichkeit Branching Scenarios erstellen zu können. Die Limitationen des Tools haben sich jedoch im Verlauf der Jahre immer klarer gezeigt. Grund dafür waren grundsätzliche Entscheide des Softwaredesigns und der Struktur der Comics zu Beginn der Reise. Es war klar, dass praktisch ein kompletter Neubau der Website notwendig ist. Und das ist nun dieses Tool.
What we needed
Drei zentrale Fähigkeiten meines ersten Scrollytelling-Builder fehlten, um flexiblere und reichere Scrollytelling‑Comics zu ermöglichen.
Arbeiten mit Ebenen: Statt einer fixen Kombination aus einem Hintergrundbild und einer Lottie-Animation, sollten mehrere Elemente übereinandergelegt werden können.
Einsatz von Text: Textelemente sollten nativ und editierbar im Layout integriert werden, anstatt nur als fest eingebrannte Bestandteile der Bilder.
Freie Positionierung: Elemente sollten beliebig in der Kachel positionier‑ und skalierbar sein. Sie müssen nicht mehr an die Kachel‑Grösse gebunden sein.
Um das zu erreichen, mussten drei Kernbereiche überarbeitet werden: das Speicherformat der Geschichten, der Renderer zur Darstellung und der Editor zur Erstellung/Bearbeitung. Die grundsätzliche Entscheidung, die Geschichten als JSON‑Files zu speichern und so auf eine SQL‑Datenbank zu verzichten, bleibt bestehen. Das erlaubt einfache Teilbarkeit, Export/Import und Hosting auf jedem Standardserver. Innerhalb dieses JSON‑Formats wird die innere Struktur jedoch ebenenbasiert neu modelliert. Renderer und Editor mussten dahingehend neu konzipiert werden, um die neue Datenstruktur nutzen zu können. Das grösste Update war dadurch beim Editor, auch wenn der neue Renderingvorgang der komplexeste Teil war.
Zu guter Schluss ist es sowohl ein persönliches Ziel meinerseits als auch das Ziel der FFHS, dieses Tool Open Source anbieten zu können. Das zentralste Prinzip der Bildung ist die Wissensvermittlung. Sie bietet Menschen ein Informationszugang, von welchem später wieder weitere Menschen profitieren. Es ist ein Kreislauf, auf dem unsere Gesellschaft beruht. Deswegen ist es für uns auch wichtig, etwas dieser Bildungslandschaft und der Open Source Community zurückzugeben. Auch wenn dieses Tool nicht nur spezifisch von Schulen genutzt werden kann, ist es ein Werkzeug, um Wissen und Geschichten teilen zu können. Deswegen ist dieses Projekt frei auf GitHub verfügbar.
Hier könnt Ihr schauen, wie so eine Story aussehen könnte: Storytelling Introduction
How it went
Ich begann mit einer Neukonzeption der Story‑Struktur und legte eine erste Test‑Story manuell im neuen JSON‑Format an, die alle vorgesehenen Elemente (Branchings, mehrere Ebenen, vertikale/horizontale Ausrichtung) enthielt. Darauf aufbauend entwickelte ich den Renderer, der diese Daten visualisieren sollte. Die zentralen Herausforderungen waren das präzise Positionieren von Elementen innerhalb einer Kachel und das Zusammenspiel frei platzierter Bilder und Lottie‑Animationen. Vor allem der Mechanismus sowohl klassisch vertikale als auch horizontale Stories erstellen zu können, erschwerte das Rendering auf Grund der Art, wie Browser die Position/Grösse von Elementen berechnen und darstellen.
Für Text entschied ich mich bewusst für einen bestehendes Markdown‑basierten Tool (zero-md), um einfache Formatierungsmöglichkeiten zu ermöglichen und gleichzeitig die Integration in das Layout zu vereinfachen.
Der zeitaufwändigste Teil war der Editor. Ziel war ein intuitiver, flüssiger Workflow, der komplexe Kompositionen ohne Hürden erlaubt. Dazu mussten alle Interaktionen einzeln programmiert werden – Positionierung, Skalierung, Layer‑Management, Klickflächen sowie Branching‑Kontrolle. Technisch bedeutete das einen Architekturwechsel: weg von alten, formularbasierten Inputs mit AJAX‑Aufrufen und Seitenreloads, hin zu einer client‑zentrierten Lösung. Der Editor kommuniziert nun über fetch‑Requests mit dem Backend, während JavaScript die Vorschau in Echtzeit aktualisiert und alle Änderungen lokal spiegelt, während sie gespeichert werden. Dieses Frontend‑lastige Vorgehen macht den Editor einfacher zu bedienen, erforderte jedoch umfangreiche Umstrukturierung und Tests, insbesondere zur Synchronisation von Editor‑State und JSON‑Speicherformat. Zudem ist der Code im Vergleich viel sauberer strukturiert, Skripts und Anzeigeseiten strikter voneinander getrennt und auch etwas lesbarer aufgebaut. Ich bin mir sicher, in Zukunft werde ich auf diesen Code schauen und mich wieder fragen, warum ich das ausgerechnet so gemacht habe. Im Vergleich mit meiner vorherigen Version ist es jedoch ein gewaltiges upgrade, mit welchem ich sehr zufrieden bin.
Ihr könnt diesen Editor nun auch selbst austesten. Ihr könnt das Projekt von GitHub kopieren und auf einem eigenen (lokalen) Server nutzen oder auch auf meiner Demo-Seite ausprobieren. Die Daten werden dort einmal pro Tag auf den Ursprungszustand zurückversetzt. Achtung, es gibt noch kein Usermanagement.
Ihr findet die Demo hier: demo.branchingtales.ch
How it continues
Ist dieses Tool nun fertig? Nein, ganz klar nicht. Wenn ich über die letzten Jahre eines gelernt habe, dann, dass ein solches Projekt nie wirklich fertig ist. Schon jetzt habe ich Ideen und Funktionen, welche ich hinzufügen möchte, von denen ich weiss, dass sie eine gute Ergänzung wären. Auch einige geplante Features, wie zum Beispiel eine Videoeinbindung oder ein Versionierungssystem, sind noch auf meiner To-Do-Liste. Doch der aktuelle Stand stellt eine erste funktionierende Version dar. Auch eine richtige solche Story zu erstellen, ist ein weiteres Ziel von mir. Das ist jedoch eine Geschichte für ein anderes Mal.
(mmi)
Ich kann nicht behaupten, dass ich überrascht war, wie viel Zeit das Projekt in Anspruch nahm. Mir war schon am Anfang bewusst, es ein ambitioniertes Projekt wird. Zu dem Zeitpunkt bin ich jedoch auch noch davon ausgegangen, dass ich den Grossteil der Funktionen für die Interaktionen im Editor lediglich umschreiben und anpassen könne. Dies war jedoch schlussendlich grösstenteils nicht der Fall. Grund dafür ist die neue client-zentrierte Struktur des Programms. Diese Umstrukturierung war auf jeden Fall die richtige Entscheidung, besteht sie neu auf einer action-basierten Logik, welche zwischen Client und Server kommuniziert. Das ermöglicht mir in Zukunft ein Versionierungssystem zu integrieren und hat im Allgemeinen dafür gesorgt, dass mein Code sehr viel strukturierter und übersichtlicher wurde. Meine alte Version bestand zugegebenermassen aus viel Spagetti-Code – auch da ich damals das erste Mal mit ChatGPT versucht habe zu programmieren.
KI als Hilfsmittel war auch dieses Mal ein wichtiger Teil der Arbeit, auch wenn sich der Arbeitsprozess stark verändert hat. Grossteils vorbei sind die Zeiten der offenen Prompts, um eine Funktion hinzuzufügen und einfach ins Projekt zu kopieren. Ich habe über die Zeit gemerkt, dass ein solches Vorgehen mir nicht hilft, mich im Programmieren zu verbessern. Daher bin ich diesen Prozess für dieses Projekt anders angegangen. Was ich selbst schreiben konnte, habe ich selbst geschrieben. Wenn ich nicht wusste, wie vorgehen, habe ich mir einen Vorschlag generieren lassen, auf welchem ich aufbauen konnte. Mein Ziel war es dabei immer, diesen Vorschlag zu verstehen und basierend darauf in den weiteren Funktionen so umzusetzen. Als Beispiel dazu kann ich das action-basierte System nennen. In meiner Suche nach dem besten Vorgang wurde mir diese Struktur vorgeschlagen und ein erstes Beispiel gezeigt. Anhand von diesem konnte ich dann alle weiteren Aktionen selbst in diese Struktur integrieren. Ausnahme bilden da die zwei Funktionen zuständig für das Verschieben und Skalieren von Objekten. Diese überstiegen mein Verständnis. Ab da diente mir KI ansonsten nur noch der Effizienzsteigerung. So nutzte ich sie, um bestehende Funktionen zu modifizieren oder verwandte Funktionen basierend auf bestehenden zu erstellen. Dinge, die ich auch selbst hätte schreiben können, mir aber viel Zeit erspart haben. Gesparte Zeit, die ich auch benötigte, um alle Interaktionen im Editor neu zu schreiben anstatt wie geplant wiederverwenden zu können.
Insgesamt bin ich sehr zufrieden. Ich konnte viel lernen, was sich in IM2 auch schon wieder bezahlt gemacht hat. Auch wenn die einzelnen Funktionen zu programmieren länger gedauert haben als geplant, bin ich auf weniger Probleme gestossen als erwartet und konnte dadurch sehr speditiv vorankommen. Und ich freue mich auch schon an der Website weiterzuarbeiten und das Projekt noch zu verbessern.