Mit Ajax wird das Web selbst nun zu einer Applikation, die ganz andere Formen der Interaktion zulässt (siehe Interview).
Ajax ist in. Die Ajax-Applikation immo.search.ch wurde zum «Master of Swiss Web 2006» gekürt und als Sieger der Kategorie «Technology Innovation» gefeiert. Aber wie steht es mit der Usability der Ajax-Applikationen? Die Usability-Agentur Zeix testete im Auftrag der Netzwoche immo.search.ch und local.ch.
Die Suche ist eine der Web-Funktionalitäten, für die sich feste mentale Modelle etabliert haben, denn seit Jahren verhält sie sich gleich, bedingt durch Restriktionen des Browsers: Man gibt einen oder mehrere Suchbegriffe in eine Maske ein, drückt auf einen Button, wartet kurz und bekommt eine Resultatseite angezeigt. Befindet sich der gesuchte Inhalt nicht unter den Resultaten, geht man einen Schritt zurück und passt die Anfrage an. Manchmal erfolgt diese Iteration auch auf derselben Seite, aber auch dort in einem ähnlichen Formular. In beiden Fällen entspricht die Suche einem normalen Frage-Antwort-Dialog.
Mit Ajax wird das Web selbst nun zu einer Applikation, die ganz andere Formen der Interaktion zulässt (siehe Interview). So ist es unter anderem möglich, durch direkte Manipulation der Ergebnisse die Abfrage zu verändern. Augenfällig sind diese Unterschiede bei der Ajax-Kartensuche, die mittlerweile zum Standard jeder Mapping-Applikation neueren Datums gehört.
Eingabe der Suchanfrage
Doch wie nutzerfreundlich sind solche auf Ajax basierende Kartensuchen? Im Auftrag der Netzwoche testete die Zürcher Usability-Agentur Zeix die Kartenapplikationen von immo. search.ch und local.ch. Beide getesteten Suchangebote bestehen aus den gleichen drei Hauptelementen: Auf ein und derselben Site findet der User eine Leiste, in der die Suchanfrage eingegeben wird, eine Trefferliste im linken unteren Bereich der Seite und einen Kartenausschnitt, auf dem die Treffer visualisiert werden. Bei immo.search.ch sind dies Liegenschaften, bei local.ch Einträge aus den lokalen Telefonbüchern sowie Ausgehtipps.
Typisch für die Ajax-Suche ist, dass der Nutzer bereits beim Ausfüllen der Masken, beim Tippen, Unterstützung und Feedback durch das System erhält. Gibt man bei immo.search.ch unter Ort nur ein «S» ein, werden bereits Vorschläge von St. Gallen bis Seuzach angezeigt. Eine solche Funktion hilft dem Nutzer zwar über Unsicherheiten bei Schreibweisen hinweg (z.B. bei «La Chaux-de-Fonds») – wer, wie im Test vorgegeben, aber eine Wohnung im Zürcher Quartier «Seefeld» sucht, wird vorerst mal weitertippen. Doch bereits bei «Seef» verfärbt sich das Eingabefeld rot: Durch eine direkte Datenbankabfrage erhält der User schon vor dem Absenden der Maske ein Feedback, dass dieser Ort nicht in der Datenbank vorhanden ist.
Keine Testperson liess sich jedoch durch diese Verfärbung irritieren, sondern alle tippten munter weiter und gelangten zu einer Trefferliste, die entfernt mit dem Seefeld zu tun hat. Die von der Ajax-Applikation angebotene Hilfeleistung wurde also nicht verstanden. Grund: Die meisten Nutzer sind robust in ihrem Verhalten und lassen sich von etwas roter Farbe, deren Sinn ihnen nicht unmittelbar klar wird, nicht ablenken. Da der Kartenausschnitt die Stadt Zürich – und damit auch klein am Rand das Seefeld zeigt – konnte letztlich kein einziger Nutzer nachvollziehen, warum die Ergebnisliste alle Wohnungen anzeigte, die gar nicht im «Seefeld» liegen.
Dass man das Quartier unter seiner Postleitzahl suchen müsste, vermutete nur eine Testperson, allerdings kannte sie diese Postleitzahl nicht und fragte nach über zehn Minuten erfolglosem Suchen: «Wie finde ich denn jetzt die Postleitzahl von Seefeld auf dieser Website?».
Auch den anderen Personen im Test gelang es nicht, eine korrekte Resultatliste fürs Seefeld zu erzeugen. Entweder wählten die Testpersonen einen viel zu grossen Suchradius, was zwar teilweise bemerkt, nicht aber verstanden wurde. Oder sie versuchten erfolglos, «Seefeld» zusätzlich in der Stichwortsuche einzugeben. Hier stellte sich eine grundlegende Frage bei der Kartensuche: Gibt es überhaupt einen Use Case für die Suche einer Wohnung in einem rechteckigen Kartenausschnitt statt in einem Stadtkreis, einer Gemeinde oder einem Quartier?
Eingaben in natürlicher Sprache
Sowohl immo.search.ch wie auch local.ch bieten die Möglichkeit, freie Eingaben zu tätigen. So bietet immo. search.ch beispielsweise statt der klassischen Dropdowns oder Von-bis-Kombination mit mehreren Feldern nur noch ein Eingabefeld, in dem der Mietzins sowohl über einen Schieberegler als auch mit dem Text «1800-2300» angegeben werden kann. Auch kann man die Zimmeranzahl, wie in Immobilieninseraten üblich, in der Form «3½ ? 5½+» oder «-3» (für weniger als drei Zimmer) eingeben, während «3,5+» oder «ab 3,5» nicht akzeptiert wird. Was funktioniert und was nicht, muss der User selbst herausfinden. Der Freizeitbereich von local.ch bietet ebenfalls fürs Web ungewohnte Datumseingabemöglichkeiten an, etwa «heute», «ab heute» oder «Samstag».
Der Test zeigte, dass die Nutzer die Möglichkeit, Freitext in ihrer natürlichen Sprache einzugeben, schnell verstanden, ja sogar sofort begannen, selbst entsprechende Formulierungen zu «erfinden», was umgehend zu Problemen führte: Die Testpersonen gaben vielerlei plausible Texte ein, die das System jedoch nicht verarbeiten konnte. Zur Eingabe des Datums bei local.ch wurden aus den erlaubten Suchphrasen Varianten abgeleitet wie «ab Oktober», «im Oktober» oder «13.?21. Oktober» ? die alle nicht funktionierten. So ist womöglich die Enttäuschung grösser und der Zeitaufwand höher, als wenn man gleich mit einer klassischen Suchapplikation gearbeitet hätte.
Interaktive Suchresultate
Auch die durch die Suchanfragen erhaltenen dynamischen Suchresultatlisten überforderten die Testpersonen. Bei immo.search.ch werden im Kartenbereich und in der Liste bereits Ergebnisse angezeigt, noch bevor man die Suchanfrage überhaupt fertig formuliert hat. Die durchschnittlich und weniger erfahrenen Internetnutzer fielen in die «Aktualisierungsfalle », indem sie durch die sofort angezeigte Trefferliste dazu verleitet wurden, ihre Anfrage nicht mehr fertig auszuformulieren oder zu unterbrechen: Sie begannen, in dieser provisorischen ? oft viel zu grossen ? Trefferliste nach passenden Objekten zu suchen. So spielt es nun plötzlich eine wesentliche Rolle, in welcher Reihenfolge man die Suchbegriffe eingibt, was bisher beim klassischen zweistufigen Modell egal war.
Eines der wichtigsten Prinzipien der Ajax-Kartensuche ist, dass man durch Manipulation der Suchresultate wie durch Zoomen oder Verschieben der Karte, auch seine Suchanfrage ändern kann. Dies ist zwar praktisch, stellt aber einen fundamentalen Bruch mit den eingangs beschriebenen Prinzipien dar. Zoomt man beispielsweise vom Zürcher Seebecken etwas heraus, sucht man innerhalb grosser Teile der Stadt; die nächste Zoomstufe erweitert die Suche bereits auf grosse Teile der Agglomeration. Bei dieser Ausweitung der Suche passt sich die Trefferliste im linken Bereich der Seite automatisch an, während im oberen Bereich die Ortschaft und die Postleitzahl nicht angepasst werden oder verschwinden und im Fall von immo.search.ch unverändert stehen bleiben.
Kernfunktionalitäten blieben teilweise unerkannt
Als weitere Komplikation der Kartensuche kommt hinzu, dass sich der beschriebene Zusammenhang zwischen der Karte und der Trefferliste, respektive der Karte und der Ortschaft in der Suchanfrage-Leiste, deaktivieren und aktivieren lässt, was relativ unauffällig geschieht: im Fall von immo.search.ch über eine Checkbox, im Fall von local.ch über einen Link.
Entsprechend blieb eine der Kernfunktionalitäten von immo.search.ch vollständig unentdeckt: die Checkbox, mittels der man die Wohnungssuche auf den quadratischen Kartenausschnitt statt auf einen Ort beziehen kann. Eine Nutzerin verbrachte rund 25 Minuten auf der Website und wunderte sich laufend über die unpassenden Treffer, die überhaupt nicht zu ihrer Suchanfrage zu passen schienen.
Keine der Testpersonen verstand die Zusammenhänge und das Wechselspiel zwischen den einzelnen Bildschirmbereichen. Bei local.ch, das die Testpersonen erst nach immo.search.ch nutzten, wurde der Zusammenhang zwischen den Bildschirmbereichen teilweise besser verstanden, allerdings zeigten sich zum Zeitpunkt des Tests teilweise noch technische Probleme, so dass die Karte gar nicht oder viel zu spät angezeigt wurde.
Auch die an sich praktische Sonderfunktion von immo.search.ch, sessionsübergreifend Favoriten zu markieren, die in der Folge immer angezeigt werden, führte zu grosser Verwirrung, da diese Favoriten nun ständig in der Trefferliste angezeigt wurden ? auch wenn sie der aktuellen Suche gar nicht mehr entsprachen. Wer zuerst in 8003 Zürich eine Wohnung als Favorit markiert und anschliessend in 8048 Zürich weitersucht, sieht inmitten der Resultate für 8048 Zürich seinen 8003er-Favoriten als Treffer. Im Extremfall erschienen bei einem User in der Trefferliste mehr Favoriten als Treffer, was diesen völlig verwirrt zurückliess.
In einer fortgeschrittenen Aufgabe sollten die Testpersonen auf local.ch ein chinesisches Restaurant in Brig und Umgebung suchen. Da in Brig kein entsprechendes Restaurant existiert, könnte die Kartensuche ihre Stärken voll ausspielen: Man sucht zunächst nach einem chinesischen Restaurant in Brig, findet nichts und erweitert dann den Kartenausschnitt so weit, bis man in der Nähe ein chinesisches Restaurant gefunden hat. Doch hier zeigte sich ein weiteres Problem, was auch bei klassischen Suchen bestehen kann: Bei local.ch hat man zwei Eingabefelder: eines für den Ort, eines für den Suchbegriff. Logischerweise tippten alle Testpersonen «chinesisches Restaurant» in das eine, «Brig» in das andere Eingabefeld ein. Da keine Treffer vorhanden waren, wussten die Testpersonen nicht, ob es einfach kein chinesisches Restaurant in Brig gibt, oder ob sie ihren Suchbegriff falsch eingegeben hatten. In der Folge probierte jede Testperson mindestens zehn Suchanfragen aus, bevor sie überhaupt auf die Idee kam, dass man auch über den Kartenausschnitt nach dem Restaurant suchen könnte. Letztlich gelang es nur zwei der vier Testpersonen, überhaupt ein chinesisches Restaurant auf Schweizer Boden zu finden, wobei es sich in keinem Fall um eines in der Umgebung von Brig handelte.
«Im Idealfall nimmt der Nutzer Ajax gar nicht wahr»
Interview von Sandra Steiner, Netzwoche
Der Einsatz von Ajax bietet grosse Chancen – birgt aber auch das Risiko, interaktive Plattformen einmal mehr an den Massen vorbei zu entwickeln. Peter Hogenkamp, Partner beim Usability-Dienstleister Zeix, erklärt, wie Ajax nutzerfreundlich angewendet wird.
Herr Hogenkamp, die geteilten Reaktionen beim Relaunch von immo.search.ch ? Überschwang bei den Power-Usern, Unverständnis bei allen anderen ? haben eindrücklich gezeigt, dass Ajax-Anwendungen nicht automatisch selbsterklärend sind. Worin gründete diese Ablehnung?
In der Tat wünschten damals einige User die alte Immobiliensuche von Search.ch zurück – ein Schlag ins Gesicht, wenn man denkt, dass man gerade etwas fundamental verbessert hat und die Branche einen dafür liebt. Aber man hat gesehen, dass graduelle Verbesserungen nichts dagegen sind, wenn jemand dafür die Grundfunktionen nicht mehr findet. Seit den Anfangstagen des Web haben sich die User an gewisse Funktionsweisen gewöhnt, vor allem an die bisher typische Abfolge: lesen, klicken, warten. Selbst wenn es sich um mühsame oder zeitraubende Vorgänge handelt, trägt die Vertrautheit sozusagen zur mentalen Entlastung bei. Überspitzt gesagt: Es ist gar nicht schlimm, wenn ich fünf Schritte brauche, Hauptsache, ich muss nicht zu viel denken.
Also lieber doch kein Ajax? Oder gibt es Anwendungen, bei denen Ajax aus Usability-Sicht wirklich sinnvoll ist?
Natürlich gibt es die, und es sind unzählige. Wir dürfen die Vorgeschichte nicht ausser Acht lassen. Der Browser war ursprünglich als Abfrageprogramm für Textbibliotheken gedacht, nicht für interaktive Anwendungen. Seit zehn Jahren versucht man, diesen Makel zu beheben, mit Java, Javascript, DHTML, Flash etc., wobei alle Varianten mehr oder weniger grosse Schwächen haben, so dass sich keine restlos durchgesetzt hat. Ajax ist der mit Abstand aussichtsreichste Ansatz, aber der Übergang geschieht natürlich nicht völlig friktionslos. Jede Innovation ist zuerst ein Usability-Problem ? wie intuitiv sie sich dann erschliesst, macht den Erfolg aus. Es hilft sicher, wenn die Neuerung an etwas erinnert, das man kennt. Google Suggest, bei dem die Eingabe nach jedem Tastendruck zu verschiedenen Suchphrasen, inklusive der zu erwartenden Trefferzahl, ergänzt wird, sieht fast genauso aus wie die vertraute Auto-Vervollständigen-Funktion des Browsers. Die User nutzen das Feature einfach und merken vielleicht gar nicht, dass es etwas Neues ist.
Gibt es nicht im Moment einen Boom von neuen Ajax-Applikationen, die aber nur von Internetfreaks genutzt werden, weil sie einfach zu wenig nutzerfreundlich sind? Oder wird Otto Normalverbraucher sie auch irgendwann entdecken?
Man muss zwischen verschiedenen Arten des Ajax-Einsatzes unterscheiden. Zum einen gibt es Web-Applikationen, die versuchen, Desktop-Applikationen möglichst weitgehend nachzubauen wie Writely als abgespecktes Word, iRows als kleines Excel etc. Ob die «Hipness» dieser Online-Versionen auch die Massen der User überzeugen wird, die nur jeden Tag vom selben PC aus ihre Arbeit schnell und effizient erledigen wollen und die Software auch lokal installiert haben, muss sich erst noch zeigen. Ich würde das Potenzial von Ajax nicht unterschätzen. Die Ortsunabhängigkeit solcher Anwendungen ist ein sehr starker Faktor, und Browser gibt es inzwischen nun mal überall. Dann gibt es die Kategorie von Web-Applikationen, die sich mit Ajax deutlich anders anfühlen als vorher; dazu gehören die getesteten local.ch und immo.search.ch oder zum Beispiel auch Googles GMail, das enorm viele Leute inzwischen als ihre einzige Mailing-Applikation nutzen, weil das Interface besser ist als das vieler Mail-Clients. Schliesslich gibt es Websites, die einzelne Features einbauen, zum Beispiel in Formulare, ohne deswegen gleich eine «Ajax-Site» sein zu wollen. Ajax kann hier leise wirken, ohne dass man je Gefahr läuft, neue Probleme zu generieren. Ein gutes Beispiel hierfür ist ein Registrationsprozess, bei dem ich jeweils direkt nach der Eingabe sehe, ob der Benutzernamen noch verfügbar ist oder ich mich beim Wiederholen des Passworts vertippt habe. Das ist das richtige Feedback zur richtigen Zeit am richtigen Ort, viel besser als der alte Prozess mit dem Reload der Seite und Fehlermeldungen irgendwo im Formular, die ich erst suchen muss. Durch solche Features erhöht sich nicht nur der Komfort, sondern auch die Sicherheit des Anwenders, korrekte Angaben gemacht zu haben. Im Idealfall nimmt der Nutzer dies gar nicht als etwas Aussergewöhnliches wahr, sondern findet schlicht den Prozess einfach zu bedienen.
Raten Sie also davon ab, ganze Sites in Ajax zu erstellen?
Ich rate davon ab, heute beim Redesign einer schon erfolgreichen Site zu viele Ajax-Features einzuführen, die die Bedienbarkeit an sich gefährden. Man stelle sich vor, der SBB-Fahrplan wäre plötzlich hip und schneller, was aber nur ein Drittel der Leute als positiv wahrnimmt, einem weiteren Drittel ist es egal, und das letzte Drittel kann die Abfrage nicht mehr bedienen. Das wäre eine Katastrophe! Die grundlegende Anforderung an Ajax-Usability ist, dass wer Javascript deaktiviert hat oder die Ajax-Funktio nalität einfach übersieht, weiterhin in der Lage ist, die Website zu nutzen. Was auch gut funktioniert ist, wenn die User die neuen Möglichkeiten erst nach und nach entdecken, aber die Applikation trotzdem von Anfang an bedienen können. Bei G-Mail beispielsweise ist das vielen so ergangen.
Wie viele Websites werden in fünf Jahren Ajax-Features einsetzen?
Fast alle, viele vielleicht nur bei Kleinigkeiten. Vermutlich wird der Begriff verschwinden, weil es einfach die Art und Weise sein wird, wie man in Zukunft im Web programmiert.
Kommentare