PROJEKTEINBLICK ·
Ich musste nicht von vorne anfangen
Nach der Pause stand die Entscheidung: Mein Assistent sollte eine Webanwendung bekommen. Die Frage war, wie viel von meiner bisherigen Arbeit dafür übrig bleiben würde. Musste ich neu anfangen? Oder konnte ich auf dem aufbauen, was bereits funktionierte?
Ich hatte inzwischen einen Assistenten, mit dem ich sprechen konnte. Er erkannte Befehle, führte Skills aus und fragte bei entsprechend eingestuften Aktionen nach meiner Zustimmung. Dazu kamen seine Instruktionen und die Protokolle, mit denen ich seine Abläufe nachvollziehen konnte.
All das steckte in dem Projekt, das ich zuletzt erst einmal zur Seite gelegt hatte. Die Vorstellung einer neuen Oberfläche war reizvoll. Die Vorstellung, die ganze Arbeit noch einmal zu machen, deutlich weniger.
Ich entschied mich für eine Webanwendung. Mein Assistent sollte im Browser sichtbar und bedienbar werden. Damit hatte die offene Frage aus dem letzten Teil eine Richtung bekommen. Nun musste ich herausfinden, was dieser Schritt für die bestehende Anwendung bedeutete.
Jetzt zahlte sich die Trennung aus
Genau hier half mir die Architektur, mit der ich mich vorher so oft beschäftigt hatte. Ich hatte meine Fähigkeiten und Abläufe nicht ausschließlich in die Konsolenoberfläche eingebaut. Die CLI war ein Zugang zu meinem Assistenten. Sie war nicht alles, was ihn ausmachte.
Das klingt im Nachhinein selbstverständlich. Während der Entwicklung hatte diese Trennung aber immer wieder Arbeit gemacht: Schnittstellen definieren, Zuständigkeiten auseinanderziehen und refactorieren, obwohl ich eigentlich gerade eine neue Idee ausprobieren wollte.
Jetzt konnte ich einen großen Teil davon weiterverwenden. Die Intent-Pipeline musste nicht neu erfunden werden. Ebenso wenig brauchte jeder Skill eine zweite Umsetzung, nur weil die Eingabe künftig aus einem Browser kam.
Ich musste meinem Assistenten ein neues Gesicht geben. Seinen Kern konnte ich behalten.
Der grundlegende Umbau hielt sich dadurch in Grenzen. Die bisherigen Entscheidungen machten aus dem Wechsel der Oberfläche eine Erweiterung des Projekts, statt mich zu einem kompletten Neubau zu zwingen.
Ein zweiter Zugang zum selben Assistenten
Zur bestehenden Anwendung kam ein Webhost auf Basis von ASP.NET hinzu. Er verband den vorhandenen C#-Unterbau mit der Oberfläche im Browser. Für den Austausch verwendete ich SignalR, auf der sichtbaren Seite HTML, CSS und JavaScript.
SignalR war dabei die Verbindung für Nachrichten und Zustandsänderungen. Wenn der Assistent etwas verarbeitete oder eine Antwort lieferte, konnte die Oberfläche darauf reagieren. Und eine Eingabe im Browser konnte den Weg zurück in die Anwendung nehmen.
| Was ich weiterverwenden konnte | Was für die Weboberfläche hinzukam |
|---|---|
| Intent-Erkennung und vorhandene Skills | Bedienung und Darstellung im Browser |
| Gemeinsame Dienste und Modellanbindung | Webhost und SignalR-Verbindung |
| Bestehende Regeln und Ausführungspfade | Sichtbare Zustände und Rückmeldungen |
| Erfahrungen aus den Sprachpipelines | Anpassungen für Audio im Browser |
Die Konsole musste dafür nicht verschwinden. Sie blieb als direkter Zugang zum Kern nützlich. Ich hatte jetzt die Möglichkeit, an der Darstellung zu arbeiten, ohne bei jeder Änderung die Fähigkeiten darunter neu anzufassen.
Das war für mich der praktische Wert der Modularität aus Teil 3. Sie machte sich genau dann bezahlt, als sich meine Vorstellung von der Anwendung veränderte.
Ganz ohne neue Arbeit ging es natürlich nicht
Ein Browser verhält sich anders als eine Konsole. Die Oberfläche verbindet sich mit dem Server, kann die Verbindung verlieren und später wieder zurückkommen. Auch Mikrofon und Audiowiedergabe brauchen dort einen anderen Umgang.
Wichtig war mir dabei, dass die Oberfläche zum tatsächlichen Ablauf passte. Wenn sie Zuhören anzeigte, sollte der Assistent auch zuhören. Wenn eine Verbindung fehlte, durfte die Bedienung nicht den Eindruck erwecken, alles sei bereit.
Die Zustände, die ich bisher in der Konsole und den Protokollen verfolgt hatte, bekamen damit eine sichtbare Aufgabe. Sie waren die Grundlage dafür, was die Oberfläche anzeigen konnte.
Jetzt konnte ich ihm ein Gesicht geben
Mit der Webanwendung öffnete sich ein anderer Teil des Projekts. Ich konnte über Anordnung, Farben, Bewegung und die Darstellung von Antworten nachdenken. Der Assistent sollte auch optisch etwas von der Idee vermitteln, die mich ursprünglich begeistert hatte.
Dabei musste ich nicht mehr überlegen, ob jede gestalterische Änderung einen Umbau der Intent-Pipeline nach sich zog. Die Oberfläche konnte sich entwickeln, während der gemeinsame Kern weiter seine Arbeit machte.
So wurde aus der Frage, ob ich meine bisherige Version wegwerfen musste, ein neuer Abschnitt desselben Projekts. Die Arbeit an der CLI war nicht verloren. Sie hatte den Unterbau geliefert, auf dem ich jetzt weiterbauen konnte.
Und mit der sichtbaren Oberfläche entstand bald die nächste Frage: Musste jede Information nur als Antwort im Gespräch auftauchen? Wetter oder Uhrzeit konnten doch auch einen eigenen Platz bekommen und sichtbar bleiben.
