Web Apps als Multi-Vendor-Strategie für Tablets

Der Tablet-Markt weist enorme Wachstumsraten und Wachstumschancen aus. Die Entwicklung von nativen Apps für die zahlreicher werdenden Betriebssysteme wird schwieriger und kostenintensiver. Bieten die »universellen« Web Apps auf Basis von HTML5 einen Ausweg?

er Tablet-Boom hält ungebremst an. So prognostizierten die Marktforscher von Gartner im April 70 Millionen verkaufte Tablet PCs für dieses Jahr und einen Anstieg auf 108 Millionen für 2012. Entsprechend rasant dürfte sich auch der Markt für Tablet-Applikationen entwickeln.

Angesichts dieser Marktprognosen stellt sich nicht mehr die Frage ob, sondern wann Tablets als Kanal für Kommunikationsmaßnahmen zu berücksichtigen sind. Das wiederum erfordert zumindest eine technische Erweiterung des digitalen Informationsangebots, wenn man der steigenden Zahl von Tablet-Anwendern Rechnung tragen möchte. Dabei sind zwei Szenarios zu unterscheiden:

· Tablet-Apps, die für die Öffentlichkeit bestimmt sind. Diese vermitteln frei zugängliche Informationen, beispielsweise über Produkte, Lösungen, Dienstleistungen, Veranstaltungen oder das Unternehmen selbst. Um möglichst viele Tablet-Nutzer mit dem Informationsangebot zu erreichen, wird man nicht auf nur ein Tablet-Betriebssystem oder gar nur einen Tablet-Hersteller setzen, sondern einen Multi-Vendor-Ansatz verfolgen. Die App sollte also idealerweise auf allen gängigen Tablets ablaufen und gleichzeitig die liebgewonnene Tablet User Experience unterstützen.

· In-house-Nutzung von Tablets mit »internen« Apps. Hier sind i.d.R. im Unternehmen von der IT-Abteilung nur Tablets mit einem bestimmten Betriebssystem beziehungsweise von einem Hersteller zur Nutzung freigegeben und integriert. Eine enge Verzahnung mit den Verfahren und Anwendungen des Unternehmens lässt sich dabei häufig nur durch eine »bodennahe« Programmierung effizient realisieren, also mit nativen Apps. Dadurch können Eigenschaften und Sicherheitsmechanismen eines Tablet-Betriebssystems optimal genutzt werden. Ein Vorteil, der nicht nur geschäftskritischen Anwendungen zu Gute kommt.

Obwohl iPad-Apps auf Grund der nach wie vor marktbeherrschenden Stellung des Apple-Tablets – laut IDC lag der Marktanteil des iPad2 im zweiten Quartal 2011 bei 68 % – eine beachtliche Reichweite haben, wird ein Multi-Vendor-Ansatz und damit das erste Szenario aus Marketing- und Kommunikationssicht immer wichtiger. Apple ist zwar mit dem iPad ein großartiger Wurf gelungen, aber sein Windschatten für erfolgreiche Kommunikationsmaßnahmen ist bereits kleiner geworden. Und auch wenn fast sämtliche Markt-Auguren dem iPad zumindest für die nächsten zwei Jahre eine weiterhin führende Marktposition vorhersagen, dürften iPad-Apps für breitenwirksames Marketing innerhalb einer stetig wachsenden Tablet-Gemeinde alleine wohl nicht mehr ausreichen.

Stellt sich also die Frage: Wie kann man sich mit der Artenvielfalt im Tablet-Markt arrangieren, ohne sich im Babel der Programmiersprachen zu verlieren? Eine Antwort darauf ist das Zurückgreifen auf Bewährtes in Form von Web-Applikationen. Denn mit HTML5, CSS3 und JavaScript lassen sich beachtliche Ergebnisse erzielen, die den Vergleich mit nativen Apps nicht scheuen müssen. Und durch Einbettung in einen nativen Rahmen ist selbst der Einzug in den prestigeträchtigen App-Store möglich.

Der Tablet-Markt boomt. Immer mehr Hersteller springen auf den Zug der Multitouch-Geräte auf, den Apple 2010 mit dem ersten iPad in Bewegung gesetzt hat. Zwar ist die Idee solcher Mobile Companions, die gänzlich ohne Maus und Tastatur auskommen, nicht neu. Aber erst die intuitive Steuerung durch Gestik hat zu dem unverwechselbaren Benutzererlebnis geführt, dass Tablets – allen voran das iPad – sich solch enormer Beliebtheit erfreuen.

Kein Wunder also, dass das als Mobile Device konzipierte Tablet all diejenigen Hersteller auf den Plan ruft, die sich ohnehin schon im Smartphone- und/oder Notebook-Markt tummeln. Fangen wir bei den vier wichtigsten Betriebssystemen an, die heute bereits auf Tablets zu finden sind:

Der Vollständigkeit halber sei hier noch HPs WebOS erwähnt, das aber aus heutiger Sicht eine eher unbedeutende Rolle spielen dürfte, auch wenn HP das Betriebssystem nach seinem Ausstieg aus dem Tablet- und Smartphone-Markt weiterführen möchte.

Folgende Gerätehersteller haben bereits Tablets auf den Markt gebracht beziehungsweise Prototypen vorgestellt, die demnächst auf den Markt kommen sollen (die Aufzählung erhebt auf Grund der Marktdynamik keinen Anspruch auf Vollständigkeit):

Acer, Apple, Archos, Asus, Dell, Fujitsu, Lenovo, Motorola, RIM, Samsung, Sony, Toshiba

HP hat sich – wie oben bereits erwähnt – als Hersteller aus dem Tablet-Markt verabschiedet und ist von daher auch nicht aufgeführt. Ebenso haben wir auf die Nennung der schier zahllosen Discounter- und exotischen beziehungsweise Nischen-Marken verzichtet, die hinsichtlich ihrer geringen globalen Marktpräsenz unseres Erachtens zu vernachlässigen waren. Erwähnen wollen wir aber noch das »Kindle Fire« von Amazon. Ein 7 Zoll Tablet-PC, der am 15. November 2011 in den USA auf den Markt kommen soll.

Während Apple und RIM als Hersteller von Hard- und Software mit ihren Produkten proprietäre Tablet-Lösungen anbieten, setzen die anderen Hardwarehersteller bislang größtenteils auf Googles Android-Betriebssystem für ihre Tablets. Zwar gibt es auch Hersteller, die mit Windows ihre Tablets befeuern, doch erst das angekündigte Windows 8 dürfte die Funktionalität mitbringen, die echtes Tablet-Feeling aufkommen lässt.

Die Zusammenfassung zeigt deutlich, welche Dynamik im Tablet-Markt herrscht. Nicht nur für die Unternehmens-IT, sondern auch für Unternehmenskommunikateure und -marketeers ein triftiger Grund, bei Tablet-Aktionen eine Multi-Vendor-Strategie im Blick zu haben.

Auf der einen Seite bietet die beschriebene Tablet-Vielfalt dem Verbraucher enorme Vorteile und verhindert eine Monopolisierung zu Gunsten eines Anbieters. Auf der anderen Seite erschwert genau dieser Aspekt die Entwicklung von Applikationen mit einer durchgängigen User Experience in beständiger Qualität. Denn bei den Herstellern Tablet-tauglicher Betriebssysteme setzt jeder auf eine andere Programmiersprache für native Apps (s. Abbildung).

Solange die App-Entwicklung auf ein Zielsystem beschränkt bleibt, muss der »Sprachvielfalt« keine Bedeutung beigemessen werden. Es kann auf eine native App mit all ihren Vorzügen gesetzt werden. Hierzu zählt normalerweise ein ausgereiftes API, das genau so funktioniert, wie es soll und weitestgehend aufwärtskompatibel bleibt.

Soll aber die Breitenwirkung durch weitere Zielsysteme erhöht werden, bedeuten native Apps einen deutlich größeren Programmieraufwand und dürften bei Budget-Verantwortlichen für eine spürbare Pulsbeschleunigung sorgen. Schließlich muss die App in mindestens drei verschiedenen Sprachen – wenn man bei Android und Windows auf C++ setzt – geschrieben werden. Aber selbst hier müssen sich C++-Programmierer in jedes API und damit Plattform einarbeiten, sprich sich spezialisieren.

Um sich nicht zu verzetteln, spekuliert der eine oder andere Hersteller nativer Apps auf Emulatoren, wie den für das PlayBook angekündigten Android-Emulator. Mit dem Android-Emulator sollen native Android-Apps auch auf dem PlayBook nutzbar werden. Ob es jedoch irgendwann einen Emulator für alle Plattformen geben wird, darf bezweifelt werden. Hinzu kommt, dass Emulatoren kein Allheilmittel sind. In der Regel sinkt die Performance in Emulatoren dermaßen ab, dass jeglicher Spaß abhanden kommt. Außerdem würden im Emulator die Oberflächen-Elemente »von der anderen Plattform stammen« und so visuell zusätzlich die User Experience (UX) stören. Bleibt letztlich bei der Suche nach dem Standard nur der Rückgriff auf Bewährtes. Und das sind in diesem Fall Web-Applikationen.

Wer auf Web-Applikationen für Tablets setzt, muss sich bewusst sein, auf den kleinsten gemeinsamen Nenner zu setzen. Gerade Webentwickler träumen ja eigentlich immer von einer Umgebung, in der man sicher sein kann, dass das Produkt immer so aussieht, wie man es programmiert hat. Die Realität sieht jedoch anders aus: Je nach Komplexität der Applikation kämpft man im Web immer wieder mit nervigen und verzwickten Unterschieden in den einzelnen Browsern. Das betrifft CSS ebenso wie JavaScript und bedeutet im Klartext, dass nach dem eigentlichen Programmieren zeitintensive Browsertests und -optimierungen beginnen. Doch was auf dem Desktop schon recht tückisch, aber auf Grund der überschaubaren Browser-Zahl noch akzeptabel ist, kann im mobilen Umfeld beziehungsweise Tablet-Segment recht schnell zum unersättlichen Zeitfresser werden. Bei Web Apps findet die Code-Interpretation im Browser statt. Für eine Tablet-taugliche App bedeutet das einen Test mit folgenden Browsern:

Dazu kommen dann noch die verschiedenen Geräte, was das ganze schnell exponentiell ansteigen lassen könnte. Die Entwicklung von Web Apps für Tablets ist folglich immer ein Balance-Akt zwischen Aufwand und Reichweite. Man sollte sich also darauf einigen, nur bestimmte Plattformen zu unterstützt – und zwar solche die einen am meisten Publikum aber am wenigsten Ärger bescheren. Das sind normalerweise Systeme mit Webkit-Browsern, sprich iOS und Android, womit man aktuell über die Hälfte der Anwender erreicht. Je nach angepeiltem Marktsegment sollte man dann noch den Aufwand für die Unterstützung anderer Browser abwägen. Mit jeder Plattform, die man hier zusätzlich aufnimmt, wachsen der Aufwand und die Anzahl der Kompromisse. Beispielsweise erlaubt ein Nokia-Browser nicht, die Anwenderkoordinaten auszulesen. Bei einer App, die dieses Feature für einen »Location Dependent Service« nutzt, müsste man den Browser abfragen und im Falle des Nokia-Browsers das entsprechende Feature ausblenden, damit gar nicht erst eine negative User Experience auftreten kann. Wirft eine Web App im Tablet-Umfeld also mehr Fragen auf als Antworten?

Glücklicherweise ist das Web ein ungemein dynamisches Umfeld mit einem hohen Evolutionstempo, das sich sozusagen ständig selbst optimiert. Allen voran das noch in der Entwicklung befindliche und vom World Wide Web Consortium (W3C) nicht verabschiedete HTML5, das HTML4 und XHTML ersetzen soll. Als Technologie-Hype mit einer großen Entwicklergemeinde ist HTML5 in seinen Möglichkeiten den nativen Apps dicht auf den Fersen. Die folgende Übersicht zeigt auszugsweise, welche für Tablets wichtigen Features HTML5 bereits heute bereithält und von welchen Browsern diese unterstützt werden (Quelle: mobilehtml5.org):

Mit diesen zu wichtigen Tablet-Browsern kompatiblen HTML5-Funktionen lassen sich beachtliche und nutzbringende Anwendungen kreieren, um Inhalte Tablet-optimiert bereitzustellen. Und das für Geräte verschiedener Hersteller. Außerdem bietet HTML5 zahlreiche weitere interessante und innovative Funktionen, mit denen sich mehr als nur darstellungsoptimierte Apps realisieren lassen. Das kann beispielsweise die 'Offline beziehungsweise clientseitige Datenbank' sein, die wir im Beispiel-Szenario weiter unten noch genauer betrachten werden. Desktop-Browser hinken hier noch deutlich hinterher, da die Verbreitung moderner Versionen nur sehr schleppend voran geht und somit Neuerungen wie HTML5 noch etwas länger auf Massentauglichkeit warten lassen dürften. In einer solchen App-Architektur wäre eine mögliche technische Durchführung so, dass man mobile Anwender auf eine andere Seite weiterleitet, um dort eine eigene Web App zu starten. Die Unterscheidung zwischen Websites für mobile Anwender und Desktop-Anwender ist schon lange Realität. Beispiele hierfür sind Wikipedia und Facebook (de.wikipedia.org → de.m.wikipedia.org, facebook.com → m.facebook.com). In diesem Fall würde das auch »Bootstrapping« genannte Starten der Applikation beinhalten, dass erstmal alle Dateien, die zum Betrieb der App notwendig sind, auf das Device geladen und dank HTML5 Application Cache gespeichert werden. Der zweite Aufruf/Start der App wäre damit wesentlich schneller. Das würde im Prinzip dem Download aus dem App-Store entsprechen. Eine solche App wäre eine echte »Online App«, die man dank HTML5-Funktionalität aber auch »offline« nutzen kann. Die App würde jedoch in jedem Fall erstmalig online über eine URL aufgerufen werden und wäre damit fernab vom App-Store. Die Web App der Financial Times ist ein Paradebeispiel für eine erfolgreiche Applikation mit Monetizing.

Eine Web App in Reinkultur schafft es in keinen App-Store – egal ob bei Android oder iTunes. Erhält die Web App aber eine Hülle aus nativen Funktionen, sieht die Sache schon wieder anders aus. Um die Store-Tauglichkeit nicht zu gefährden, sollte der native Überbau mehr bieten als eine reine Web-View, die eine URL aufruft, in der die Web App läuft. Ist die Web App aber beispielsweise durch PhoneGap in einer »nativen App« eingebettet, das heißt alle Dateien der Web App werden mit der nativen App ausgeliefert, sollte der Hybride eine Existenzberechtigung im App-Store haben.

Anhand eines einfachen Beispiels verdeutlichen wir den Weg von der herkömmlichen Web Applikation zu einer Tablet-optimierten Web App:

Ein Unternehmen stellt auf seiner Website einen Produktkonfigurator zur Verfügung. Mit Hilfe des Konfigurators lässt sich das Produkt in den angebotenen Farben visualisieren und mit Erweiterungen ausstatten. Abgerundet wird der Konfigurator durch einen Finanzierungsrechner, der abhängig von der geleisteten Anzahlung und dem aktuellen Zinssatz die Finanzierungsrate errechnet. Da der Konfigurator aus der Prä-iPad-Zeit stammt, ist er als Flash-Anwendung realisiert. Und damit haben alle iPad-Anwender das Nachsehen, denn Flash-Anwendungen werden nach wie vor von Apples iOS nicht unterstützt.

Prinzipiell gibt es mehrere Möglichkeiten, die iPad-Nutzer auch beim Konfigurator ins Boot zu holen:

· Entwicklung einer nativen iPad-App, die parallel zur Flash-Applikation im Web angeboten wird.
Vorteil: Native iPad-App, die im App Store angeboten werden kann.
Nachteil: Doppelte Pflege bei Aktualisierungen. Jede inhaltliche Änderung muss in der Flash-Fassung und der nativen App nachgezogen werden. Auch erfordert die exklusive Bereitstellung des Konfigurators im App Store einen – wenn auch minimalen – Kommunikationsaufwand. Denn auf gut Glück werden die wenigsten iPad-Anwender nach einer App-Variante für nicht darstellbare Flash-Anwendungen suchen.

· Ablösung der Flash-Applikation durch eine Web App basierend auf HTML5, CSS3 und JavaScript, die generell Tablet-optimiert ist.
Vorteil: Eine Applikation und damit einmaliger Änderungsaufwand bei Aktualisierungen. Keine Ausgrenzung oder Sonderwege für Tablet-Anwender einschließlich iPad-Nutzer. Besonderen Charme hat die permanente Aktualität einer Web App, da sämtliche Daten ja zentral auf einem Server liegen und nicht durch ein explizites Update der App auf den neuesten Stand gebracht werden müssen.
Nachteil: Als reine Web-Applikation ist der Konfigurator von einer Veröffentlichung in den meisten App-Stores ausgeschlossen.

· Hybrid-Lösung aus Web App und nativer App. Der Konfigurator mit seinen Auswahlmöglichkeiten und dem Finanzierungskalkulator bildet die Basis. Die Internet-Version der Web App ist Tablet-optimiert. Zusätzlich wird eine Hybrid-App mit nativen Erweiterungen als Store-Variante produziert.
Vorteil: Internet-Fassung und Tablet-Version basieren auf der gleichen Web App. Die zusätzliche Bereitstellung in einem Store erhöht die Reichweite des Konfigurators.
Nachteil: Die Komplexität der App nimmt zu mit jedem App Store, in dem die App angeboten werden soll. Ferner muss bei Änderungen am Konfigurator (beispielsweise Erweiterung der Konfigurationsmöglichkeiten) die Hybrid-App neu produziert und von jedem Anwender eigenverantwortlich durch ein manuelles Update auf dem Tablet aktualisiert werden.

Im Folgenden skizzieren wir kurz, wie der Konfigurator ohne Flash auf Basis von HTML5 umgesetzt werden könnte:

Im Bootstrapping-Prozess der App werden zunächst alle für den Betrieb der App nötigen Dateien wie Grafiken, Darstellungsgerüste, Programmcode und eine Datenbank auf das Gerät heruntergeladen und für die spätere Offline-Nutzung gespeichert. Möglich macht dies der HTML5 Application Cache. Da gewisse Teile des zu vermarktenden Produkts eingefärbt werden sollen, bringt die App für jede Szene zumindest eine Maske beziehungsweise Schablone mit, die im Vordergrund platziert wird und bei der die einzufärbenden Elemente ausgeschnitten wurden. Eine zweite Grafik bringt nun die zu färbenden Elemente in Form einer Grausstufenabbildung mit und wird so hinter der ersten Grafik positioniert, dass sie sich nahtlos in die Aussparung der Maske einfügt. Durch die Nutzung des HTML5-Tags <canvas> wird die Grausstufengrafik in eine Pixelmatrix verwandelt und ist somit bereit für die Bildbearbeitung aus dem Code heraus. Wählt der User eine Farbe aus, werden die Pixel der Graustufengrafik entsprechend eingefärbt. Dies geschieht trotz der Pixel-für-Pixel-Berechnung dank der hervorragenden 2D-Performance der Geräte in Echtzeit. Die Darstellung der Bedienelemente sowie der Farbpalette kann in geräte-typischer Optik geschehen. Nun geht es an den Finanzierungsrechner: Hierfür dienen die Daten als Grundlage, die im Bootstrapping der Applikation in Form einer Datenbank mit heruntergeladen wurden, denn dank HTML5 ist es möglich, im Browser eine eigene – wenn auch im Funktionsumfang etwas reduzierte – relationale Datenbank vorzuhalten und Abfragen auf diese auszuführen. Ein weiteres HTML5-Feature ist die Abfrage des Online-Status, womit die eigene Datenbank nach Möglichkeit in sinnvollen Intervallen (beispielsweise 1x täglich) mit der Online-Datenbank abgeglichen werden kann. So kann gewährleistet werden, dass die Finanzierungsberechnung auf einer akkuraten Preisbasis stattfindet. Die Darstellung zur Eingabe der persönlichen Daten für den Finanzierungsplan kann ebenfalls in gerätetypischer Formularoptik passieren. Die eigentliche Berechnung inklusive Datenbankabfragen findet nun komplett lokal auf dem Gerät statt. Zu guter Letzt kann die Zusammenstellung per E-Mail an den Anbieter gesendet werden.

Zahlreiche Tablet-typische Funktionen lassen sich bereits heute mit einer Web App abbilden. Aber ein Königsweg für plattformübergreifende Tablet-Apps ist die Web-Applikation auf Basis von HTML5, CSS3 und JavaScript nicht. Denn wie so oft steckt auch hier der Teufel im Detail. Das fängt mit dem User-Interface-Design an, bei dem die Web App Grafiken für Symbole und Bedienelemente selber stemmen muss, und endet mit dem Einbeziehen von Hardware-Elementen wie beispielsweise integrierte Kameras.

Als Faustformel lässt sich sagen: Je puristischer die App, desto sinnvoller scheint eine Realisierung als Web App. Dabei muss auf visuelle Effekte keineswegs verzichtet werden, denn auch mit HTML5 lassen sich – ganz ohne Flash – überaus ansprechende Animationen verwirklichen. Für die Web App spricht auch die Verfügbarkeit von Entwicklungsressourcen, die deutlich höher ist als bei nativen Programmiersprachen, von denen für manche auf Grund ihres Spezialisierungsgrads fähige Programmierer Seltenheitswert haben dürften.

Ein weiterer wichtiger Aspekt ist die Bereitstellung der Applikation. Ist eine Veröffentlichung in den Stores der verschiedenen Anbieter geplant, gibt es nur zwei Möglichkeiten: Hybrid-Anwendung, also eine Web App mit einer jeweils nativen Verpackung, oder native App. Hier ist zu überlegen, ob Hybrid-Apps die Komplexität nicht weitaus stärker erhöhen als eine konsequente Entwicklung als native Apps. Das wiederum hängt von der Funktionalität der geplanten App ab.

Aber egal ob Hybrid- oder native App – in jedem Fall sollte vermieden werden, mit einer App auf allen Tablet-Hochzeiten tanzen zu wollen. Eine Fokussierung auf wenige wirklich wichtige Geräte und deren gängigste Browser führt schneller zum Ziel als der Versuch, eine eierlegende Wollmilchsau zu erschaffen. Denn auch für Tablet-Apps gilt: Weniger ist manchmal mehr.

Die Autoren

Alexander Buch

Alexander Buch ist seit April 2011 unter dem Namen »Keen Code« als freiberuflicher Webentwickler auf der Suche nach neuen Herausforderungen. Ihn begleitet unter anderem Expertenwissen zu den Themen TYPO3, PHP, MySQL, JavaScript, HTML & CSS, das er sich in langjähriger Berufserfahrung angehäuft hat. Zudem interessiert er sich für die neuesten Entwicklungen des Web und ist sowohl von Webtechnologien als auch dem mobilen Markt überzeugt. Privat hat er einen Hang zu übermäßigem Teekonsum und lauter Gitarrenmusik.

Peter M. A. Kasprzyk

Gemeinsam mit Olaf Bethke gründete und leitet Peter Kasprzyk die Communeer GmbH. Zu den Stationen seiner beruflichen Laufbahn zählen unterschiedliche Tätigkeitsbereiche und Funktionen, u.a. Technischer Redakteur und Autor, Product Line Manager, Internet Manager, Leiter der Kommunikationsplanung und -strategie des Siemens-Geschäftsgebiets Enterprise Systems sowie Geschäftsführer der MMK GmbH. Als »Trekkie« und Fan intelligenter und humorvoller Science-Fiction-Literatur begeistert er sich seit dem Aufkommen des iPads für die vielfältigen Einsatzmöglichkeiten von Tablet-PCs.

Copyright © 2003-2012 ap Verlag GmbH