Wenn ich versuche, ein Website-Problem zu lösen, habe ich viele Gelegenheiten, die KT-Problemanalyse sowie das IS/IS-NOT-Denken anzuwenden.
In diesem kurzen Artikel geht es um Fehlermeldungen und darum, warum sie 1) irreführend sind und 2) keine Problembeschreibung darstellen!
Hinweis: Dieses Problem trat vor einiger Zeit auf, und die Details wurden für die Zwecke dieses Artikels vereinfacht und präzisiert.
Das Szenario
Es gibt eine bestimmte Website, die ungenannt bleiben soll (ähem), in die Formulare eingebettet sind, die im Wesentlichen von einer anderen Seite stammen: Pardot, einer Marketing-Automation-Plattform. Außerdem gibt es verschiedene Versionen dieser Formulare in unterschiedlichen Sprachen. Welches Formular auf welcher Website angezeigt wird, wird durch Code bestimmt, der besagt: „Wenn die Sprache dieser Website X ist, zeige dieses Formular an“.
Bis hierhin alles gut.
Das Problem
Eines Tages erschien beim Aufrufen bestimmter Seiten an der Stelle, an der das Formular hätte sein sollen, folgende Fehlermeldung:
Was bedeutet das? Auf den ersten Blick bedeutet es, dass der Server von Pardot einen Fehler hatte und die Verbindung verweigert hat.
Aber ergibt das Sinn?
Problemspezifikation und -analyse
Beim Blick auf einige Formulare auf den verschiedenen Websites (siehe Tabelle unten) wurde eines absolut klar: Wenn der Pardot-Server wirklich schuld gewesen wäre, wäre es der größte Zufall aller Zeiten, dass die Formulare B und C zufällig alle auf demselben Pardot-Server liegen. Oder? Wissen und Erfahrung sagen uns, dass das völlig unsinnig ist:
| Formular A | Formular B | Formular C | |
|---|---|---|---|
| Englisch (US) | OK | OK | OK |
| Englisch (GB) | OK | Fehler | Fehler |
| Deutsch | OK | Fehler | Fehler |
| Niederländisch | OK | Fehler | Fehler |
| Französisch | OK | Fehler | Fehler |
Die nächste Frage war also: „Was stimmt mit den ‚lokalsprachlichen‘ Versionen der Formulare B und C nicht?“
Liegt es am Formular?
Es war einfach genug, den HTML-Code der Formulare in einen Textblock auf einer brandneuen Seite einzufügen. Wenn man es so macht, gibt es keinen ausgefeilten Code; man bettet einfach das eine Formular ein, das man verwenden möchte.
Beim Testen der Formulare auf diese Weise funktionierten sie alle einwandfrei. Damit haben wir eindeutig bewiesen, dass mit den in Pardot erstellten Formularen nichts nicht stimmte.
Wahre Ursache
Als Nächstes war daher der Code auf den Website-Seiten selbst zu prüfen.
Der Übeltäter entpuppte sich als ein zusätzliches Leerzeichen in der Formular-URL!
Wenn Sie sich fragen, warum dasselbe Formular auf der Website Englisch (US) (der Haupt-Website) funktionierte: Das lag an der Position des zusätzlichen Leerzeichens. Es befand sich zwischen der URL des Formulars und der Seiten-URL, etwa so (das Leerzeichen steht direkt vor dem „?“):
https://go.kepner-tregoe.com/l/12345566554 ?Page_URL
Das ist der Grund, warum der Fehler nur auftrat, wenn eine bestimmte Seiten-URL angegeben wurde.
Vielleicht denken Sie auch: Warum endete der Link nicht, wenn man die Leertaste drückt? In Microsoft Word passiert das, aber ein Code-Editor lässt Sie dieses Leerzeichen einfügen, ohne sich zu beschweren (ich musste das testen, weil ich nicht sicher war, ob ich mich richtig erinnere).
Wie auch immer: Rätsel gelöst. Hätten wir der Annahme vertraut, dass mit dem Pardot-Server etwas nicht stimmt, hätten wir Zeit und Energie verschwendet, indem wir ein Ticket bei Pardot eröffnet und sie eine Nicht-Problematik hätten untersuchen lassen.
Fazit: Fehlermeldungen sind nichts weiter als ein Signal, dass etwas nicht stimmt – sie sind nicht die Grundlage für eine echte Problemformulierung und nicht immer ein Hinweis auf oder ein Abbild des zugrunde liegenden Problems.
