Architektur und Ressourcenverteilung

Die nativen Clients für die mobilen Plattformen existierten bereits; somit bestand Klarheit über die grundsätzliche Architektur. Die Client-Komponente sollte via SSL mit einer Serverkomponente kommunizieren, die dann auf Basis einer Protokollbeschreibung Aktionen serverseitig ausführt. Das kann der Ausdruck auf einem Netzwerkdrucker sein, das Rendern eines PDFs oder das Zurückliefern von Inhalten, wie beispielsweise Dateilisten. Für die Kommunikation zwischen Client und Server setzen wir auf modernes AJAX (XMLHttpRequest Level 2) und das sehr schlanke Datenaustauschformat JSON. Weil der HTML5-Cloud-Desktop keine serverbasierte Website ist, sondern ein browserbasierter Client, lässt sich auch die Kommunikation zwischen Client und Server optimieren. So konnten wir in unserem US-Büro in Denver feststellen, dass der Dateizugriff mit unserem Cloud Desktop bis zu sechsmal schneller ist als mit einem Windows Fileshare. Das einfachere Einloggen durch die Möglichkeit des Verzichts auf ein VPN sowie die Möglichkeit einer Dateivorschau wurden dabei noch nicht einmal berücksichtigt.

Von Anfang an war klar, dass die Usability und das Design im Vordergrund steht. Deshalb wagten wir eine völlig neue Herangehensweise. Statt in der Softwareentwicklung entstanden die ersten Prototypen in der Marketing-Abteilung. Statt unsere Entwickler auf HTML5 zu schulen, bildeten wir unsere Grafiker zu HTML5-/CSS3-Entwicklern aus. Dadurch konnten wir sicherstellen, dass zum einen keine unnötigen Kompromisse beim Design eingegangen werden mussten und dass zum anderen die möglichen Reibungsverluste auf ein Minimum gesenkt werden konnten. Mittlerweile hat sich aus dem Marketing heraus ein Team gebildet, das übergreifend für das User-Interface und die Usability zuständig ist. Im HTML5-Kontext arbeitet dieses Team eng mit den HTML5-Frontend-Entwicklern zusammen, die den HTML5-Client mit der notwendigen Programmlogik ausstatten und die ihrerseits wiederum die Kommunikation zu den Serverentwicklern sicherstellen.

Deployment

Eine HTML5-Lösung ist eine echte Client-Software und keine serverseitige Website. Das Thema der Softwareverteilung entfiel deshalb vollständig. Als wir den HTML5-Client erstmals intern zur Verfügung stellten, schlugen einige Mitarbeiter bei unserer IT auf und fragten, ob sie den Client installiert bekämen. Erst nach der nochmaligen Erklärung, dass der Aufruf des Links genüge, glaubten sie uns das auch.

Fazit

Unsere Erfahrungen aus dem Projekt zeigen ganz klar: HTML5-Features sind heute schon machbar und führen zu hervorragenden Ergebnissen. Die Entwicklungszeit war, obwohl wir alle sehr viel lernen mussten, vergleichbar mit der mobiler Clients. Stellt sich letztendlich die Frage, was die Zukunft bringen wird und ob native Client-Entwicklung auch weiterhin Sinn machen werden. Aktuell ist die Antwort für komplexe Anwendungen wie unsere klar: Der native Client hat definitiv Vorteile (siehe Tabelle unten). Das wird auch noch die nächsten Jahre so bleiben, denn der HTML5-Client hat keine Möglichkeit, auf lokale Schnittstellen oder das Betriebssystem zuzugreifen. Doch hier zeichnen sich schon erste Veränderungen ab. Beispielsweise bietet Motorola in Rahmen seines Webtop SDK das USB-Interface als Webservice. RIM arbeitet mit dem WebWorks SDK für die nächste BlackBerry-Generation auch an diversen lokalen Funktionen. Entwickelt sich dieser Trend weiter, kann HTML5 endlich die Versprechen erfüllen, mit denen Java einst antrat. (sh)