Warum HTML/Browser/Web nerven, Teil 1

Die Debatten über Web-Anwendungen vs. Fat-Client-Software werden so schnell nicht enden, aber eigentlich ist es auch müßig, sich darüber zu streiten. Denn Fakt ist einerseits: Die Plattform- und Ortsunabhängigkeit von Web-Anwendungen zählt zu den größten Leistungen in der IT-Geschichte. Auch in mir hat sich vor über 10 Jahren, seit meinen ersten Web-Kontakten, die Hoffnung festgesetzt, dass ich bald nicht mehr mit meinen Daten und Programmen an feste Client gebunden sein werde. Fakt ist aber leider auch, …

… dass einige essentielle Grundprinzipien von gutem Softwaredesign und Usability im HTML-Umfeld bis heute nicht ansatzweise gelöst sind.

Aktuelles Beispiel: Ich möchte auf einem Blog einen Kommentar absetzen, Tippe im Editor-Feld (Editor??) meinen Sermon, werde aber durch ein Telefonat unterbrochen. Abgelenkt öffne ich weitere Programm- und Browser-Fenster, vergesse den Kommentar und schließe in der Folgezeit wegen des Fensterchaos am Desktop wieder diverse Browserfenster – u.A. das mit dem halbfertigen Kommentar.

Kommt irgendeine Warnung, Fehlermeldung, ein dezenter Hinweis? Natürlich nicht, aber was interessiert mich mein Gescheibsel von vor 10 Minuten… 8-/

Das Beispiel zeigt, dass das Web immer noch ein erbärmliches Anwendungsfrontend ist, in dem nicht einmal die grundlegendsten Fehlerbehandlungsroutinen moderner GUI-Software zum Einsatz kommen. (Wie denn auch, wenn HTML derart bescheindene Mechanismen bereitstellt.)

Fazit: Einer Sache ist nicht gedient, wenn man sie immer nur an ihren guten Ideen und Absichten misst. Wenn man nicht konsequent den Finger in die vielen großen Wunden des Web legt, geht dieses Gewurschtel auch die nächsten 13 Jahre so weiter. Aufklärung tut also not, deshalb werden hier weitere abschreckende Beispiele folgen …

3 Kommentare » Schreibe einen Kommentar

  1. Was hat HTML denn mit dem o. g. Problem zu tun? Das ist doch Aufgabe des Interfaces, und das erzeugt der das HTML darstellende Browser.

  2. @Sascha: HTML ist für Millionen von Entwicklern ganz einfach eine „Programmiersprache“, die in Verbindung mit angeflanschten Standards zum Erstellen von GUI und Logik von Anwendungen verwendet wird.

    @Wolfgang: Ich weiß nicht, was du bei Gmail meinst. Wenn ich in Gmail eine Mail tippe und versehentlich auf den (x)-Button des Browsers klicke, verschwindet alles ohne Warnung im Orkus. Wenn ich die gleiche Aktion in Outlook (oder jedem anderen Fat-Client) bringe, kommt der kleine, aber entscheidende Warnhinweis „Möchten Sie die Änderungen speichern?“.

  3. @Wolfgang S.
    Das Gmail-Beispiel zeigt, wie rückständig HTML-basierte Webanwendungen tatsächlich sind. Ist so ein banales Feature überhaupt der Rede wert? Im Falle von Webanwendungen offenbar schon. Solche Funktionen hatten schon die ersten DOS-Anwendungen. Wie Du richtig feststellst, ist CSS etwas für Entwickler. Da liegt der Hase im Pfeffer. An einfache Anwender wurde bei diesem Standard faktisch nicht gedacht. Offenbar ist es gar nicht so einfach, vernünftige WYSIWYG-Editoren dafür zu bauen. Für Leute, die einfach nur Webseiten erstellen wollen, aber mit dem Programmieren nichts am Hut haben (und das ist die Mehrheit), ist vieles bei CSS mehr oder weniger uninteressant. Das ist vermutlich auch der Grund, warum sich die kleine Softwareschmiede, die immer nur den Massenmarkt im Auge hat, nie sonderlich dafür interessiert hat.

    @Sascha
    Es geht bei Wolfgangs Beispiel vor allem darum, welche Möglichkeiten HTML in Bezug auf Webanwendungen bietet. Und die sind äußerst bescheiden, wenn man das mit modernen Client-Server-Anwendungen vergleicht. Der Grund dafür ist, dass HTML und das ultraprimitive Javascript kaum Möglichkeiten für eine eine vernünftige Oberfläche im Frontend bieten. Das ist der Punkt, wo .Net und Java ins Spiel kommen. Wobei Letzteres sich in diesem Bereich auch nicht gerade mit Ruhm bekleckert hat.