DIE ZEIT goes Android

Möglicherweise ist es an der einen oder anderen Stelle schon ein wenig durchgesickert, seit heute ist es nun aber auch offiziell: die ZEIT-App für Android Tablets ist draussen und im Play Store erhältlich oder kann (allerdings nur auf Android Tablets) im Browser aufgerufen werden. Es gibt eine Probeausgabe, die gratis verfügbar ist, wer mehr ZEIT will, muss ein Abo abschließen.

Die App basiert auf den HTML5-Webviews, die auch schon in der iPad-App genutzt werden. Das ganze wird per JS mit einem Ausgabenmanagement, Inhaltsverzeichnis, viel drumherum und einer Swipingengine versehen. Lädt man sich eine Ausgabe herunter, wird sie in der Datenbank des Browsers abgelegt (derzeit noch ausschließlich WebSQL, die IndexedDB-Komponente ist noch nicht fertig). Was an Grafik und Gedöns nicht zu einer Ausgabe gehört wird über ein Cache Manifest gespeichert und im local storage des Browsers landen auch ein paar Daten. So kann man dann die Ausgabe, die man sich heruntergeladen hat auch offline anschauen, bspw. im Zug, ich bin da in den letzten Wochen begeisterter Tester gewesen. Das alles funktioniert mit dem Standardbrowser ab Android 3, besser aber im Chrome, noch besser unter Android 4, nahezu perfekt auf Nexus 7.

Nun kommt also die Zeit der Bugfixes und Reparaturen, das ist klar bei dem, was da draussen an Android Geräten herumgeistert. Wir haben zwar viele Tablets angeschafft und auf ihnen getestet, aber funktioniert und funktioniert, naja, man weiß ja schon.

So eine App wird ja von einer ganze Horde Menschen erstellt und gebaut. Da sind die Redaktion(en), das Produktmanagement, Agenturen mit denen wir zusammen gearbeitet haben. Alles tofte Leute, ohne die wir keinen Schritt tun könnten und denen ich hoffentlich nicht allzu sehr vor den Kopf stosse, wenn ich trotzdem an dieser Stelle ausschließlich mein Team namentlich erwähne, das in den letzten Wochen wirklich Außergewöhnliches geleistet hat: Anika Szuppa und Arne Seemann. Thanx a lot.

Habemus Nexus 7

Seit ein paar Tagen nenne ich ein Android-Tablet mein Eigen, wer hätte das gedacht?! Die Kombination aus Preis, Jelly Bean/Project Butter und dem wie ich finde handlichen Format hat wohl dazu geführt. Die zahlreichen Android-Tablets, die ich beruflich in den letzten Monaten in Augenschein nehmen konnte waren jedenfalls keine Werbung, insofern muss man sagen: trotz HTC, Sony, Acer und letztendlich Medion habe ich nun ein Nexus 7.

Kurzer Einschub: Ich weiss ja nicht, ob sie es wussten… Nexus oder gar Nexus 7 sind keine sonderlich einfallsreichen Markennamen. In der Industriegeschichte gab es unter diesem Namen schon alles, vom Motorroller bis zum Sexspielzeug (einfach mal bei Amazon suchen). Außerdem ist der Nexus wie jeder weiss das dämliche Star-Trek-Konstrukt in dem Picard und Kirk aufeinandertreffen. Und sicherlich nicht zuletzt ist Nexus-6 eine Baureihe von Androiden (!!!) in Blade Runner.

Zunächst einmal zum Format, nur damit das klar ist: wenn demnächst das iPad mini kommt und alle plötzlich voll auf kleine Tablets abfahren — also ich bin schon da. Überprüft jetzt schonmal, was ihr dazu in ein paar Wochen sagen wollt, nur so also Warunung. Ich steh‘ auf die sieben Zoll, vielleicht, weil ich so kleine Pianisten- Programmiererhände habe, und beim iPad die geteilte Tastatur zwar wie für mich gemacht ist, aber irgendwie dann doch nicht, weil ich damit nun mal nicht tippen kann. Geht einfach nicht. Das um Kilo leichtere Nexus liegt übertrieben ausgedrückt beim Tippen in der Hand wie ein Feder, jedenfalls im Vergleich zum iPad. Und man verbrennt sich auch nicht die Flossen dabei; man merkt den Quadcore-Prozessor bei der Rechenleistung und nicht als Abwärme an den Fingern. Und ich will jetzt nicht behaupten, dass 216ppi Retinadisplay wären, aber scharf ist der Nexusbildschirm trotzdem genug.

Aber das ist natürlich am Ende alles unwichtig, wenn es keine Software zu kaufen oder wenigstens geschenkt gibt. Und das gebe ich gerne zu, der Google Play Store ist zwar crowded, aber die wenigsten Sachen machen einen guten Eindruck. Da ist viel Kleinkram, Abgekupfertes und viel alter Wein in neuen Schläuchen dabei. Und es scheint Vorschrift zu sein, keinerlei gut gestylte Icons zu haben. Finden kann man im Google Play tatsächlich nur schwierig etwas, man braucht Blogs und Presseartikel, die einem den Weg zeigen. Aber, das ist ja im AppStore nicht anders. Allerdings: die wirklich wichtigen Apps gibt es alle auch für Android: 1Password, Google Reader, Dropbox, Kindle, Evernote, WordPress, Twitter, Facebook…

Außerdem funktioniert das Suchen, die Eingabe per Sprache (IMHO besser als bei Siri und ohne Widerworte), Google Music (hatte noch all die Songs die ich während der Beta einst hochlud, schluck), man kann Filme streamen (einen bekommt man auch geschenkt, obwohl… für Transformers III ist ja geschenkt noch zu teuer), Mail mit Gmail und Exhange (!) funktioniert, Kalender geht, Kontakte sind alle drin und so fort.

Nur eine Sache: verdammt, warum um Himmels willen gibt es denn kein 3G/4G? Nun muss ich jedes Mal mit dem iPhone tethern… das ist doch irgendwie uncool. 😉

Es wird werden

Wer mit der Entwicklung für das mobile Internet beschäftigt ist, liest und hört viel Text, in denen Worte und Formulierungen wie »wird«, »in Zukunft«, »demnächst«, »in Vorbereitung«, »Quartal X« oder »noch in diesem Jahr« die Hauptrolle spielen. Die Ankündigung hat sich in Sachen mobil zu einer eigenen Textgattung gemausert und man bekommt mithin den Eindruck, dass vielerorts nicht mehr auf Launches oder Produkteinführungen, sondern nur noch auf deren Ankündigung hingearbeitet wird. Im Vergleich zum »release early, release often« des Web 2.0, nun eher ein »talk early, release never«. Gerade nach großen Messen ist es dabei schwierig den Überblick zu behalten, da bspw. angekündigte Produkte von der Messe aus dem letzten Jahr vielleicht noch gar nicht am Markt sind, trotzdem aber schon neue angekündigt werden müssen. Schwierig auseinanderzuhalten ist da, was realer Plan und was feuchter Traum der Produktentwickler ist. Zumal dann auch schon mal das Produkt aus dem Vorvorjahr mit anders angeordneten Knöpfen und unter neuem Namen nochmal gelauncht wird, damit man irgendetwas hat.

Kommen nun zu etwas völlig anderem.

Aldi Nord hat gerade wieder das Medion-Android-Tablet im Angebot und ohne es genutzt zu haben, allein durch die Erfahrungen mit seinem Vorgänger, kann ich von der Anschaffung nur ausdrücklich abraten. Der Vorgänger glänzte ja nicht nur mit dem aus Entwicklersicht einmaligen Feature, dass der »Portraitmodus« dort ist, wo ein angetrunkener Produktdesigner das »Lifetab«-Plastikschild hingebappt hat und nicht da, wo ihn 99,99% aller Menschen inklusiver aller anderen Tablethersteller vermuten, sondern auch durch ausgesprochene Trägheit und Unterpowerung. Einmalig auch: der nicht abstellbare Startsound, zu dem unser Büro inzwischen an Micheal Jackson Thriller angelehnte Gruppentänze aufführen kann, weil man nach jedem Absturz… aber ich schweife ab. Aldi jedenfalls wirbt mit diesem einmaligen Slogan für das neue Gerät: »Android 3.2 vorinstalliert – Kostenloses automatisches Update auf Android 4.0 in wenigen Monaten verfügbar! (Hervorhebungen meine).

Letzteres habe ich inzwischen auch schon in einer offiziellen Version gesehen, nämlich auf dem Asus Transformer Prime und ich muss sagen: tatsächlich, das könnte etwas werden. Nun sieht Android 4 dort genauso aus wie 3.2, aber es läuft gut, und das ist das große Ding: die Beta des Google Chrome funktioniert. Es ist noch nicht alles verloren. Man muss allerdings anmerken, das »Prime« steht für definitiv nicht unterpowered und superteuer, der Vergleich mit der Aldikrücke verbietet sich. Dafür macht es beim Absturz nur ein niedliches kurzes Ping und meldet sich mit einem seichten Gong wieder zurück. Ja, genau…

Offline

Als Alternative zur Apptisierung des mobilen Internets wird immer wieder die Webapp genannt. Ebenso oft wird betont, dass native Apps den Webapps in UI und Features überlegen sind. Die Browser holen jedoch langsam auf, z.B. mit der Möglichkeit Geodaten zu lesen, oder auch Zugriff auf eine im Smartphone integrierte Kamera zu erhalten. Und dann ist das noch das Feature der offlinefähigkeit. Im folgenden will ich einige Techniken dazu kurz anreissen, zum einen um (mir) einen Überblick zu verschaffen, zum anderen um feststellen zu können, wie weit wir denn technologisch heute sind, in Sachen offline. Zum über den Onlinezustand hinaus gehenden Speichern von Daten stehen im wesentlichen drei Techniken zur Verfügung.

Offline weiterlesen

Lustiger Smartphonemarkt

Die Jungs mit den Androids in der Tasche weisen sich selbst ja immer gerne als Teil einer Massenbewegung aus, in dem sie feststellen, das Android täglich 700.000 Mal aktiviert wird, und das ist natürlich eine echt beeindruckende Zahl. Tatsächlich hat Android die Nase im mobilen Markt vorn, obwohl das vierte Quartal 2011 vor allem für iOS gut gelaufen ist. Laut Erhebungen der Nielsen Company holte Apple vor allem bei den neu verkauften Einheiten auf und stieg von 25% auf sagenhafte 44.5% (Smartphone Neuanschaffungen in den USA).

Zur selben Zeit tauscht man bei RIM, wohl auf Druck der Aktionäre, die beiden CEOs aus und ersetzt sie durch den ehemaligen Siemens-Manager Thorsten Heins. Der will nach eigener Aussage so weitermachen wie gehabt, bis auf eine Kleinigkeit:

It’s going to be continuity, but it’s not going to be a standstill.

Lustiger Smartphonemarkt. Wer hier für die künftige Mobilstrategie etwas herauslesen will: viel Spass.

Motorola, webOS, whatsoever…

Am 1. September 31. August erscheint die 25. t3n mit einem Artikel von mir (Infolink) zur Frage App versus Web, eine längere Fortsetzung meines Artikels hier. Nun, Papier ist zwar geduldig, aber oft schneller überholt, als es bedruckt wird, darum hier eine kleine Ergänzung zu einem Teilaspekt des Artikels, in dem ich die mögliche, zukünftige Verteilung der mobilen Clients versuche vorherzusagen. Die jüngsten Ereignisse um den Kauf von Motorola (durch Google) und den Verkauf von webOS (durch HP) dürften einen nicht marginalen Einfluss auf diese Zahlen haben.

Bisher wurde über die Auswirkungen des Motorola-Deals vor allem mehr oder weniger trefflich spekuliert. Tatsache ist, dass Google seine Android-Partner sicherlich stark verunsichert oder gar verärgert hat. Vor allem Samsung scheint sich das nicht gefallen lassen zu wollen und will wohl webOS von HP kaufen. Sollte der Deal so laufen, wird das natürlich starken Einfluss auf die Verteilung der mobilen Betriebssysteme in der Zukunft haben. Ob Google mit Motorola allein Android so erfolgreich in den Markt drücken kann wie bisher, halte ich eher für fraglich. Android war für mich aber bisher ganz klar der kommende Anführer bei den mobilen Systemen. Stattdessen die schon erahnte weitere Diversifikation durch webOS, von dem ich mir allerdings sicher war, dass HP es selber zum Einstieg in den Smartphone-Markt nutzen würde. Falsch gedacht. Wenn Samsung allerdings webOS kauft, müssen die es a) kräftig weiterentwickeln, damit es mit iOS und Android auch zukünftig konkurrieren kann und b) hohe Verkaufszahlen erreichen, damit sich die Investition dann auch lohnt.

Das wird auf jeden Fall spannend, denn zerfällt die Androidfront, ist ja wieder alles drin, von der totalen Zerstückelung des Marktes bis zur endgültigen Dominanz von iOS oder eines anderes Systems. Und wie schon angekündigt: schwierig in so einer Lage nur Apps für ein System zu bauen… ohne zu wissen ob man auf das richtige setzt. Genau solche Vorgänge spielen den Webapps den Ball zu. Ich hab’s ja gesagt.

Web gegen App?

Das sich das Netz entwickelt hat, weg vom Schreibtisch, hin zur Hand- oder Hosentasche, das haben wir nun alle mitbekommen. Seit ein paar Wochen scheinen sich allerorten Leute für die ideale Art der Entwicklung für das mobile Internet entscheiden zu wollen, die Frage lautet: »Web or App«. Da ich mit der Frage ebenfalls schon ein paar Wochen schwanger gehe (ihhh!), hier meine 2 Eurocents und am Schluss zwei Fragen dazu.

Getriggert wird das ganze derzeit durch die direkte Gegnerschaft in dieser Frage zwischen Apple und Google. Um es einfach und kurz auf einen Punkt zu bringen: Apple setzt im mobilen Web wenig überraschend auf native Apps, die durch die Cloud nach außen eine Feature- und/oder Speichererweiterung erfahren. Dieses Prinzip ist nicht neu und es wurde überhaupt von Microsoft erfunden, die aber mal wieder zu dämlich waren, es selbst sinnvoll umzusetzen (via ReadWriteWeb). Für Apple ist dabei vor allem eins wichtig, nämlich dass die Apps und die Cloud eben auf der eigenen Hardware stattfinden. Das Applegesamterlebnis aus Hard- und Software ist dann die unique selling proposition, die cash-cow und das goldene Kalb in Personaleinheit.

Demgegenüber steht Googles Idee von der Cloud und dem mobile web. Die hätten es gerne möglichst offen, am liebsten als Webapps. Das Google Betriebssystem vulgo der Google Browser zielen dabei am mobilen web noch ein wenig vorbei, aber die Macht von HTML5, Javascript und CSS läuft natürlich auch auf den Androids. Und während Apple seinen Appstore hat, um die Apps zu verticken, hat Google eben seine Suchmaschine und die findet nun mal (auch mobil) eher Webapps, als geschlossene Systeme.

Apple’s primary focus is on native Cocoa Touch and Cocoa apps running on iOS devices and Macs. Google’s primary focus is on HTML/CSS/JavaScript apps running in web browsers. Google is not getting away with less work. If anything, they’re doing more work, because it is harder to create good user experiences inside a web browser. Where Google benefits from its strategy is reach — Gmail and Google Docs run anywhere with a PC-caliber modern web browser. Cocoa apps run only on Apple-made devices. (John Gruber)

Wie Tim Bray so treffend feststellt, stehen sich also eigentlich die Entwickler von C++/Objective-C und Javascript gegenüber. Und er stellt auch fest, dass sich mit HTML/JS/CSS derzeit noch nicht auf einer Höhe mit Obj.-C u.ä. programmieren lässt, z.B. weil noch nicht alle APIs zur Verfügung stehen.

Wer jetzt auf den Zug mobile Web aufspringen möchte, muss sich nun also heute entscheiden. Und nachdem es einen wahren Run auf Apples App-Store gegeben hat in den letzten Jahren, könnte das Pendel nun ich Richtung Webapps ausschlagen. Facebook beispielsweise arbeitet an einer solchen App – wie man lesen kann, die Financial Times hat eine.

Interessanterweise wird aber ja selten auf technischer Basis entschieden, ob nun native oder Webapps gebaut werden. Im Gegenteil. Es geht um finanzielle Erwägungen und wichtiger – zumindest was die Herstellung von iPad-Apps anging – um Voodoo. Viele Glaskugeln® beispielsweise zeigten bis vor kurzem noch auf native Apps. So wurden viele viele Apps gebaut, ein paar sind sogar erfolgreich. Die Masse allerdings wohl eher nicht (genau wie im appfreien Web eben).

Am Ende geht es um die Frage der Monetarisierung. Da bietet die Welt der nativen Apps derzeit genau ein Modell an, den Apple Appstore. Und der ist erfolgreich. Wie Webapps zu Geld gemacht werden können bleibt derzeit noch offen. Das Geldverdienen mit Webseiten funktioniert ja derzeit hauptsächlich mit Werbung, die alte Leier. Zwei Fragen dazu:

  • Sind Webapps genauso wie Webseiten nur durch Werbung zu finanzieren, brauchen also die Massenmarkt, bestimmte Mengen an AdImpressions, mglw. sogar an Clicks?

  • Oder sind lassen sich Webapps so gestalten, mithin zum Luxusgut, dass sie als die Teil der Business Class im Netz direkt bezahlt werden könnten?

Hinter dem mobilen Proxy

Ich hatte jüngst großen Spaß mit dem mobilen Proxy der Telekomiker und—würde es nicht immer eine besonders störungsanfällige Nutzerschar treffen—ich würde glatt darüber lachen. Denkt man allerdings die Gutsherrenartigkeit mit der alle Mobilprovider mit unseren Websites im mobilen Netz umgehen konsequent zu Ende, wird einem leider Angst und Bange.

Erste Erfahrungen damit, das im mobilen Internet der Sourcecode einer Website beim Nutzer nicht so ankommt, wie man ihn am Server losgeschickt hat, hatten wir kurz nach dem Launch unserer iPad-Website. Eins der zahlreichen Scripte auf der Seite nutze einen <meta>-Eintrag im Head der Seite, um zu erfahren, in welchem Ressort es sich gerade befand. Informationen, die man zwischen Datenbasis und Frontend sicherlich auch bspw. mit Hilfe einer Klasse am <body>-Element übertragen hätte können. Aber unsere Templatehasen haben uns einst einen dicken <head> mit massig Informationen über die Seiten unserer Anwendung gegeben, warum sollte man die nicht nutzen und auslesen? Weil im mobilen Netz (zum Zwecke der Geschwindigkeitserhöhung) von den diversen mobile proxy alle <meta/> herausgefiltert werden, zum Beispiel.

Ok, das kann man ja noch verstehen, steht ja auch nichts drin, was so ein Handy, iPhone oder auch iPad im 3G-Betrieb brauchen könnte. Der zuckt der Entwickler kurz mit den Schultern und programmiert drum herum. Ein wenig komplizierter wurde es, als wir feststellten, dass im mobilen Netz nicht nur Daten aus dem <head> entfernt werden, es werden auch welche hinzugefügt. Dort verlinkte Javascripte bspw. werden komprimiert und direkt in den <head> ausgegeben. Das ist ja nett. Ich nehme mal an, ein derart aufbereitete Seite wird dann so gecached, spart ja auch reichlich Verbindungen. Technisch alles durchaus verständlich.

Und wenn man sich denn darauf verlassen könnte. Aber bspw. die Telekomiker verbessern ihre Systeme natürlich auch und da dieses Treiben nur wenig oder gar nicht dokumentiert ist, gibt es natürlich auch keine Releasetermine, keine Vorwarnung. Dass man wieder in die 3G-Falle gelaufen ist, merkt man genau dann, wenn der erste Nutzer sich meldet.

Dazu ein kurzer murphyesker, aber logischer Merksatz: Fehler am Livesystem werden immer zuerst von einem Nutzer entdeckt, niemals vom Entwickler.

Vor kurzem hatte also mein Lieblingsprovider wieder an seinem Proxy herumgespielt und folgendes Verhalten hinzugefügt: ähnlich wie die Javascripte wurden nun auch CSS statt wie vorgesehen verlinkt zu werden, direkt in den <head> geechoet, schick auf eine Zeile komprimiert. Das sollte weiter nicht stören, es sei denn man nutzt eine Technik zum Austauschen von verlinkten Styles zur Ladezeit. Dieser Hack um Stylesheets bei Bedarf zu dis- und/oder enablen funktioniert dann so gar nicht mehr.

Und wenn diese Technik dann für die Seite wichtig ist, dann kann man schon mal ins Schwitzen kommen. Die Lösung war in diesem Fall recht einfach: schreibt man statt <link rel="stylesheet" href="../styles.css"/> genauer <link rel="stylesheet" href="../styles.css" media="screen"/>, zeigt sich der Proxy derzeit gütig und lässt die Styles in Ruhe. Mal davon abgesehen, dass sich das leider morgen ändern kann, kann man nun auch keine @media innerhalb des CSS mehr machen.

Im Grunde ist das ja auch alles nicht so schlimm, so lange der Mobilprovider sich nicht auch noch am Inhalt der Seite zu schaffen macht. Es zeigt aber, dass eine iPad-HTML-Anwendung sehr viel defensiver gebaut werden müsste, als ich es bisher getan habe. Vielmehr muss man berücksichtigen, dass ein Tablet eben auch ein mobiles Device sein kann und dann eben den gleichen Restriktionen unterliegt, wie das schnöde Handy in meiner Tasche. Hier klafft imho noch eine mobile-Web-Smartphone-und-Tablet-Lücke, die sich auch darin zeigt, wie drastisch niedrig die Datenmengen von den Providern beschränkt werden (statt die Infrastruktur auszubauen oder die Technik zu verbessern). An Seiten, die eine Tonne wiegen und zwei Minuten Ladezeit bei UMTS auf die Ur bringen, hat der Nutzer in zweierlei Hinsicht wenig Freude.

One Web ist gar nicht so einfach.