muss das Web zur Applikation kommen, oder: Warum Web-Applikationen nicht funktionieren.

Vor einiger Zeit glaubte man, die Ära der Programme sei vorbei. Schliesslich würde man in kurzer Zeit alles direkt im Internet machen, im Browser. Und in der Tat begannen in kurzer Zeit überall Intranets zu blühen, die verschiedenste Desktop-Applikationen ersetzen sollten. Ganze Aufgaben-, Projekte- und Adressverwaltungen wurden auf Servern platziert und mit HTML-Front-Ends versehen. Nicht zuletzt wurde mit diesen Web-Applikationen auch der «Browser-War» kräftig angeheizt, wurden doch oft proprietäre Tags eingesetzt, um bestimmte Verhalten zu erreichen, die dann natürlich nicht mit anderen Browsern kompatibel waren. Der Grund, warum noch heute IE in vielen Firmen weit verbreitet ist, lässt sich durch die Tatsache erklären, dass dieser für das Funktionieren von gewissen Webapplikationen vom IT-Department verordnet wurde.

Dieses Essay ist ein Versuch zu begründen, warum diese scheinbar so praktischen Lösungen nicht nur ein sicherheitstechnisches, sondern vor allem auch ein Problem bezüglich der User Experience sind – und welcher Weg sich anbietet, trotzdem Informationen für alle von überallher anzubieten.

Vor allem für Entwickler scheinen Web-Applikationen vorteilhaft zu sein:

• einfachere Entwicklung¹
• keine Installation auf der Client-Seite nötig²
• Updates sind nur auf dem Server nötig

Diese Vorteile wirken sich jedoch gleichzeitig negativ auf die Benutzung aus. Denn ein Browser kann nun einmal nicht die reiche Oberfläche simulieren, die ein Betriebssystem bietet.

Beschränkungen

Sicherheitsrisiken

Ich würde sagen, es ist nicht übertrieben zu sagen, dass sämtliche Daten, die auf einem Server, der nicht komplett vom Internet isoliert ist, potentiell gefährdet sind. Angesichts der Tatsache, dass sogar äusserst alte und als «sicher» abgesehene *nix-Systeme immer wieder Sicherheits-Updates benötigen, sollte klar sein, dass die meisten Web-Applikationen, die ja meist in wesentlich kürzerer Zeit entwickelt wurden, zumindest potentiell mehr Lücken aufweisen.

Gleichzeitig ist es für den Anwender der Applikation unmöglich, zu prüfen, ob die Applikation sicher ist. Die Tatsache, dass auf dem boomenden IT-Feld viele selbsternannte Experten zu finden sind, die auf der Suche nach dem schnellen Geld sind, und dies mit schlampig zusammengeschusterten Lösungen zu überteuerten Preisen zu erreichen versuchen, macht die Sache auch nicht einfacher. Im Gegenteil. Zu Beginn des August meldete Heise, dass

bei der Sicherheitsfirma MyChannel eine Datei mit einer Kundenliste offen zugänglich im Web lag. Sie enthielt unter anderem Kreditkartennummern. Die URL zu der Datei wurde in diversen IRC-Foren veröffentlicht, bevor diese vom Netz genommen wurde.

Die Firma MyChannel bezeichnet sich selber als Internet-Sicherheitsfirma, dessen Besitzer tritt in den Medien als Sicherheitsexperte auf.

Das Problem ist ja nun schon einige Zeit bekannt, doch noch immer tauchen immer wieder ähnliche Meldungen von Kreditkartennummern-Raubzügen auf. Zwei Schlüsse sind möglich: IT-Experten haben das Risiko noch immer noch nicht kapiert, oder die Cracker sind einfach besser. Wenn letzteres der Fall ist: kann man das Risiko wagen?

Reduziertes Toolset

Die beiden Bilder sind nur ein Ausschnitt aus der ziemlich grossen Palette an «Widgets», die Mac OS X anbietet. Was bietet HTML? Nicht sehr viel: Ein Eingabe-Feld, ein Button, Options-Felder. Das war’s. Und damit soll nun eine Applikation gemacht werden?

Es gibt Entwickler, die daran glauben. Zwar bin ich durchaus auch nicht der Meinung, dass eine möglichst grosse Anzahl an verschiedenen Knöpfen ein Interface besser macht (Windows ist, wie so oft in Sachen Interface-Design, das Paradebeispiel dafür). Wenn jedoch Apple all diese Formen einführt, so hat dies durchaus seine Gründe: jedes dieser Bildschirmelemente reagiert anders. Um dem Benutzer eine Hinweis darauf zu geben, was passiert, wenn er ein bestimmtes Objekt manipuliert, sind sie unterschiedlich gestaltet.

Mit HTML ist dies nicht möglich. Es existieren ein paar wenige Objekte, die auf jeder Website ein wenig anders reagieren. Ein Beispiel gefällig? Da gibt es die bekannten «Jump»-Menüs, Pop-Up-Menüs, die eine Art verkürzte Sitemap bieten. Wählt man eine Option aus, so springt man bei einigen Sites direkt auf die ausgewählte Page (und wenn es nun die falsche war? Jeder mit Laptop und Trackpad wird ein Lied von solchen Fehleingaben singen können …) oder aber es passiert gar nichts, weil zuerst der GO-Button nebendran geklickt werden muss. Bei beiden Varianten sehen die Menüs aufs Haar gleich aus, und nichts gibt mir einen Anhaltspunkt, wie das Menu auf einer bestimmten Site reagieren wird – vor allem auch darum, da selbst bei der ersten Variante ein GO-Button daneben platziert ist, sollte Javascript nicht aktiviert sein.

Dasselbe bei den Submit und Reset Buttons: während der Submit-Button effektiv eine Verbindung zum Server erstellt und Daten mit dem Server austauscht, tut der Reset-Button nichts dergleichen. Und trotzdem sehen sie gleich aus.³

Gleichzeitig stellt sich auch das Problem der Plattformunabhängigkeit. Natürlich: eine Web-Applikation läuft (im Idealfall) auf allen Browsern auf allen Systemen. Aber auf welchen Metaphern, Verhaltensweisen baut sie auf? Mac OS X benutzt andere Paradigmen als MS Windows. So basiert viel Datenmanipulation auf der Mac-Plattform auf Drag-and-Drop, eine Technik, die zwar auch von Windows zwischendurch mal verwendet wird, aber bei weitem nicht so konsequent und komfortabel wie beim Mac. Dieses Verhalten im WWW zu simulieren ist durchaus möglich, wie die Website von Panic beweist, aber werden Benutzer, die Windows gewohnt sind, damit zurechtkommen? Dasselbe gilt auch umgekehrt: werden Mac-User Windows-spezifisches Verhalten einleuchtend finden?

Das ganze wird noch kritischer, als dass viele Webbrowser die Widgets des Betriebsystems, in dem sie ausgeführt werden, benutzen. Auf Mac OS X sehe ich in Safari die bekannten Aqua-Buttons; auf Windows in IE sehe ich dieselben Objekte im Windows-Stil (Luna, anyone?). Wer würde nicht erwarten, dass diese Objekte auch das Verhalten zeigen, das sie ansonsten quer durch die gesamte Oberfläche haben?

Das Beispiel des Jump-Menüs von oben beweist eindrücklich, dass dem eben gerade nicht so ist. Pop-Up-Menus sind da, laut der Apple-Spezifikation

[…] to present a list of mutually exclusive choices in a dialog or window. Pop-up menus are used as a means of selecting one choice from a list of many. If you have a dialog with a set of six or more radio buttons, consider using a pop-up menu instead. [A pop-up menu] Contains nouns (things) or adjectives (states or attributes), but not verbs (commands); use pull-down menus for commands.

Ist nun das Jump-Menu so programmiert, dass es direkt auf die ausgewählte Page springt, so ähnelt dieses Verhalten einem Befehl, der ausgewählt wird – und damit ist das Pop-Up Menu nicht geeignet dafür. Bloss: in der HTML-Spezifikation gibt es keine Pull-Down Menus. Das scheint nun arg nach Korinthenkackerei zu riechen, gehört aber genau zu jenen Fällen, die in den Benutzern ein undefinierbares Gefühl von «das ist irgendwie nicht richtig» hinterlassen. Das ist bei den Produkten von MS fast durchwegs so, aber das heisst nicht, dass damit ein weiterer Quasi-Standard zum Mass aller Dinge erhoben werden sollte …

No Push – fehlendes Feedback

In den Apple Software Design Guidelines steht es unter den wichtigsten Prinzipien: Feedback.

Keep users informed about what’s happening by providing appropriate feedback. When a user initiates an action, provide an indication that your application has received the user’s input and is operating on it.

Users want to know that a command is being carried out. If a command can’t be carried out, they want to know why it can’t and what can be done instead. When used sparingly, animation is one of the best ways to show a user that a requested action is being carried out. For example, when a user clicks an icon in the Dock, the icon bounces to let the user know that the application or document is in the process of opening.

For potentially length operations, use a progress indicator to provide useful information about how long the operation will take. Users don’t need to know precisely how many seconds an operation will take, but an estimate is helpful. For example, Mac OS X uses statements such as “about a minute remains” to indicate an approximate time frame. It can also be helpful to communicate the total number of steps needed to complete a task—for example, you might include text that says “Copying 30 of 850 files.”

Feedback in vielfältigster Form gehört zum wichtigsten Paradigma von GUIs: Der Benutzer soll immer gleich sehen, was für Auswirkungen seine Aktionen haben. Das setzt voraus, dass ein ungebrochener Fluss an Information besteht: Die Eingaben des Benutzers müssen sofort verarbeitet werden und gleich wieder zurück gesendet werden. Das WWW hat dies aber nie unterstützt: nachdem eine Anfrage an den Server gesendet worden ist, wird die gewünschte Seite gesendet und die Verbindung wieder geschlossen. Kontinuierliche Interaktion ist damit nicht möglich.⁴

Die meisten werden den klassischen Fall kennen: Man ist in einem Internet-Forum, schreibt einen Artikel und klickt auf Absenden. Doch – nichts geschieht. Man wartet ein wenig, und klickt dann noch mal auf Absenden. Nun endlich wird eine neue Page geladen, die die Aktion bestätigt. Sieht man sich aber nochmal das Forum an, wird man sehen, dass der Beitrag zweimal gepostet worden ist. Der Punkt ist klar: Vom unserer normalen Arbeit mit Desktop-Programmen sind wir gewöhnt, dass wir auf unsere Aktionen sofort ein Feedback bekommen. Bei der Forums-Anwendung ist dies nicht, bzw. erst verspätet geschehen: der Eintrag wurde zwar in der Datenbank vorgenommen, dem Benutzer wurde dies aber nicht bestätigt. Wenn ich in einer Desktop-Applikation auf einen Button klicke, und nichts geschieht, kann das nicht sehr viele Ursachen haben:

• Ich habe den Button mit der Maus nicht erwischt.
• Das Programm ist abgestürzt.

Wieviele Möglichkeiten gibt es doch in der selben Situation bei einer Web-Applikation!

• Ich habe den Button mit der Maus nicht erwischt.
• Mein Modem ist ausgefallen.
• Der Browser ist abgestürzt.
• Mein Bruder lädt irgendwas riesengrosses runter und legt das Netz lahm.
• Mein Provider hat eine Störung.
• Der Server, auf dem die Applikation läuft, ist ausgefallen.
• Ich bin in China.
• Der Prozess ist auf dem Server noch in Arbeit.

Bei einer Mehrzahl dieser Gründe bekomme ich gar keine Feedback, mal abgesehen von der Tatsache, dass ich merke, dass «es» nicht funktioniert. Ich habe nicht einmal die Möglichkeit, irgend einen Einfluss darauf zu nehmen. Auch im letzten Fall, wenn der Server eine langwierige Arbeit zu bewältigen hat, werde ich nicht über deren Stand informiert. Das WWW beherrscht das «Push» nicht: der Server kann mir von sich aus keine Meldung schicken, zum Beispiel, wenn ein Task beendet ist. Was bleibt, sind Meldungen, die freundlich darauf hinweisen, dass es längern dauern könnte und ein Benutzer, der alle 5 Sekunden auf den Reload-Button klickt. Wie eigenartig würde es uns scheinen, wenn wir in unseren Betriebssystemen immer auf einen Button klicken müssten, um zu wissen, was unser Computer gerade so tut. Aber auf dem WWW gehört dies zur Tagesordnung …

Wenn nicht einmal eines der grundlegenden Konzepte von GUIs zufriedenstellend implementiert werden kann, wie soll man dann eine web-basierte Applikation machen? Es wird höchstens eine Emulation sein – mit all den Problemen, die dieser Begriff impliziert: Komplikationen, Ungereimtheiten, Inkonsistenz.

Wenn die Appplikation nicht zum Web will …

… muss man das Web zur Applikation bringen. Dass ein Bedarf da ist, Daten auf Servern zu speichern, auf die danach von überall her zugegriffen werden kann, ist unbestritten. Doch wie die oberen Begründungen zeigen, bietet HTML ein zu geringes Toolset, um das wirklich funktionieren zu lassen. Kein Wunder, müssen dann Plugins herhalten, die diese Funktionalitäten ersetzen sollen. (Natürlich erübrigt sich damit gleichzeitig auch gleich das Argument, man brauche keine Installation auf der Client-Seite …). Eine solche Möglichkeit präsentierte Macromedia im März 2003 auf ihrer eigenen Website.

macromedia.com 2003 – Ein Versuch

Bei macromedia hatte man erkannt, dass HTML nur begrenzte Möglichkeiten zur Interaktion bietet:

Often times, the “page paradigm” of today’s web is inappropriate for the tasks it supports. As an alternative to current web applications, Rich Internet Applications offer the ease of use more typical of a desktop application. In certain areas of the site, we felt that freedom from the limitations imposed by HTML would greatly improve the execution of:

• Filling out logic-driven forms, where an answer to one question can determine a set of options for the next.
• Browsing and searching for content within a large library, especially when sorting and filtering are important.
• Navigating a deep hierarchy.

Mit «Rich Internet Applications» waren im Grunde in Pages eingebettete Flash-Files gemeint, die die Aufgaben, die HTML nicht erfüllen konnte, übernehmen sollten. Der Artikel von Jerry Knight auf macromedia.com listet dabei ziemlich genau die Probleme von Web-Applikationen auf, und wie sie in dieser Beta mit Flash gelöst wurden.

Es ist jedoch zu bemerken, dass die Lösungen, so innovativ sie auf den ersten Blick auch scheinen mögen, nicht sehr lange überlebt haben: inzwischen ist macromedia.com Standards-kompatibel, und die Formulare basieren wieder auf reinem HTML. Welche Gründe gibt es dafür?

• Viele dieser Flash-Lösungen funktionierten nicht ohne das aktuellste Flash-Plugin. Längst nicht alle Leute halten sich an die Empfehlungen und laden es herunter. Für sie alle waren die Neuerungen nicht erreichbar.
• Flash-Files sind zwar nicht sehr gross, haben aber immer noch länger zum laden als HTML. Was immer man auch machte – die Leute beklagten sich, die Site reagiere nur langsam, man müsse immer wieder warten. Selbst wenn es nur psychologisch ist (für viele stehen Flash-Files für lange Wartezeiten), ein schlechtes Image bekommt eine Website trotzdem.
• Macromedia führte für ihre Website wiederum neue Widgets ein, eine zweischneidige Entscheidung: auf der einen Seite evoziert man damit keine Erwartungen an das Verhalten, die dann, wie oben gesehen, nicht erfüllt werden; andererseits können sie auch verwirren, da sie ungewohnt sind und ihre Funktion nicht klar ersichtlich ist.

Selbst wenn es ein mutiger Versuch war, so zeigt es doch das Dilemma: Man muss eine eine «HighTech»-Applikation (das Flash-File) in eine «LowTech»-Umgebung (HTML / WWW) einbinden, die wiederum in einer «HighTech»-Umgebung (dem Betriebssystem) eingebettet ist. Warum dieser Umweg?

iTunes – Die Reinvention des Browsers

Wenn man spezielle Daten hat, die zu präsentieren mit HTML schwierig wären, warum nimmt man nicht einfach eine angepasste Lösung? Zu lange habe Entwickler versucht, ihre Daten und Routinen in das enge Korsett von HTML zu zwängen. Die Lösung sieht anders aus, und sie ist inzwischen auf Millionen von Computern installiert: [iTunes].

iTunes kombiniert auf geniale Weise zwei Welten: die der Desktop-Applikation und die der Web-Applikation. Statt die Applikation in das Web zu bringen, wird das Web in die Applikation geholt – und das praktisch nahtlos: es besteht kein Unterschied in der Bedienung, ob ich jetzt auf meiner eigenen, lokal abgespeicherten Musik-Bibliothek suche und stöbere oder im Music Store. Die Stücke im Music Store sind einfach Lieder die ich (noch) nicht besitze. Damit wird iTunes zum hochspezialisierten Browser, genau zugeschnitten auf die Bedürfnisse des Music Stores und damit natürlich relativ ballastfrei.

Indem iTunes als normale Desktop-Applikation erscheint, kann sie von all den Vorteilen profitieren, die ein Betriebssystem bietet: Einbindung zu anderen Programmen, ein anständiges Interface, das dem jeweiligen Betriebssystem angepasst ist, Stabilität, Konsistenz, sofortiges Feedback.

Was ganz klar ein Vorteil für den Benutzer ist, entpuppt sich dabei auch als praktisch für den Entwickler: Nicht mehr länger muss er mit «Kompatibilität» mit verschiedenen Browsern/Systemen/Konfigurationen kämpfen. Er entwickelt eine hybride Applikation (was zum Beispiel mit Java unterstützt wird, und mit der Java-Version der e-Banking-Software Yellownet bewiesen wird), die von allen Clients installiert wird. Mit einer eingebauten Software-Aktualisierung, wie sie heute in fast allen Programmen zu finden ist, können diese Clientprogramme schnell und sicher aktualisiert werden und für eine sichere und fehlerfreie Arbeitsumgebung sorgen. Angesichts der Tatsache, dass Web-Applikationen, sollen sie seriös sein, nicht schneller entwickelt werden können, ist es erstaunlich, dass es diese Web-Enabled Applications nicht häufiger gibt.

Aber vielleicht müssen halt noch mehr Kreditkartennummern gestohlen werden, bis die Anbieter aufwachen …