Sechs Fehler beim Umbau der eigenen Website
Wir haben diese Seite mit KI-Unterstützung neu gebaut. Was dabei schiefging, lag selten am Modell — sondern fast immer an Stellen, an denen niemand vorher festgelegt hatte, was richtig heißt.
Diese Website ist in weiten Teilen mit KI-Unterstützung entstanden. Das ist keine Besonderheit mehr, aber es macht die Fehlerliste interessant: Sie zeigt, welche Art von Fehler dabei entsteht und welche nicht.
Sechs davon haben wir aufgeschrieben. Alle sind in der Versionsgeschichte nachlesbar.
Eins: Ein Aufräumskript löschte Regeln, die im Betrieb gebraucht wurden
Nach dem Umbau lagen tote Gestaltungsregeln herum. Ein Skript suchte nach Klassennamen, die im Code nicht vorkommen, und entfernte sie.
Es entfernte auch Regeln, die sehr wohl gebraucht wurden. Der Grund: Ein Teil der Klassennamen entsteht erst zur Laufzeit, zusammengesetzt aus einem festen Anfang und einem variablen Ende. Im Quelltext steht nirgends der vollständige Name. Statische Suche findet ihn nicht.
Aufgefallen ist es nicht beim Lesen des Codes, sondern beim Vergleich zweier Bildschirmfotos vor und nach dem Aufräumen. Die Regeln kamen zurück, mit einem Kommentar, der erklärt, warum sie tot aussehen und es nicht sind.
Zwei: Verbindungslinien mit einprogrammiertem Winkel
Im Glossar gibt es eine Karte verwandter Begriffe: ein Zentrum, außen herum die Nachbarn, dazwischen Linien.
Die Linien waren als Gestaltungselemente mit fester Länge und fest eingetragenem Drehwinkel gebaut. Achtundsiebzig Grad hier, dreizehn Grad dort. Diese Werte stimmten für genau eine Fenstergröße, nämlich die, an der jemand sie eingestellt hatte. Auf dem Telefon ist der Kasten schmal und hoch statt breit. Dieselben Winkel zeigen dann ins Leere.
Es war nie ein Layoutproblem. Ein Zentrum und höchstens fünf Nachbarn ergeben eine Anordnung, die man ausrechnet: Polarkoordinaten, ein gemeinsamer Bezugsrahmen für Knoten und Linien, fertig. Der Fehler bestand darin, ein geometrisches Problem als Gestaltungsproblem zu behandeln und die Werte zu schätzen, bis es aussah wie beabsichtigt.
Drei: Ein abgeschnittener Selektor
Im dunklen Seitenfuß hatten zwei Spaltenüberschriften plötzlich einen hellen Balken hinter sich.
Die Ursache war eine unvollständige Regel. Eine Aufzählung von Selektoren brach mitten im letzten Eintrag ab, ein Kommentar folgte, dann begann die nächste Regel. Und der Browser las beides als einen Zusammenhang. Die Fußüberschriften bekamen dadurch die Hintergrundfarbe, die für einen ganz anderen Seitenbereich gedacht war.
Der Fehler stand seit Wochen im Code. Er ist beim Lesen kaum zu sehen, weil er wie ein Zeilenumbruch aussieht. Auf einem Bildschirmfoto sieht man ihn sofort.
Vier: Text mit 1,37 zu 1
Im dunklen Bereich der Seite steht über jedem Abschnitt eine kleine Zeile. Ihre Farbe war einmal für dunkle Hintergründe festgelegt worden. Einige Abschnitte sind aber hell.
Auf dem blassen Blau ergab das ein Kontrastverhältnis von 1,37 zu 1. Die Anforderung für kleine Schrift liegt bei 4,5 zu 1. Die Zeile war praktisch unsichtbar, und zwar seit dem Tag, an dem der helle Abschnitt hinzukam.
Gefunden wurde sie nicht im Entwurf, sondern von einem Skript, das über jede Seite läuft, Vorder- und Hintergrundfarbe jedes Textelements ausliest und das Verhältnis ausrechnet. Der erste Durchlauf fand elf Stellen. Danach war die Frage nicht mehr, ob etwas zu blass ist, sondern nur noch, welche Farbe stattdessen.
Fünf: Symbole von der falschen Adresse
Das Browser-Symbol der Seite wurde von einer Domain geladen, auf der es nichts zu holen gab.
Der Grund liegt in einer Bequemlichkeit des Frameworks: Es rechnet Pfade gegen eine hinterlegte Basisadresse absolut. Diese Basisadresse war ein Platzhalter, weil die endgültige Domain noch nicht feststand. Für Vorschaubilder in sozialen Netzwerken ist die absolute Form richtig. Für ein Symbol, das immer von der eigenen Seite kommt, ist sie falsch.
Bemerkt haben wir es beim Mitschneiden aller Netzwerkanfragen. Dieselbe Messung, mit der wir für die Datenschutzerklärung geprüft haben, ob die Seite fremde Server anspricht.
Sechs: Ein Bild, das seine Höhe nicht ableitet
Beim Umbau des Aufmachers sollte ein Bild einen Kasten füllen. Oben und unten festgelegt, links und rechts festgelegt. Das genügt bei den meisten Elementen, um die Höhe zu bestimmen.
Bei Bildern genügt es nicht. Sie gehören zu einer Sorte Element, deren Größe aus dem Inhalt kommt; die Angaben oben und unten leiten dort keine Höhe ab. Das Bild blieb auf seiner Ursprungshöhe stehen und wurde vom Kasten beschnitten.
Auffällig wurde es erst, als wir die tatsächlichen Maße auslasen: 662 mal 1024 Bildpunkte, wo 662 mal 442 sein sollten. Vorher hatten wir drei Runden lang an der falschen Stelle gesucht.
Was die Liste gemeinsam hat
Kein einziger dieser Fehler ist ein Denkfehler. Es ist keine Stelle darunter, an der eine falsche Schlussfolgerung gezogen wurde.
Es sind ausnahmslos Stellen, an denen niemand vorher festgelegt hatte, was richtig heißt. Solange „sieht gut aus" das Maß ist, findet man Fehler nur, wenn man zufällig hinsieht. Und zwar auf dem Gerät, in der Fenstergröße und bei der Sehstärke, bei der der Fehler auffällt.
Sobald es eine Messung gab, waren die Fehler in Minuten gefunden. Der Kontrastlauf fand elf Stellen im ersten Durchgang. Die Überlaufprüfung fand fünf Seiten, die sich seitlich verschieben ließen. Das Auslesen der Bildmaße beendete eine Suche, die drei Runden gedauert hatte.
Die Arbeit steckte nicht im Beheben. Sie steckte darin, das Maß zu formulieren.
Das ist auch die Übertragung auf alles andere, was wir mit diesen Systemen bauen. Ein Modell kann eine Regel schreiben, eine Grafik entwerfen, einen Text formulieren. Was es nicht kann, ist entscheiden, woran man erkennen soll, dass das Ergebnis stimmt. Diese Entscheidung ist keine technische Nacharbeit. Sie ist der eigentliche Entwurf. Und sie bleibt bei den Menschen, die mit den Folgen leben.