Zunächst mal glaube ich nicht, dass Google mit AMP traffic stiehlt. Natürlich läuft der Datenverkehr über Googles Cache und schlägt so nicht auf dem hauseigenen Server auf, aber gezählt wird er, wenn man ihn zählt, als eigene views, pageipressions, visits, whatsoever. Falls einen das groß artiginteressiert. Das ist aber der große Vorwurf des Artikels, man rufe AMP-Artikel auf und sei dann dort in einem dead end gefangen und könne als einzige Möglichkeit zurück zur Google-Suche. Das mag so sein, wenn man einfach das WordPress-Plugin installiert und einschaltet und sich nicht weiter darum kümmert, was an AMP-HTML dabei heraus kommt. Wir haben AMP für ZEIT ONLINE implementiert und das war mehr Arbeit, als ein Plugin einzuschalten. Wir liefern eine spezielle Version unsere (responsiven) Seite aus, die, so gut es geht, die AMP-Erweiterungen nutzt, also spezielle Adtags, Imagetags und so weiter nutzt. Das WordPress-Plugin versucht die Standard-Wordpress-Elemente automatisch in AMP umzusetzen und macht das erstaunlich gut. Trotzdem kann es natürlich sein, bspw. bei selbstgestrickten Templates, dass der Ergebnis nicht so ist, wie man möchte. Das mag ein dead end produzieren, das ist dann aber eher nicht AMPs Schuld.

Ich habe mich bisher um meine AMP-Seiten auch überhaupt nicht gekümmert, wie sie aussehen sieht man hier. Warum ich mich noch nicht darum gekümmert habe: im Moment läuft da für mich noch nicht wirklich etwas. Derzeit gibt’s AMP-Ergebnisse im Grunde nur in Google-News und in einer speziellen Box, da läuft in der Regel nur Medienverkehr, bei ZEIT ONLINE hat das durchaus Bedeutung, für das Couchblog heisst das bisher no amp in the moment. Eine geplante flächendeckende Einführung in Suchergebnissen ist zumindest international noch nicht fertig umgesetzt, aber für das Jahresende angekündigt. Insofern hat es für mich noch keine Relevanz.

Was mich wirklich in Sachen AMP ein wenig nervt, ist was auch in diesem Kommentar eines AMP-Entwicklers nochmal durchscheint, nämlich dass AMPs ja auch an anderen Stellen als nur der Google Suche erscheinen könnten, bspw. in Twitter oder Pinterest. Twitter ist seit den ersten AMP-Tagen immer mal wieder genannt worden, ausser in twitter moments ist davon aber weit und breit nichts zu sehen. Das ist gelinde gesagt sehr schade, weil mit höherer Verbreitung der AMP natürlich auch das Ansehen steigen würde und sich zeigen würde, dass es um mehr geht, als Content für die Google Suche zur Verfügung zu stellen. Dabei sind AMP, wenn sie sich verbreiten, einerseits eine wundervolle und vor allem offene Alternative zu Facebook Instant Articles, andererseits ein guter Satz Daumenschrauben, die Google mit dem Suchtraffic als Pfand den krankhaft langsamen Newswebseiten anlegen kann. Zusammengenommen ein guter Schritt in Richtung schnelleres Web.

Bild: William Bout

Update: Nach längerem Test habe ich die AMP-Unterstützung wieder dran gegeben.

Chris Win hat das neue iOS einigen ausgesprochenen Nicht-Profis gezeigt, da die Diskussion unter seinen Design-Kollegen doch ziemlich zerstritten ist. Chris kommt direkt zum Punkt:

Everyone is entitled to an opinion, but a design can be objectively bad. Despite some important functional design improvements, much of what Apple displayed at WWDC was simply not show-quality.

Da stimmt er mit mir und vielen, vielen, sehr vielen Stimmen im Netz bis hin zu Erik Spiekermann überein. Cap Watkins ist mehr oder weniger auch dieser Meinung, mag es aber nicht aussprechen. Stattdessen vertritt er die Ansicht, dass sozusagen dort wo gehobelt wird, eben Späne fallen:

Today, Apple pressed the big reset button on their entire OS and aesthetic. Sure, the functionality is still, largely, there. But they’ve essentially taken the last six years of tweaking, touching-up, honing, and revising and wiped it all away to begin again. To learn again. To hone from a new, unknown place.

Was ziemlich pathetisch klingt. A land, where no man has gone before. Wofür er allerdings wirbt ist, Apple den anfänglichen Fail zuzugestehen, so wie wir es bei der seit Jahren üblichen Strategie launch quickly, learn quickly, and polish as we go ja auch immer selbst machen. Und man hat ja durchaus genug gemeckert die letzten Jahre, über das veraltete Design mit Lederimitat und den anderen Skeuphormismen. Das dies zur kompletten Entstellung führen darf, zweifelt Chris Win natürlich an:

iOS 7 misses the mark when it comes to user interface design. Take the new Control Center, for example. Does a black icon mean a button in its active state, or is the white icon active? You’ll learn once you start using it, I guess.

The controls also lack negative space. Buttons and widgets are crowded together. Apple has always stated clearly that control groups should allow comfortable target zones, particularly with touch.

Maybe this will change. Maybe Apple knows it’s wrong or unfinished. But then what the hell are they doing showing it?

Was ranten wir dafür immer wieder über Microsoft. Was haben wir uns über die Präsentationen bei Samsung lächerlich gemacht. Immer aus der Warte heraus, Nutzer der bestdesignten Notebooks zu sein, die beste Software zu benutzen, das beste mobile Betriebssystem. Über das wir natürlich trotzdem immer gemeckert haben, weil wir der Ansicht waren, Apple könnte es tatsächlich noch besser machen. Jammern auf sehr hohem Niveau. Cap Watkins dazu:

For the last couple of years we’ve all complained, jeered and teased our phone-maker-of-choice for not totally revising their UI. For using felt. For using leather stitching. They’re falling behind the times, we said. They need to revolutionize their interface.

Kein Grund mit halben Kram zu kommen, meint auch Chris Win:

Apple is following in this area, where once they led. They had purpose in their user interface designs. They set the standard and showed finished products. They inspired designers and copycats. Who will copy that home screen, with its mess of over-saturated, child-like icons? Who can tell me the beautiful, subtle detail of the previous camera lens icon should be replaced with a black blob?

Und trifft, wie ich meine einen wichtigen Punkt. Bei Apple hat sich etwas verändert. Es ist schwer zu ertragen, dass eben die Firma, die in den letzten Jahren den Staffelstab in Sachen mobile Design und Smartphone-UI in der Hand hielt, sich nun eingereiht hat in die Riege derjenigen, die halt auch mal mit etwas halbfertigem an den Markt gehen. Hier antwortet Watkins mit Optimismus:

It will get better. It will be honed. They’ll spend the next six years polishing this interface until we’re complaining that it’s not real-looking enough. Not directly-connected-to-our-brains enough. Not whatever enough. And they’ll revolutionize it again. And we’ll complain.

Sechs Jahre?! So optimistisch ist das vielleicht gar nicht. Ich kann mich nicht erinnern, dass bei derPräsentation des iPhone 1 etwas derartig unfertiges abgeliefert worden wäre, dass man nun die letzten sechs Jahre verfeinert hätte. Da kommen harte Zeiten auf uns zu. Sieht auch Win so:

Everyone seems to agree this was a big moment for Apple. It is a time to reclaim the mantle of innovation and quiet the naysayers who have become skeptical of Tim Cook’s Apple. But if this is the future — following and not leading on software design — we are in for a rough ride. They have until September to finish this draft. I sure hope they do.

Ich habe ja zum Glück noch ein zweites Telefon, ein Nexus 4. Mal sehen wie Android dann in sechs Jahren aussieht.

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.

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.

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…

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.

DOM Storage #

Als DOM Storage bezeichnet man einen kleinen, leicht zugänglichen Speicherbereich, auf den vom Browser über eine sehr einfaches Interface zugegriffen werden kann: es werden jeweils Key-Value-Paare gespeichert. Das DOM Storage kommt in zwei Ausführungen: als Localstorage ist der Speicher persistent, als Sessionstorage hält er nur bis zum Sessionende.

DOM Storage besticht vor allem durch die Einfachheit mit der man ihn nutzen kann und ist zudem weit verbreitet. Deswegen wird er wohl vielerorts als das Schweizer Messer der Offlineapplikationen angespriesen; ja, das wäre ja zu schön… die Wahrheit ist: DOM Storage is considered harmful, vor allem wegen seiner grausigen Performance. Zudem ist die Menge an Speicher, die man damit zur Verfügung bekommt ziemlich klein. Unter iOS stehen wohl nicht mehr als 5 MB zur Verfügung, da kann man eh’ keine großen Sprünge machen, auch wenn Androiden und Desktopbrowser mehr Speicher zu lassen.

Application Cache #

Die Mutter der Offlinefunktionalitäten dürfte der Application Cache sein. Hier steuert man unter Zuhilfenahme einer Manifest-Datei, welche Dateien der Browser für die eigene Webapp in den Application Cache legt. Der Clou dabei ist, dass im Offlinezustand diese gecachten Dateien völlig transparent zur Verfügung stehen. Ohne die Meldung »Ey Alter, geh’ mal online« werden Bilder aus dem Cache geladen und Scripts interpretiert. So sollte es jedenfalls sein. Hier zeigt sich der Browser called Browser (aka. Android-Webkit) aus Android 3.2 etwas unwillig und beschwert sich per Popup, das man ja nun offline sei, nur um danach alles wie gewünscht zu verarbeiten.

Für den Application Cache gibt es auch etwas Javascript-Interface mit dem man bspw. den Cache leeren kann. Auch gut geeignet zum Debuggen, denn wegen der oben erwähnten Transparenz, sind Fehler manchmal etwas schwierig zu finden. Hilfreich: hier kann man seine Manifest-Datei validieren lassen. Wermutstropfen Nummer eins: auch der AppCache wird durch das störrische iOS auf einer Untergrenze von 5 MB festgenagelt.

Browserdatenbanken #

Wer bis hier mit den vorgeschlagenen Möglichkeiten zurecht kommt, oder mit anderen Worten: wer nicht mehr als 5 MB offline zu speichern hat, der hat Glück gehabt, denn er ist nicht auf die DB-Funktionalitäten der modernen Browser angewiesen. Diese stellen zwar wesentlich mehr Speicherplatz zur Verfügung, selbst im mobile Safari kann man, nachdem der Nutzer zugestimmt hat, bis zu 50 MB Daten in Datenbanken speichern und offline wieder abrufen. Trotzdem steht man derzeit vor einem Schlachtfeld.

Auf der einen Seite steht WebSQL, dass zwar in vielen Browsern zur Verfügung steht (Chrome, Opera, Safari, Android Browser…), aber vom W3C letztendlich verschmäht wurde, weil alle Browserhersteller das gleiche Backend nutzten. Stattdessen arbeitet man nun an IndexedDB. Das wäre sicherlich eine genauso gute Lösung, ist aber zumindest zum heutigen Zeitpunkt nicht gerade verbreitet: Firefox kommt seit Version 4 damit, Chrome (ab 12) kann beides, IE 10 wird es haben hat es, eines Tages. Der neue Chrome für Android kommt ebenfalls mit IndexedDB. Momentaner Stand hier ist allerdings, dass sich die Implementierungen doch noch sehr stark unterscheiden, zwischen den Browsern, aber vor allem auch von einer Browserversion zur nächsten, die ja heutzutage praktisch wöchentlich kommen…

Da muss man sich dann natürlich fragen, ab wann sich der Aufwand lohnt, denn um eine Browser-Offline-Datenbank-Anwendung zu schreiben, braucht man schon ein paar ausgewachsene Abstraktionsstufen, um die Daten in allen Browsern ordentlich wegzuschreiben und auch wieder zu finden…

Ein Fazit #

Es ist nicht alles Gold, was sich HTML5 nennt. Beim Storage geht es jedenfalls, vor allem bei den Datenbanken noch sehr holprig zu. Somit liegt die Grenze für Offlinedatenspeicherung doch sehr sehr sehr niedrig. Definiert wird diese Untergrenze regelmäßig von den iOS-Geräten, man könnte Apple verdächtigen, den Webapp-Entwicklern Steine in den Weg legen zu wollen, um seine liebgewonnene App-Welt zu schützen, aber andererseits, man will ja auch keine Verschwörungstheorien verbreiten.

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.

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.

Bild: Nasa: Space Colony Art from the 1970s, via The Public Domain Review.

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?

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. Da 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.

Artikelbild: Some rights reserved by Masked Malayan