Kurz gesagt
Der Vision Prototype soll früh sichtbar machen, wie sich IncluLearn.AI für Menschen anfühlen könnte, bevor die eigentliche KI- und Dateninfrastruktur vollständig angebunden ist.
Er ist deshalb weder eine statische Mockup-Sammlung noch bereits das fertige Produkt. Die Oberfläche ist als evolutionäre Grundlage angelegt: Navigation, Begriffe, Accessibility-Bausteine, DE/EN-Struktur und wiederverwendbare Komponenten sollen weiterverwendet werden, wenn sie sich in Tests bewähren.
Gleichzeitig gilt eine klare Grenze: Die derzeit sichtbaren Materialien, Jobs, Nutzer und fachlichen Ergebnisse sind Demo-Daten. Der Prototyp darf nicht so gelesen werden, als sei die gesamte Verarbeitungskette bereits produktiv.
Nicht „welches KI-Modell?“, sondern „was möchte ich mit meinem Material tun?“
Eine zentrale Produktentscheidung ist, technische Pipelinebegriffe aus der Hauptnavigation herauszuhalten.
Nutzende sollen nicht zuerst zwischen OCR, VLM, Embeddings, Sonifikation oder einzelnen Modellen wählen müssen. Im Vordergrund stehen Aufgaben wie:
- Materialien öffnen und weiterbearbeiten,
- Ergebnisse fachlich prüfen,
- freigegebene Fassungen bereitstellen,
- geteilte Inhalte finden,
- später geeignete Ausgaben erzeugen.
Technische Details können für Fachpersonen wichtig sein, sollen aber progressiv eingeblendet werden und nicht die Einstiegshürde bestimmen.
Das ist besonders relevant für Medienzentren und Lehrende, deren Fachkompetenz nicht voraussetzt, dass sie KI-Architekturen oder Prompting beherrschen.
Der Prototyp zeigt bereits drei getrennte Statusideen
Aus dem UX-Konzept ergibt sich eine für IncluLearn.AI wichtige Trennung:
- Verarbeitung: Wurde das Material technisch aufbereitet?
- fachliche Prüfung: Ist die erkannte Semantik tatsächlich geprüft?
- Zugriff/Bereitstellung: Wer darf welche Version sehen oder verwenden?
Diese Ebenen sollen nicht in einem einzigen grünen „fertig“-Status verschwinden.
Ein automatisch erzeugtes Ergebnis kann technisch abgeschlossen und trotzdem fachlich ungeprüft sein. Eine fachlich bestätigte Inhaltsversion ist wiederum nicht automatisch veröffentlicht oder für alle freigegeben.
Diese Unterscheidung ist eng mit der AI Governance des Projekts verknüpft.
Accessibility ist keine spätere Nachrüstung
Der Web-Prototyp wird mit Accessibility als technischer Grundanforderung entwickelt. Dazu gehören unter anderem:
- semantisches HTML vor zusätzlichem ARIA,
- vollständige Tastaturbedienbarkeit,
- sichtbarer und nicht verdeckter Fokus,
- Statusinformationen nicht nur über Farbe,
- Reflow und Zoom ohne Verlust zentraler Funktionen,
- reduzierte Bewegung,
- klare und lokalisierte Systembegriffe.
Deutsch ist Referenzsprache, Englisch wird in den Kernansichten strukturell mitgeführt. Weitere Sprachen sollen später ergänzt werden können, ohne die Informationsarchitektur neu aufzubauen.
Ein synthetischer Workflow statt vieler isolierter Screens
Die Demo verbindet inzwischen mehrere Ansichten zu einem Beispielablauf. Dazu gehört auch ein konkreter semantischer Demo-Ausschnitt, der zeigt, wie erkannte Struktur später prüfbar dargestellt werden könnte.
Wichtig ist die Formulierung „könnte“: Der sichtbare Ablauf ist eine Produkt- und UX-Hypothese, die Feedback ermöglichen soll. Er ist noch keine Aussage darüber, dass die gesamte fachliche Verarbeitung technisch fertig ist.
Das zugrunde liegende UI-Konzept geht noch weiter und beschreibt beispielsweise einen geführten Einstieg „Material aufbereiten“, klare nächste Schritte, Reviewaufgaben und eine Materialseite als verlässlichen Wiedereinstieg. Teile davon sind Zielbild und noch nicht vollständig implementiert.
Was noch nicht produktiv vorhanden ist
Die Plattformdokumentation nennt mehrere Komponenten ausdrücklich als geplant:
- FastAPI-Backend,
- Worker für asynchrone Verarbeitung,
- PostgreSQL und Object Storage,
- produktive authentik/OIDC-Anbindung,
- versionierte Semantikschemata,
- produktive Processing-Service-Orchestrierung.
Auch die aktuelle Webanwendung nutzt Demo-Fixtures noch direkter, als es für die spätere Produktplattform vorgesehen ist. Vor produktiver Persistenz soll deshalb eine stabilere Datenzugriffsschicht eingezogen werden.
Warum der Prototyp für Beirat und Partner wichtig ist
Gerade weil die Backendfunktionalität noch nicht fertig ist, können Navigation, Begriffe und Arbeitsabläufe jetzt vergleichsweise günstig verändert werden.
Für Beirat, Medienzentren, Lehrende und blinde/sehbehinderte Fachkräfte ist daher nicht nur die Frage interessant, ob die Demo „gut aussieht“. Wertvoller sind Rückmeldungen wie:
- Ist jederzeit klar, was schon geprüft wurde?
- Ist der nächste sinnvolle Schritt verständlich?
- Werden technische Begriffe unnötig vorausgesetzt?
- Ist Review auch nicht-visuell vollständig möglich?
- Sind Teilen, fachliche Freigabe und Veröffentlichung klar genug getrennt?
Solches Feedback kann die Plattformstruktur verändern, bevor sie durch Backend und produktive Datenmodelle schwerer beweglich wird.