Fallakte 04 Kostenlose Lernplattform Live

Keine Werbung. Keine Paywall.
Kein Konto. Dieser Verzicht schrieb die Architektur.

Tedzi ist eine kostenlose Lernplattform für Kinder und Erwachsene — Physik, Chemie, Rhetorik, Web-Sicherheit, schneller lesen, Zeitmanagement und mehr. Sie funktioniert auf einem Handy ohne Empfang, und sie fragt nie, wer Sie sind.

Dieser Verzicht ist kein Marketing. Weil es kein Konto gibt, gibt es keinen Server, der den Lernstand von irgendjemandem hält — also auch keine personenbezogenen Daten zu schützen und fast nichts am Laufen zu halten. Ein kostenloses Produkt überlebt von den Betriebskosten, die man beim Entwurf vermieden hat.

Auf einen Blick
Status
Live
Art
Kostenlose Lernplattform
Kurse
30+
Stack
Statische PWA · Service Worker
Konten
keine
Tracking
keins
Build-Gates was die Pipeline verweigert
  1. Lint Inhaltsbaum failÜber tausend Beschädigungsspuren in 68 Dateien. Gültiger Text, falsche Zeichen, kein Absturz.
  2. Revert 68 Dateienletzter sauberer Commit hergestelltAus der Versionsverwaltung wiederhergestellt statt von Hand repariert.
  3. Lint Inhaltsbaum passNull Spuren. Die Prüfung gehört jetzt zum Build und lässt ihn scheitern.
  4. Version App + Shell-Cache gekoppeltBeide steigen gemeinsam, sonst bekommen Wiederkehrende eine veraltete Hülle — eine Regel, die der Build jetzt erzwingt.
  5. Kurs eine JSON-Dateiein fertiger Test datenEin Fach hinzuzufügen heißt Inhalte schreiben, nicht Code ausliefern.

Jedes dieser Gates gibt es, weil einmal etwas durchgekommen ist. Eine Inhalts-Pipeline ist nur so gut wie das, was sie abzulehnen bereit ist.

Ausgangslage Was der Verzicht einbringt § 01

Kostenlose Produkte sterben an Betriebskosten, nicht an schlechten Ideen.

Die übliche Form für eine Lernplattform: ein Konto, ein Server der den Fortschritt speichert, und Analytics um beides zu rechtfertigen. Jedes davon ist eine wiederkehrende Rechnung, eine Datenschutzpflicht und etwas, das um sieben Uhr morgens ausgefallen sein kann, wenn ein Kind üben will.

Also haben wir das beim Entwurf entfernt, statt später zu sparen. Fortschritt, Punktestände und der Wiedereinstieg leben im Browser. Die Anwendung besteht aus statischen Dateien und einem Service Worker. Zu betreiben bleibt ein Webserver, der Dokumente ausliefert — deshalb kann die Plattform kostenlos bleiben, ohne dass jemand in einem harten Quartal entscheidet, sie müsse jetzt Geld verdienen.

Die interessante Technik steckt deshalb nicht in der App. Sie steckt in der Pipeline, die die Kurse herstellt.

Bestand Was gebaut ist § 02

30+ Kurse
2.300+ Testfragen
0 Konten
0 Tracker

Entscheidungen Was wir wählten, und was es kostete § 03

Drei Entscheide, alle Folge desselben Verzichts.

Entscheid 01 · Speicherung

Kein Konto, also ist der Browser die Datenbank.

Punktestände, Verlauf und die Möglichkeit, einen pausierten Test fortzusetzen, liegen im lokalen Speicher. Es gibt keine Anmeldung, kein Passwort-Zurücksetzen, keine Sitzung und nirgends eine Tabelle, in der eine lernende Person steht.

Kostet: der Fortschritt folgt niemandem auf ein zweites Gerät, und wer die Websitedaten löscht, löscht ihn.
Bringt: keine personenbezogenen Daten zu schützen, keine Anmeldung zu pflegen, und Betriebskosten nahe null.

Entscheid 02 · Erweiterbarkeit

Ein neuer Kurs ist Daten, kein Code.

Die Test-Engine liest je Kurs eine strukturierte Datei. Ein Fach hinzuzufügen heißt Fragen schreiben und eine Datei ausliefern — kein Branch, kein Release, kein Regressionsrisiko für die Kurse, die schon funktionieren.

Erst das machte eine Agenten-Truppe als Redaktion überhaupt tragfähig. Sie produziert Daten gegen ein Schema; die Engine bleibt unangetastet.

Kostet: das Schema muss früh stimmen, denn alles, was dagegen geschrieben wird, erbt seine Fehler.
Bringt: Inhalte skalieren, ohne dass die Entwicklung zum Engpass wird.

Entscheid 03 · Didaktik

Falsche Antworten kommen wieder, bis sie sitzen.

Ein Test ist nicht zu Ende, wenn er endet, sondern wenn jede Frage mindestens einmal richtig beantwortet wurde. Dazu ein Zeitmodus, eine Punktehistorie, und ein pausierter Test lässt sich später fortsetzen.

Das kam alles in der ersten Fassung, statt nachgerüstet zu werden. Motivations-Mechanik, die man später aufsetzt, sitzt meist auf einem Entwurf, der sie nicht erwartet hat.

Kostet: eine kompliziertere erste Auslieferung, als ein schlichtes Quiz gewesen wäre.
Bringt: eine Lernschleife statt einer Punkteanzeige.

Störfälle Was kaputtging, und was es verändert hat § 04

Beides waren Pipeline-Fehler, keine Anwendungsfehler.

Inhaltsintegrität

Parallele Schreiber zerlegten den Inhaltsbaum.

Mehrere Agenten schrieben gleichzeitig in dieselben Kursdateien. Umlaute fielen unter den überlappenden Schreibvorgängen auseinander. Achtundsechzig Dateien waren betroffen, über tausend Beschädigungsspuren sammelten sich an, bevor jemand hinsah — denn nichts scheiterte. Die Dateien waren weiterhin gültig, wurden weiterhin gelesen, wurden weiterhin angezeigt. Sie waren nur falsch.

Was wir angenommen hatten: dass getrennte Tickets getrennte Dateien bedeuten. Das stimmte oft genug, um sich wie eine Regel anzufühlen — und wurde nie als eine aufgeschrieben.

Behoben → aus der Versionsverwaltung wiederherstellen, dann die Beschädigungsprüfung zu einem Build-Gate machen, das scheitert statt zu warnen. Inhalt ist ein Build-Artefakt und verdient dieselben Gates wie Code.

Cache-Kohärenz

Wiederkehrende Besucher sahen die App von gestern.

Ein Service Worker lässt die App offline funktionieren. Er bedeutet aber auch, dass Wiederkehrenden ausgeliefert wird, was zwischengespeichert war — und diesen Speicher korrekt zu erneuern ist eine zweiteilige Aktion: Anwendungsversion und zwischengespeicherte Hülle müssen sich gemeinsam bewegen. Taten sie es nicht, brauchte es zwei Neuladungen für eine Änderung.

Was wir angenommen hatten: dass neue Dateien auszuliefern dasselbe ist, wie sie zuzustellen. Bei einer Offline-First-App ist es das nicht.

Behoben → die beiden Versionsmarken so koppeln, dass sie sich nur gemeinsam bewegen können, und automatisch neu laden, sobald ein neuer Worker übernimmt. Eine Neuladung leistet jetzt, wofür es vorher zwei brauchte.

Übertrag Was das für Sie bedeutet § 05

Inhalts-Systeme scheitern anders als Software-Systeme.

Inhalt als Build-Artefakt behandeln

Text wirft keine Ausnahmen. Wenn eine Pipeline Inhalte herstellt, braucht sie Gates, die den Build scheitern lassen — sonst erfahren Sie von der Beschädigung durch einen Leser.

Offline-First ist eine Datenhoheits-Entscheidung

Den Zustand in den Browser zu legen entfernt in einem Zug einen Server, eine Anmeldung und eine Datenschutzpflicht. Es kostet Geräte-Übergreifendes — oft ein fairer Tausch, und immer einer, den man bewusst machen sollte.

Zuerst das Schema, wenn Nicht-Entwickler es füllen

Sobald Inhalte gegen ein Schema entstehen statt durch eine Codebasis, ist das Schema Ihre Schnittstelle. Fehler darin pflanzen sich in alles fort, was danach geschrieben wird.

Pipelines misst man daran, was sie ablehnen.

Wenn Sie Inhalte in Menge herstellen — mit Menschen, mit Modellen oder mit beidem — steckt das Schwere in den Gates. Wir bauen die, die früh und laut scheitern.