Die Probleme, die man sich durch den Einsatz von Ajax einhandeln kann, lassen sich in drei Kategorien einteilen. Erstens können schlichtweg technische Probleme auftreten, zweitens kann die Kompatibilität zu externen Komponenten und Services leiden, und drittens muss der Einsatz von Ajax an sich grundlegend durchdacht sein, um eine konsistente, intuitive und vor allem gute
Benutzeroberfläche zur Ver-
fügung zu stellen.
Betrachtet man Ajax rein vom Begriff her (Asynchronous JavaScript and XML), so ergeben sich direkt die beiden Hauptbestandteile – eben JavaScript und XML. Da Ajax eine clientseitige Technologie ist, folgt daraus aber auch bereits die erste technische Einschränkung: Der Browser
muss – um eine Ajax-gestützte Seite problemlos anzuzeigen zu können – JavaScript ausführen können (und dürfen) und muss über eine Implementierung des XmlHttp-Objekts verfügen.
Zweiteres ist bei allen modernen Browsern gegeben, aber JavaScript kann zum Beispiel in Firmen aufgrund von Sicherheitsrichtlinien deaktiviert sein. Daher sollte Ajax in einer Webapplikation immer so eingesetzt werden, dass es Funktionalität nur vereinfacht, aber niemals so, dass es kritische Funktionen ergänzt. Beispielsweise kann eine Textbox, welche Autovervollständigen für ihren Inhalt anbietet, auch ohne diese Funktion genutzt werden, ein Speichern-Button, der vollständig auf Ajax basiert, ist ohne Ajax allerdings nutzlos.
Letztendlich gelten für den Einsatz von Ajax-gestützten Komponenten damit die gleichen Einschränkungen wie sie schon für den Einsatz von JavaScript an sich gelten – es sollte immer auch eine Ajax-freie Variante zur Verfügung stehen, ohne dass bei dieser relevante Funktionalität verloren geht.
Ein weiterer Aspekt beim Einsatz von Ajax ist die Leistung der Clients, welche die Webapplikation anzeigen. Da jede Ajax-Komponente auf dem Client berechnet, gerendert und ausgeführt wird, verbraucht sie dort Leistung. So können beispielsweise gerade umfangreiche Validatoren für Eingabefelder oder aufwendige grafische Effekte den Client nicht unwesentlich belasten.
Entsprechend kann man nicht davon ausgehen, dass es sich bei jedem Client um einen entsprechend leistungsfähig ausgestatteten Computer handelt. Ausserdem gilt es, auf mobile Endgeräte und auch schwächere Computer wie Thin Clients Rücksicht zu nehmen. Nicht zuletzt sind einige Ajax-Komponenten auch nicht gerade kompakt, bezogen auf die zu übertragende Datenmenge. Immerhin müssen meistens Daten im dreistelligen kByte-Bereich übertragen werden, doch nicht jeder Anwender verfügt über eine entsprechend schnelle Breitbandanbindung.
Zusammenfassend lässt sich also sagen, dass die Zielgruppe und deren technische Möglichkeiten – von der Anbindung bis hin zum verwendeten Browser – sehr genau definiert werden sollte, um nicht «am Markt vorbei» zu entwickeln.
Die zweite Kategorie von Problemen, die im Zusammenhang mit Ajax auftreten kann, betrifft die Kompatibilität einer Webapplikation – insbesondere mit Suchmaschinen und dem Browser des Benutzers. Hierbei ist nicht die technische Kompatibilität gemeint, sondern die Konformität im Hinblick auf Zusammenarbeit beziehungsweise Benutzbarkeit.
Ajax-gestützte Seiten zeichnen sich oftmals dadurch aus, dass ihr Inhalt dynamisch und kontextbezogen nachgeladen wird. Was auf den ersten Blick äusserst praktisch erscheint, hat auf den zweiten einen riesengrossen Nachteil – Inhalt, der nicht über eine dedizierte eigene URL verfügt, lässt sich nur schlecht den Favoriten hinzufügen oder anderweitig direkt aufrufen.
Hier gilt es also, den Nutzen des dynamischen Nachladens gegen die Wahrscheinlichkeit des direkten Zugriffs abzuwägen. Ein gutes Beispiel ist hier Outlook Web Access, das Ajax nutzt, um die jeweils ausgewählte E-Mail dynamisch nachzuladen und anzuzeigen. Da man selten eine einzelne E-Mail als Favoriten ablegen würde, ist es vertretbar, dass diese nicht über eine eigene URL verfügt. Für eine Nachrichtenseite als weiteres Beispiel aber wäre es undenkbar, die einzelnen Meldungen dynamisch per Ajax nachzuladen – viel zu oft besteht der Bedarf, den Link auf eine bestimmte Nachricht an jemand anderes weiterzuleiten oder die Nachricht den eigenen Favoriten hinzuzufügen.
Bedenken muss man an dieser Stelle auch, dass Suchmaschinen Ajax gegenüber nicht sonderlich freundlich eingestellt sind – Ajax wird ebenso wie JavaScript oder Flash ignoriert. Möchte man also, dass der Inhalt der Webseite gefunden wird, sollte man auf Ajax verzichten – zumindest zur Navigation, zum Paging von Tabellen oder zum Nachladen von Panels.
Im Hinblick auf Suchmaschinenkompatibilität ist Ajax dann erlaubt, wenn es nicht für den Inhalt, sondern für Funktionalität eingesetzt wird. Sowohl Validatoren wie auch Buttons würden von Suchmaschinen sowieso nicht ausgeführt, so dass sie nicht zur Indizierung herangezogen werden. Auch Statusmeldungen können in der Regel bedenkenlos mit Hilfe von Ajax angezeigt werden, da ihr Inhalt zumeist nicht relevant für den eigentlichen Inhalt einer Webseite ist.
Fasst man diese Einschränkungen zusammen, so ergibt sich, dass Ajax ausser in Ausnahmefällen nicht für die Navigation und generell nicht zur Generierung von Inhalt genutzt werden sollte. Zur Erweiterung beziehungsweise Verbesserung der Funktionalität der Benutzeroberfläche lässt sich Ajax allerdings einsetzen.
Bleibt also die Frage, welche Anwendungsfälle für Ajax bleiben, um die Benutzeroberfläche aufzuwerten, und was dabei zu beachten ist. Grundlegend kann man sagen, dass alles, was dem Benutzer die Bedienung der Webapplikation einfacher oder intuitiver macht oder was die notwendige Wartezeit beim Laden einer Webseite verkürzt, zunächst einmal gut ist – unter Beachtung der bereits genannten Einschränkungen.
Typische Kandidaten für solche Erweiterungen wären also beispielsweise Validatoren zur Prüfung von eingegebenen Daten, Möglichkeiten zum Bearbeiten und Speichern von Daten vor Ort, ohne erst auf eine eigene Bearbeitungsseite wechseln zu müssen, oder auch die inzwischen doch recht häufig eingesetzten Wartesymbole (www.ajaxload.info). Hier gilt allerdings – wie bei den meisten Effekten – dass weniger oft mehr ist. Solche Komponenten sollten also durchaus dort eingesetzt werden, wo sie Sinn ergeben, aber nie um ihrer selbst willen, sonst wirkt eine Webseite schnell überladen. Wichtig ist auch, dass Veränderungen an der Seite, die durch Ajax ausgeführt werden, mit visuellem Feedback versehen werden, damit der Benutzer merkt, dass sich an einer bestimmten Stelle etwas verändert hat. Allzu leicht gehen Änderungen sonst unter.
Ebenfalls geschickt lässt sich Ajax einsetzen, um Daten quasi unsichtbar im Voraus zu laden. Um auf das Beispiel mit Outlook Web Access zurückzukommen – ein wünschenswertes Feature könnte hier beispielsweise sein, dass beim Lesen der ersten ungelesenen Nachricht weitere ungelesene Meldungen vorgeladen werden, damit diese dann auf Mausklick verfügbar sind. Doch auch hier sollte man Vorsicht walten lassen und zurückhaltend sein, denn nicht jeder verfügt über eine Breitbandverbindung oder kann die vollständige Kapazität seiner Anbindung nutzen.
Tips, Tutorials und Werkzeuge zu Ajax
Als Fazit lässt sich sagen, dass Ajax eine Technologie mit grossartigen Möglichkeiten ist, deren Potential derzeit sicherlich noch nicht vollends ausgenutzt wird. Ajax kann – geschickt und durchdacht eingesetzt – die Bedienbarkeit einer Webapplikation sehr verbessern und den Abstand zwischen Web- und Desktopapplikationen ein gutes Stück verringern.
Dabei sollte man sich aber immer bewusst sein, dass der Einsatz von Ajax gerechtfertigt sein muss, um nicht überladen zu wirken – sprich, Ajax sollte als Mittel und nicht als Zweck gesehen werden. Wenn man sich daran hält, kann man mit Ajax viel bewirken, um gute Webapplikationen der nächsten Generation zu schaffen.
