AJAX und die Realitäten mobilen Arbeitens

2006-03-07T18:51:00+00:00

Erinnert sich noch jemand an Timesharing? Ein Zentralrechner dient vielen Terminals als gemeinsame Ressource. Eine Vorbedingung für Timesharing war eine Datenleitung zwischen Terminal und Zentralrechner — lokal oder entfernt (die gute alte „Datenfernübertragung“, die in Microsofts „DFÜ-Verbindungen“ weiterlebt).

Der Personal Computer war dann die neue Idee, jedem Menschen einen persönlichen Computer zu geben, um die Abhängigkeit von schwerfälligen Zentralrechnern loszuwerden. Der PC wurde in den 1980ern tragbar, so daß man seine persönliche Infrastruktur bald überall hin mitnehmen konnte (vom Koffer-Computer „Compaq“ bis hin zum modernen Notebook Computer).

Recht schnell wurde dann jedoch klar, daß ein einzelner Rechner (genauer: ein einzelner Mensch an diesem Rechner) nicht viel ausrichten kann. Netze mußten her, um die PCs auch noch mit nützlichen Funktionen zur Kommunikation und zum gemeinsamen Arbeiten auszustatten.

Das Internet hat diese Rangordnung inzwischen nahezu umgekehrt: Der Computer ist heute in vielen Fällen vor allem Zugangswerkzeug zum Netz und zur Kommunikation mit anderen (Menschen und den von ihnen gemeinsam benutzten Systemen), erst in zweiter Linie persönlicher Rechner mit eigenen Funktionen. AJAX ist ein Vehikel, um dieses Primat der Kommunikation und Kollaboration über die isolierte Eigenarbeit („personal productivity“) auch auf klassische PC-Anwendungen wie Textverarbeitung, Kalkulation und Präsentationsentwicklung auszudehnen — das Web als Plattform.

Das Problem

Aber wie arbeiten wir heute? In vielen Bereichen ist das Büro, dessen Desktop-Anwendungen AJAX ersetzen will, gar nicht mehr primärer Arbeitsort. (Es mag nicht jedem so gehen, aber mein persönliches Büro ist praktisch identisch mit meinem Laptop.)

Dieser Artikel ist in einem Flughafen entstanden, in dem Internet-Konnektivität zwar ausreichend besteht, aber durch bestimmte Marktentwicklungen künstlich um Größenordnungen verteuert ist. Die Benutzung einer Web-Anwendung wäre in diesem Kontext prohibitiv teuer. Will ich im Flugzeug weiterarbeiten, wird Konnektivität (außer in wenigen Flugzeugen z.B. der Lufthansa) ganz unmöglich. Im Zug (ICE) kann man zwar über GPRS (2.5G/3G) Basis-Konnektivität erlangen, diese bricht beim heutigen Stand der Mobilnetze unterwegs aber immer wieder zusammen. (Fertig getippt habe ich den Artikel auf einer Konferenz mit einem Konferenznetz, das unter der Last der vielen Teilnehmer immer wieder zusammenbricht.)

Von der Vision „Always on, always connected“ sind wir aus vielerlei Gründen (nicht alle davon technisch) weit entfernt.

Intel hat für ein paar Jahren versucht, einen Begriff für diese Arbeitsform zu prägen: Occasionally Connected Computing, so als sei man nur gelegentlich am Netz. Verständlich, wollen sie doch eine leistungsstarke Plattform verkaufen, die eben auch ohne Web viele Anwendungen möglich macht.

Eine realistischere Beschreibung wäre „Frequently Connected Computing“ (die Abkürzungskollision mit der amerikanischen Kommunikationsbehörde FCC nehme ich hier bewußt — und auch etwas ironisch meinend — in Kauf).

Was ist zu tun?

Wie muß eine AJAX-Umgebung beschaffen sein, die auch unter FCC-Bedingungen funktioniert?

Es ist klar, daß neue Seiten nur angefordert werden können, solange Konnektivität zum Server besteht. Eine FCC-kompatible Web-Anwendung wird sich also eher länger auf einer Seite aufhalten (geht also in Richtung Single-Page Application, aber eben mit AJAX) — Kartenreiter und ähnliche UI-Techniken können dazu beitragen, daß die Übersicht erhalten bleibt.

Eine andere Frage ist, wie die Anwendung mit Eingaben des Benutzers umgeht. Was ganz bestimmt nicht passieren sollte, sind Fehlermeldungen der Form:

 Es gab ein Problem mit dem Netz -- Ihre Eingaben sind jetzt weg

(oder gar Datenverlust ohne jede Fehlermeldung!).

Es geht also darum, Eingaben des Benutzers auch dann aufzubewahren, wenn der erste Versuch, sie über AJAX an den Server zu übertragen, fehlschlägt.

PANIC-Mode

Es gibt verschiedene Möglichkeiten, mit durch Netzprobleme fehlgeschlagenen Server-Updates umzugehen. Mein Ansatz basiert darauf, Updates im Browser persistent zu speichern, bis der Server bestätigt, daß sie erfolgreich integriert worden sind. Da im Web2.0-Umfeld Abkürzungen ganz wichtig zu sein scheinen, habe ich gleich mal ein Akronym defür definiert:

 P ersistency for
 A JAX in
 N etworks with
 I ntermittent
 C onnectivity.

Mehr zu panic-mode am Donnerstag auf der Emerging Technology-Konferenz von O’Reilly.

Viele Köche: AJAX und die Realitäten mobilen Arbeitens

AJAX und die Realitäten mobilen Arbeitens

Das Problem

Was ist zu tun?

PANIC-Mode