Ein Dashboard wäre schön — erste Skizze

Zum Jahresende hatte der Bot ungefähr fünfundvierzig Befehle und zwölf Einstellungen pro Server. Die Einstellungen wurden per Chat gesetzt:

!config prefix ?
!config willkommen #ankuenfte
!config levelup dm
!config sprache de

Das funktioniert, solange man weiß, welche Schlüssel es gibt. Und genau da fing das Problem an: Jede zweite Frage in meinem Support-Kanal war „wie stelle ich X ein". Nicht, weil die Leute es nicht konnten, sondern weil ein Chatbefehl nichts anzeigt. Man sieht nicht, welche Einstellungen es gibt, welche gesetzt sind, welche Werte erlaubt sind.

Was eine Oberfläche eigentlich löst

Mir war beim Aufschreiben klar geworden, dass es um drei verschiedene Dinge geht, die man leicht durcheinanderbringt.

Sichtbarkeit. Eine Liste aller Einstellungen mit aktuellem Wert. Das allein hätte die Hälfte der Fragen erledigt.

Gültigkeit. Ein Formularfeld für einen Kanal kann eine Auswahl aus vorhandenen Kanälen sein. Man kann gar nicht mehr eine ID eintippen, die es nicht gibt. Bei Chatbefehlen prüft man das nachträglich und meldet Fehler — in einer Oberfläche verhindert man sie vorher.

Berechtigung. Wer darf die Einstellungen eines Servers ändern? Im Chat ist das einfach, weil Discord schon weiß, wer da schreibt. Im Web muss ich es selbst herausfinden — und das ist der Teil, den ich damals gnadenlos unterschätzt habe.

Die Skizze, die ich Ende 2020 gemacht habe

Auf Papier sah der Plan simpel aus:

1. Nutzer meldet sich mit Discord an.
2. Wir holen seine Server.
3. Wir zeigen die, auf denen der Bot ist und der Nutzer Verwaltungsrechte hat.
4. Er klickt einen an und sieht die Einstellungen.
5. Er ändert etwas, wir schreiben es in die Datenbank, der Bot liest es beim nächsten Mal.

Fünf Punkte. Ich habe geschätzt, dass das ein Wochenende dauert. Es hat Monate gedauert, und jeder einzelne Punkt hatte eine Falle, die ich nicht kommen sah.

Punkt 2 und 3. Die Server-Liste, die man über die Anmeldung bekommt, enthält Berechtigungsangaben — aber sie sind ein Schnappschuss aus dem Moment der Anmeldung. Wenn jemandem die Rechte danach entzogen werden, steht in seiner Sitzung immer noch, dass er darf. Wer das nicht prüft, hat eine Rechteprüfung gebaut, die auf veralteten Daten beruht.

Punkt 5. „Der Bot liest es beim nächsten Mal" klingt harmlos und ist eine ganze Architekturfrage. Liest er bei jeder Nachricht aus der Datenbank? Das sind hunderte Abfragen pro Minute. Hält er einen Zwischenspeicher? Dann muss ihm jemand sagen, wenn sich etwas geändert hat. Und wie sagt eine Webseite einem Bot-Prozess, dass er etwas neu laden soll?

Was ich mir bewusst nicht vorgenommen habe

Beim Skizzieren habe ich zwei Dinge ausdrücklich gestrichen, und beide Entscheidungen halte ich bis heute für richtig.

Kein Live-Chat im Dashboard. Es gab die Idee, Servernachrichten in der Weboberfläche anzuzeigen. Das ist technisch machbar und war mir sofort unangenehm: Eine Weboberfläche, die den Chatverlauf eines fremden Servers anzeigt, ist etwas ganz anderes als ein Bot, der Befehle beantwortet. Der Vertrauensbedarf steigt enorm, der Nutzen ist gering.

Kein Ersatz für Discords eigene Verwaltung. Rollen, Kanäle, Berechtigungen — dafür gibt es Discords Oberfläche, und die ist besser als alles, was ich bauen würde. Mein Dashboard sollte nur das können, was den Bot betrifft.

Beides sind Beispiele für eine Regel, die ich mir irgendwann angewöhnt habe: Beim Planen ist die Liste dessen, was man nicht baut, oft wichtiger als die andere.

Was ich mir beim Skizzieren aufgeschrieben habe

Aus der Planungsphase ist eine Liste von Fragen geblieben, die ich seitdem bei jeder Oberfläche durchgehe, bevor der erste Entwurf entsteht.

Wer benutzt das, und wie oft? Ein Werkzeug, das jemand täglich benutzt, darf Einarbeitung verlangen. Eines, das jemand zweimal im Jahr anfasst, muss sich selbst erklären.

Was ist der häufigste Vorgang? Bei einem Bot-Dashboard ist das nicht „alles konfigurieren", sondern „eine einzelne Einstellung ändern". Der häufigste Vorgang bestimmt den Aufbau — er sollte ohne Umwege erreichbar sein.

Was passiert bei einem Fehler? Nicht nur technisch, sondern für den Menschen davor: Sieht er, dass etwas schiefging? Weiß er, ob seine Änderung gespeichert wurde?

Was ist der gefährlichste Vorgang, und wie schwer ist er auszulösen? Alles, was Daten löscht oder Zugriffe entzieht, sollte mehr als einen Klick brauchen.

Der Teil, den ich später falsch gebaut habe

Es gibt eine Entscheidung aus dieser Skizze, die ich später bereut habe: Ich hatte geplant, dass die Oberfläche nach jeder Änderung eine Erfolgsmeldung zeigt.

Das habe ich gebaut — und dann in der ersten Fassung an einer Stelle vergessen, an der eine Aktion still fehlschlagen konnte. Jahre später ist mir genau dieses Muster in einem anderen Panel wieder begegnet, mit deutlich unangenehmeren Folgen: Aktionen, die nichts taten und keinen Fehler zeigten, sind wochenlang unbemerkt geblieben.

Die Lehre, die ich daraus gezogen habe, ist strenger als „Erfolgsmeldungen einbauen": Eine Oberfläche muss drei Zustände darstellen können — läuft, erfolgreich, fehlgeschlagen. Zwei reichen nicht, weil dann „läuft noch" und „hat nicht funktioniert" gleich aussehen. Und der Fehlerzustand braucht Text, keine Farbe.

Der Stand zum Jahreswechsel

Am 31. Dezember 2020 existierte von diesem Dashboard genau nichts außer einer Textdatei mit Notizen und ein paar Skizzen auf kariertem Papier. Kein Code, kein Repository, kein Framework ausgewählt.

Und trotzdem war das Nachdenken die Zeit wert, weil die Fragen sich nicht geändert haben, als es dann losging. Wer darf was ändern, wie kommt die Änderung zum Bot, was passiert bei widersprüchlichen Ständen — das waren im Januar dieselben Fragen wie im Dezember. Nur dass ich sie zu dem Zeitpunkt schon einmal durchdacht hatte.