Usability im Web 2.0

Von Jan Hegewald

Heute sind mit AJAX Oberflächen möglich, die den Umgang mit Webanwendungen für den Benutzer deutlich vereinfachen können, da sie eine ähnlich reichhaltige Funktionalität bieten wie Desktop-Anwendungen. Man sollte jedoch sorgfältig darauf achten, den Benutzer nicht zu verwirren, wenn erlernte Verhalten aus dem Web 1.0 nicht mehr funktionieren. Viele solcher Probleme lassen sich mit Umsicht beim Design vermeiden, bei anderen ist ein gewisser Aufwand nötig.

Dem Web 2.0 fehlen Design-Standards
Der Segen, dass Web2.0-Seiten das Feeling einer Anwendung bieten können, ist – falsch umgesetzt – gleichzeitig ein Fluch. Für klassische Anwendungen gibt es auf jedem Betriebssystem einen Standard, meist in Form eines Styleguides. Dieser gibt vor, welche Elemente einer Oberfläche wie aussehen. Weiße Kästen mit schwarzem Rahmen, in denen ein Cursor blinkt, sobald sie ausgewählt werden, sind beispielsweise Eingabefelder für Text. Buttons sind unter Windows graue Rechtecke mit abgerundeten Ecken und einer Beschriftung. Jeder mit dem System vertraute Benutzer weiß daher, welche Funktion die einzelnen Elemente einer Oberfläche haben.

Das Web als Betriebssystem, auf dem die Web 2.0-Anwendungen laufen, kennt solche Standards kaum. Daraus resultiert die Gefahr, dass der Benutzer nicht weiß, wo er auf einer Seite Inhalte eingeben kann, und wo nicht.

Die Abbildung zeigt einen Ausschnitt einer personalisierten Google-Startseite mit den AJAX-Anwendungen ToDo-Liste und Haftnotiz. Otto-Normal-Benutzer ahnt sofort, dass er im Kasten „Neuer Eintrag“ eine Beschreibung eingeben kann und diese per Klick auf „Hinzufügen“ in seine ToDo-Liste wandert.

Was der Benutzer nicht unbedingt erkennt, sind drei weitere Interaktionsmöglichkeiten. Zunächst einmal kann er auch per Klick in das hellgelbe Feld der Haftnotiz den dortigen Text bearbeiten. Noch überraschender ist sicherlich die Möglichkeit per Klick auf die Priorität „niedrig“, eine Auswahlbox mit unterschiedlichen Prioritäten zu öffnen, wie die nächste Abbildung zeigt:

Ferner kann der Benutzer die Elemente ToDo-List und Haftnotiz sogar per Drag & Drop auf der personalisierten Seite verschieben, indem er jeweils die Titelleisten anklickt. Problematisch ist, dass die Oberfläche dem Benutzer Funktionen bietet, die er vielleicht nicht bemerkt. Wie kann man so etwas vermeiden? Der Weg zu einer sofort verständlichen Oberfläche führt über Standards. Im Web2.0-Bereich etablieren sie sich erst langsam, deshalb ist es ratsam, sich zunächst an Bewährtes zu halten.

Im konkreten Beispiel hieße das, statt des Textes mit der Priorität „niedrig“ sofort das Auswahlfeld anzuzeigen und nicht erst beim Klicken darauf. So weiß der Benutzer stets, dass er dort eine Auswahl treffen kann.

Der gelbe Notizzettel zeigt einen ersten aufkommenden Standard für Oberflächendesign im Web 2.0: hellgelb als Hintergrundfarbe für editierbare Bereiche zu verwenden, ist eine gute und verbreitete Sitte. Allerdings sind sicherlich noch lange nicht alle Benutzer von Webseiten damit vertraut. Ein klassisches, weißes Eingabefeld wäre daher eine sichere Lösung, die allerdings nicht sehr schick auf einer ansonsten durchgestylten Webseite aussieht. Man muss also abwägen, ob man mehr Wert auf Optik oder Bedienbarkeit legen möchte. Per Drag & Drop verschiebbare Elemente sollten am besten wie ein Fenster aussehen, damit der Benutzer die Funktionalität erahnen kann. Ein Beispiel für eine unmittelbar verständliche Darstellung von Aktionsmöglichkeiten sind dagegen die den meisten Nutzern bekannten Knöpfe zum Schließen oder Zuklappen der Elemente rechts oben in der Titelleiste.

Allgemein gilt also: jegliche Interaktionsmöglichkeit auf einer Seite sollte für den Benutzer auf Anhieb erkennbar sein. Die beste Methode, um dies sicherzustellen ist, auf vertraute Standards im Oberflächendesign zurückzugreifen.

Web 1.0 war auch ganz nett
Eine Reihe von Dingen, die im Web 1.0 problemlos funktionierten, bereiten dem Benutzer bei AJAX-Oberflächen auf einmal Schwierigkeiten. Das prominenteste Beispiel ist die URL. Früher repräsentierte sie genau eine Seite, was bei AJAX nicht mehr der Fall ist.

Werden mit AJAX Inhalte auf einer Seite dynamisch ausgetauscht, bleibt in der Regel die URL in der Adresszeile des Browsers unverändert. Dies hat (mindestens) zwei negative Auswirkungen. Der Benutzer kann die aktuelle Seite, die er vor sich hat, nicht als Bookmark speichern und nicht als Link an Bekannte verschicken. Würde er das tun, würde beim erneuten Aufruf der Seite deren Startzustand, nicht aber die später dynamisch geladenen Informationen angezeigt. Erschwerend kommt hinzu, dass der Benutzer dies unter Umständen gar nicht bemerkt oder erst dann, wenn er die Seite aufrufen will beziehungsweise der Bekannte sich wundert, dass er gar nicht die versprochenen Inhalte sieht.

Für dieses unerwartete Verhalten gibt es eine bessere Alternative. Der Benutzer muss die Möglichkeit haben, eine URL zu bekommen, in der der gesamte Kontext, das heißt alle Informationen, die den aktuellen Seiteninhalt beeinflussen, codiert sind. Die Webseite selbst muss dann beim Abruf einer solchen URL die enthaltenen Kontextinformationen nutzen und die Seite mit denselben Informationen wieder darstellen, wie dies ursprünglich der Fall war.
Der Kartendienst Google Maps ist ein gutes Beispiel. Hat man auf der Seite diverse Orte angeschaut, so bleibt doch die URL im Browser stets dieselbe. Diese kann man also nicht speichern oder verschicken. Klickt man jedoch auf den Link „URL zu dieser Seite“, so wird die Seite mit einer URL neu geladen, in der alle Informationen, also die aktuell angezeigte Adresse, als Parameter codiert sind. Ruft man diese URL später auf, landet man tatsächlich bei derselben Darstellung der Karte.

Dieses Verhalten erfordert zwar Mehraufwand bei der serverseitigen Umsetzung der AJAX-Anwendung, erhöht den Nutzen für den Anwender aber enorm.

Wo, bitte schön, geht’s denn hier zurück?
Ein weiteres Problem, das mit dem dynamischen Nachladen von Teilen einer Seite per AJAX zusammenhängt, ist das Nicht-Funktionieren des Zurück-Buttons im Browser. Browser rufen normalerweise die vorherige URL auf, wenn der Zurück-Button angeklickt wird. Hierzu sollte man wissen, dass dies die am zweit häufigsten verwendete Aktion in einem Browser ist (noch häufiger wird nur die Aktion ausgeführt, eine Webseite aufzurufen).

Gerade diese Funktion kann für den Benutzer verwirrend sein, wenn er diverse Änderungen an der AJAX-Oberfläche vorgenommen hat und nur die letzte rückgängig machen möchte, stattdessen aber auf eine zuvor besuchte, ganz andere Webseite zurückkommt.

Es gibt mittlerweile einige Methoden um Seitenänderungen per AJAX in die Browser-Historie der zuletzt aufgerufenen Seiten aufzunehmen. Sie funktionieren meist mittels unsichtbarer iFrames. Jedoch ist immer ein beträchtlicher Umfang JavaScript erforderlich, unter anderem auch, damit sie mit allen wichtigen Browsern funktionieren.

Really Simple History (RSH) ist eine solche Bibliothek, die Funktionen bietet um den Zurück-Button zu neuem Leben zu erwecken.

Finden Sie die Unterschiede
Der mit dem Umgang von Web 1.0 erfahrene Benutzer hat oft Erwartungen, welche eine echte Herausforderung für den Entwickler von Web 2.0-Seiten darstellen. Immerhin geht mit AJAX das alte Seitenparadigma verloren. Werden Änderungen auf einer Seite vorgenommen, bedeutet das nicht mehr wie zu Web 1.0-Zeiten, dass eine komplett neue Seite geladen wird. Unter Umständen wird nur ein kleiner Ausschnitt der angezeigten Seite aktualisiert. Hier kann es passieren, dass der Benutzer nicht bemerkt, dass er Änderungen vorgenommen hat. Eventuell verlässt er frustriert die Website, weil er glaubt, dass diese nicht funktioniert.

Um das zu vermeiden gilt: Hervorheben! Bewährt haben sich Techniken, die geänderte Teile einer Webseite kurzzeitig durch eine andere Hintergrundfarbe hervorheben, die dann wieder verblasst. Alternativ sind auch kleine Mitteilungsboxen geeignet, die eingeblendet werden und die erfolgreichen Durchführung der Aktion mitteilen: „Änderungen gespeichert“ zum Beispiel.
Generell sollte das Prinzip der räumlichen Nähe beachtet werden: Wenn ein Benutzer eine Aktion mit der Maus oder der Tastatur auslöst, sollte dadurch ein Teil geändert werden, der unmittelbar in diesem Bereich liegt und nicht ganz woanders auf der Seite. Der schlimmste Fall wäre der, wenn ein Teil aktualisiert würde, der gar nicht sichtbar ist, weil der Benutzer erst scrollen müsste.

Es ist immens wichtig den Benutzer auf Änderungen hinzuweisen, wenn eine Seite nicht wie gewohnt neu geladen wird. Nur so wird er die neue AJAX-Dynamik gegenüber dem alten Seiten-Paradigma auch schätzen.

Barrierefreiheit und Sicherheit
Grundsätzlich ist die Verwendung von AJAX hinsichtlich Barrierefreiheit kritisch zu beurteilen. Vor allem Screenreader, also Programme, die den Bildschirminhalt einem blinden Benutzer vorlesen, haben häufig Probleme mit JavaScript. Normalerweise liest ein Screenreader eine Bildschirmseite von oben nach unten komplett vor. Wenn sich nun einzelne Bereiche einer Seite ändern, bekommt dies der Screenreader entweder gar nicht mit oder er beginnt die gesamte Seite neu vorzulesen. Dies ist für den Benutzer verwirrend, da er zunächst alle unveränderten Teile nochmals hört. Es ist vielleicht zu optimistisch anzunehmen, dass die Hersteller der Screenreader ihre Produkte bald anpassen werden. Schließlich sind diese meist nicht auf das Vorlesen von Webseiten spezialisiert, sondern müssen alle Desktop-Anwendungen zugänglich machen.

Nach der Barrierefreien Informationstechnikverordnung der Bundesregierung (BITV) muss eine Webseite auch bei abgeschaltetem JavaScript einwandfrei funktionieren. In BITV, Anlage 1, Priorität I, Anforderung 6.3 heißt es: „Es muss sichergestellt sein, dass mittels Markup-Sprachen geschaffene Dokumente verwendbar sind, wenn Scripts, Applets oder andere programmierte Objekte deaktiviert sind.“

Im Klartext: eine Seite muss genauso verwendbar sein, wenn JavaScript abgeschaltet ist. Nicht nur in Hinblick auf Barrierefreiheit, sondern auch angesichts von Sicherheitsbedenken, die viele Benutzer dazu veranlassen JavaScript zu deaktivieren, ist das eine gute Idee. ™

Erstveröffentlichung 18.04.2007

Weitere Beiträge:

• 5 Ideen wie Sie wiederkehrende Arbeitsschritte & Marketingprozesse gewinnbringend im Internet automatisieren! Ein Gastbeitrag von Robert Nabenhauer.
• Wachstum durch Facebook-Gewinnspiele: Wie Sie über Facebook virale Gewinnspiele & eine schnell wachsende Fangemeinde aufbauen
• Wie Sie aufmerksamkeitsstarke Prelaunch-, Launch- und Relaunch-Szenarien aufbauen und dabei Viralität, Spannung & Kaufkraft erzeugen
• Wie Sie waschechte Iphone-Apps mit PhoneGAP entwickeln, um am lukrativen App-Markt mitzumischen
• Wie Sie Ihr Shop-Sortiment so präsentieren, dass der Kunde in Zukunft mehr findet und eher kauft! Ein Gastbeitrag von Nicolas Schmidt-Voigt.
• 11 faszinierende BuddyPress-Plugins, um kostenlos aus WordPress ein soziales Netzwerk zu zaubern
• Die Vorboten einer neuen Internet-Industrie! Ein exklusiver Rückblick & Blick hinter die Kulissen der Clickbank-Exchange 2011 in New York.