Seite 2: Entwicklungswerkzeuge

Inhaltsverzeichnis

Stolperstein Entwicklungswerkzeuge

Ohne werten zu wollen, kann die Programmierung in der aktuell verbreiteten Version 1.5 nicht gerade als optimal bezeichnet werden. Zumal es in Sachen Werkzeugunterstützung für die Entwickler schlecht aussieht. Angefangen bei mäßigen Entwicklungsumgebungen (Dreamweaver, Eclipse-Plug-ins) bis hin zur Werkzeugschlacht, die man beim Debugging von Javascript-Teilen auf sich nehmen muss. Vom HTTP-Sniffer bis zum speziellen Browser-Plug-in können da schnell mal mehr als drei verschiedene Dinge zum Einsatz kommen, um Fehler zu finden. Ist die Entwicklung so weit erfolgreich verlaufen, bleibt die Frage nach der Softwarequalität – ein entscheidendes Kriterium für Betrieb und Wartbarkeit von Anwendungen im Unternehmen.

Begibt man sich auf Internet-Suche, findet man durchaus Pattern- beziehungsweise Best-Practises-Ansätze für die Entwicklung mit Ajax und Javascript. Für Unternehmen, die im Rahmen ihres Entwicklungsprozesses Softwaremetriken, Nightly Builds oder ähnliches im Einsatz haben, ist Javascript-Entwicklung aber nicht messbar. Hier bleibt nur der direkte Blick in den Code. Ein müßiges Geschäft, das die Abnahme von Projekten deutlich verzögern kann.

Über ein ähnliches Problem stolpert man, wenn man über Tests im Ajax-Umfeld nachdenkt. Entwicklertests sind noch die kleinste Hürde, denn hier gibt es verschiedene Ansätze (etwa JSUnit). Wenn es um Last-, Performance- oder automatisierte Oberflächentests geht, kommt man schnell an die Grenzen der kommerziell im Einsatz befindlichen Werkzeuge. Das Capture & Replay-Aufzeichnen von Ajax-Anwendungen ist keinesfalls trivial und gelingt in Gänze leider nicht immer. Das liegt vor allem an der Tatsache, dass die etablierten Werkzeuge lediglich die tatsächlich an den Server gesendeten Requests aufzeichnen und wieder abspielen können. Was sich in der Ajax-Anwendung selber tut, bleibt diesen Werkzeugen verborgen. Hier muss man sich auf die Suche nach verfügbaren Alternativen begeben und den Abnahmetest entsprechend neu gestalten.

Ein letzter Punkt in dieser losen Folge von Herausforderungen sei das Thema Systemmanagement. Dahinter verstecken sich allerlei Techniken und Werkzeuge zur Überwachung von Anwendungen im Betrieb. Dazu gehört Performanceanalyse genauso wie Fehlerüberwachung und Verfügbarkeitsprüfung. Standardmäßig bieten die entsprechenden Werkzeuge Adapter für Plattformen und Produkte. Browser-Plug-ins finden sich darunter nicht. Geht es daher darum, eine gewichtige Ajax-Anwendung im Betrieb zu überwachen, muss ein Workaround her. Ob man die Fehler beziehungsweise Performance-Indikatoren per Servlet auf den Server schreibt oder andere Wege geht, bleibt jedem selbst überlassen. Bisher berücksichtigen weder die Systemmanagement-Produkte noch die verfügbaren Ajax-Implementierungen eine solche Anforderung.

Schnittstellendesign versus Benutzbarkeit

Wenn man schießlich die technischen Schwierigkeiten so weit im Griff hat, kann man sich dem Bereich widmen, der Ajax ursprünglich auf den Plan gebracht hat. User Interface Design und Usability sind schließlich die eigentlichen Treiber moderner Anwendungen. Auch hier gibt es Punkte, auf die man bei der Umsetzung einer Ajax-Anwendung achten muss. Vor allem, wenn ein Ajax-Ansatz für die Navigation innerhalb der Anwendung Verwendung findet, ist bedenkenswert, dass sich Javascript mit dem Konzept der Browser History und der Bookmarks nicht verträgt. Sollen Anwender von einem der beiden oder gar von beiden Konzepten Gebrauch machen können, muss man hier etwas tun. Ein Glück, dass viele verfügbare Frameworks solcherlei Stolpersteine schon behoben haben. Viel schwieriger sind andere Aspekte, an die sich die Anwender bei Webanwendungen gewöhnt haben. Dazu gehört vor allem das Ausdrucken von Bildschirminhalten. Durch Ajax wird das papierlose Büro wieder zu einer Wunschvorstellung. Die Frameworks nehmen einem hier selten die Arbeit ab. Eine selbstgebaute Lösung ist deshalb erforderlich. Der bei Weitem schwierigste Teil verbirgt sich aber sicherlich in der Unmenge denkbarer Funktionen und Darstellungsformen, die einem das hintergründige Neuladen von Inhalten eröffnen. Schnell ist man hier dabei, neue Benutzerkonzepte zu entwickeln. Seitenteile erscheinen unvermittelt, wo man sie nicht erwartet, der Browser bewegt die Seite wild durch die Gegend oder ähnlich Schlimmes. Dass die Anwender mit solchen Funktionen nicht zurecht kommen, kann man sich gut vorstellen.

Grundsätzlich gilt deshalb der Leitspruch: Asynchron und im Hintergrund bedeutet nicht automatisch unsichtbar. Anwender sind Rückmeldungen von den Systemen gewohnt und haben ein Recht darauf zu wissen, dass in ihrem Sinne gerade gearbeitet wird. Schon ein kleiner "Bitte warten"-Balken wirkt da Wunder und ist schnell programmiert. Außerdem sollte man nicht unbedingt der Versuchung erliegen, den gesamten Bestand fertiger Widgets aus einem oder gar mehreren Frameworks in einer Anwendung einzusetzen. Weniger ist zumeist mehr. Nutzer kommen mit aufgeräumten und übersichtlichen Anwendungen viel besser zurecht als mit überladenen Wunderwerken. Spannend bleibt schließlich die Entwicklung barrierefreier Webapplikationen: Was auf klassischen Webseiten schon ein Riesenstolperstein ist, verschlimmert sich bei der konsequenten Verwendung von Javascript und Ajax. Bisher sind leider keinerlei standardisierte Ansätze in Sicht. Will man entsprechende Lösungen bereitstellen, müssen Entwickler weitgehend in die bestehenden Frameworks eingreifen.