Wer sich mal mit der Aufgabe “automatisierte Screenshots erstellen” beschäftigt hat, weiss, dass es sich um ein ätzendes Thema – oder Neusprech: eine echte Herausforderung – handelt. Nicht umsonst gibt es hunderte unfertige Tools und etliche kostenpflichtige Services dafür. Und alle können Flash nicht oder nur unzureichend abbilden.

Google führt damit seine jüngste Firmenpraxis, nach der Flash nicht evil ist, weiter. Den/Uns HTML-Standard-Evangelisten wird ein weiteres Argument aus der Hand genommen, Kunden Flash auszureden. Das ist nicht weiter schlimm, weil andere Argumente einen immer größeren Marktanteil gewinnen.

Aber dennoch stellt sich die Frage, warum Google als Firma-gewordene Inkarnation der guten Seite der Macht (zumindest aus Sicht vieler Entwickler), dieses Kainsmal des Webs unterstützt.

Die Antwort dürfte schlicht und einfach sein: Weil sie es können.

Kein Konkurrent scheint in der Lage, mit dem Entwicklungstempo von Google mitzuhalten. Und diese Entwicklungen sind in vielen Fällen kleine Erweiterungen, die für den Wald- und Wiesen-User den eigentlichen USP von Google ausmachen. Sei es Streetview oder ein offener DNS, seien es Docs oder eben Preview-Images von Flash-Sites, die User erhalten ein Rundum-Wohlfühl-Paket, was sie davon abhält, andere Services zu benutzen.

Also steckt dahinter vermutlich keine Agenda zugunsten von Flash. Hoffentlich …

Mit einem Browser-Marktanteil von rund 10% (12+% in den Staaten) hat Chrome eine Verbreitung erreicht, die für Site-Betreiber relevant ist. Wenn dieser Browser in Zukunft die derzeit einzige Alternative zu Flash-Videos nicht mehr unterstützt müssen sich Sitebetreiber eine Alternative überlegen. Die Lösung wird für die meisten sicher nicht darin bestehen, alle Videos zusätzlich als WebM-Video anzubieten. Wer diesen Aufwand scheut wird wieder bei Flash landen. Die Massage von Google richtet sich also an die ZDFs und BBCs der Welt und lautet: “Hört auf, eure Flash-Player durch HTML5-Player zu ersetzen.”

Es gibt inzwischen vernünftige Browserweichen, die den iOS-Usern den Video-Tag mit H.264 geben und anderen den Flash-Player einspielen. In Zukunft werden diese Weichen eine weitere Regel abfragen: if(USERAGENT.indexOf(‘Chrome’) != -1) ladeFlashPlayer();

Eine schlechte Nachricht für das Netz, für Chrome-User und für Android-User. Und ein neues Zeichen (nach der Ankündigung eines Tablet-only Android 3), dass Google keine langfristige Strategie hat.

[Update] Google fühlt sich offensichtlich nach der massiven Kritik (u.a. daring fireball und zdnet) genötigt, sich näher zu erklären. Ausserdem kündigen sie (in einem Update der Erklärung) an, für Safari und Explorer WebM-Plugins anzubieten. Mit Hilfe von ‘canPlayType’ (JS-Funktion, die z.B. bei der Frage canPlayType(‘[mime-type];[codec="codec-string"]‘) z.B. den Wert ‘maybe’ oder ‘probably’ zurückgibt) sollen dann auch diese Browser WebM abspielen können. Allerdings ist dies nach meiner Meinung keine optimale Lösung, da die meisten Browserweichen wahrscheinlich eher nach Browser/OS entscheiden werden, welche Video-Player-Lösung ausgeliefert wird. Ausserdem würde mich sehr wundern, wenn über die Plugin-Schnittstelle dieser Part des Browsers ohne weiteres angesprochen werden kann.

Irgendwie scheint sich meine Vermutung, Google hätte keine langfristige Strategie, zu bestätigen. Offensichtlich haben sie nicht mit so einem Sturm der Entrüstung gerechnet und versuchen jetzt die Wogen zu glätten. [/Update]

[Update2] Unter dem Titel “The Ambiguity of ‘Open’ and VP8 vs. H.264” ist ein ausgezeichneter Artikel über die Plug-In-Frage erschienen. Besonders interessant sind die Ausführungen über die Erweiterungsmöglichkeiten von Firefox, Chrome und Opera vs. Safari und IE9. Erstere spielen Videos über eigene Decoder ab, letztere handeln den video-Tag über die OS-eigenen und vor allem erweiterbare Decoder ab. [/Update2]

Ich glaube das nicht!

Die Frage ist nämlich nicht “HTML5 oder Apps?” sondern “HTML5 oder native Apps?”. Denn das Konzept der Apps hat mit der verwendeten Technik nur wenig zu tun. Apps sind nicht wegen des Einsatzes von HTML5, Flash oder Objective-C erfolgreich. Apps sind vor allem erfolgreich wegen des Distributionskanals.

Schon aus Usability-Sicht ist diese Tatsache merkwürdig. Beispielsweise kann man den ibis reader mit drei Klicks auf einem Gerät installieren. Ein vergleichbares Programm aus dem Apple App Store oder dem Android Market benötigt – je nach Situation – deutlich mehr Interaktionen des Users.

Betrachtet man Themen wie Privatsphäre und Sicherheit von Bankdaten spricht – zumindest bei kostenlosen Apps – ebenfalls einiges gegen die App-Stores.

Warum also haben sich mobile Apps erst mit App-Stores durchgesetzt?

Schon Urzeiten im letzten Jahrhundert konnte man sich Programme für Windows CE oder Symbian von verschiedenen Quellen laden und installieren. Sites wie tucows listeten eine Unmenge kostenloser Programme. Mit ein wenig Geduld und Forschergeist fand man manchmal ein nützliches Tool, das dann genau für die Betriebssystemversion und den jeweiligen Prozessor verfügbar war. Die Sicherheitswarnung bei Symbian, dass das Zertifikat von einer nicht vertrauenswürdigen Quelle stamme und sowieso abgelaufen sei, konnte man getrost ignorieren. Die gleiche Meldung kam ja sogar bei Programmen von Nokia selbst. Die eigentlichen App-Stores waren damals allerdings die Tauschbörsen. Route66 wurde sicherlich hundert mal mehr getauscht als gekauft. Bei einem Preis von mehreren 100 DM nicht überraschend.

Der wichtigste Grund für den Erfolg von App-Stores und damit auch Apps ist daher offensichtlich, die schlechte Erfahrung der Early Adopter mit anderen Möglichkeiten des App-Vertriebs. Testversionen mit nervigen Hinweisen, Probleme mit Lizenzen, die man mal erworben hatte, Plattform-Hazzl, die Liste der bad experiences ist endlos. Ein App-Store, der einem nur die Programme zeigt, die man auch tatsächlich laufen lassen kann und noch dazu die Abrechnung übernimmt senkt die Hürden für den Anwender erheblich. Heute kaufen und installieren selbst die Laggards Apps.

Ausserdem scheinen die App-Stores das verbreitete Bedürfnis des Jagen und Sammelns zu befriedigen. In meinem Umkreis tummeln sich immer mehrere twitter-, Wetter-, RSS- und Fahrplan-Apps auf den iPhones. Jeder scheint auf der Suche nach der noch besseren App für einen noch spezielleren Anwendungsfall zu sein. Statistiken über die Nutzungshäufigkeit sprechen eine eindeutige Sprache: die meisten Apps werden selten aufgerufen und sind schnell dem Vergessen anheim gegeben.

Warum jedoch gibt es keinen HTML-Appstore?

Viele Apps – zumindest im App Store von Apple – sind reine HTML-Programme eingepackt in eine Applikationshülle. Oft wird dafür PhoneGap eingesetzt. Wir selbst haben bereits mehrere solche Projekte umgesetzt (u.a. me.style vom musikexpress). Unabhängig davon, ob es sich um eine Medien- oder eher um eine UI-lastige App handelt entscheiden wir uns eigentlich immer für HTML als technische Basis. Der Hauptgrund ist schlicht Opportunismus: wir wollen neben der iOS- immer auch die Android-Version verkaufen. Nein, Scherz beiseite! Ich bin überzeugt, dass in Zukunft auf allen Plattformen HTML (oder eine geeignete Nachfolgerin) das geeignete Mittel für die Umsetzung von User Interfaces ist.

Für die Zukunft ergibt sich daher ein sehr merkwürdiges Bild: die meisten Apps werden in Objective-C (iOS, Mac OSX), Java (Android) oder C++ (Symbian, RIM) gepacktes, identisches HTML sein. Sowohl für die Kunden der Entwickler als auch für die Nutzer der Programme bleibt dieser Fakt allerdings verborgen. Ebenfalls verborgen bleiben allen auch die Mehrkosten die dadurch entstehen.

Eine sinnvolle Lösung könnte ein App-Store für HTML-Programme und Widgets sein, betrieben von einem großen Marktplayer wie z.B. Amazon. Ob und wann es jedoch soweit sein wird, darüber kann man momentan nur spekulieren.

In der ersten Version wird der Player offensichtlich noch keine Pre-Rolls unterstützen. Aber ich bin mir sicher, dass Playlists mit dem Framework sehr einfach zu implementieren sind. Auch Skins und Themes dürften per CSS sehr leicht umzusetzen sein.

Für die Broadcaster stellt sich nun nur noch die Frage, ob sie Firefox mit Ogg unterstützen wollen, oder lieber nur H.264 verwenden möchten, das von Webkit und Flash geladen werden kann (und offensichtlich eine wesentlich bessere Qualität bietet). Mit Ogg wäre der Speicherbedarf größer und Caching und CDN aufwendiger.

Um sicher zu sein, dass es sich wirklich um einen HTML5-fähigen Browser handelt kann man ja vorher noch einen Test machen …

Die Erweiterung von Betriebssystemen oder anderen Drittanbieterprodukten oder -geräten, wie dem iPhone oder iPad wird schwieriger für unsere Produkte wodurch unsere Nutzer gewogen sein könnten, andere Technologien zu benutzen, was unser Geschäft beeinträchtigen würde.

Adobe hat heute öffentlich bekannt gegeben, dass sie ein wirtschaftliches Problem mit Apple haben. Insbesondere haben sie ein Problem mit der Tatsache, dass Apple kein Flash mag. Denn Adobe mag Flash. Lange Zeit war Adobe sogar davon überzeugt, dass man mit Flash Geld verdienen könne. Unklar bleibt allerdings, warum sie es nie getan haben. Im Verkauf von X-Trillionen CS[x]-Lizenzen war kein Sex.

Der Sex sollte darin bestehen, an jedem gestreamten (kopiergeschütztem) Medium Geld zu verdienen. Nur leider haben sie es nicht geschafft, die dazu notwendige Infrastruktur aufzubauen. Sie haben sich sogar die Firma (On2), die die Rechte an dem wichtigsten Codec (VP8) für Flash-Videos hatte, von Google vor der Nase wegschnappen lassen. Adobe kauft lieber Omniture, da es doch für die Werbetreibenden extrem wichtig ist, die Reichweite zu messen.

Mit der Meldung von Adobe an die SEC, dass die momentane Politik von Apple ein wirtschaftliches Risiko für das eigene Geschäft darstellt, hat Adobe eingestanden, dass sie auf das falsche Pferd gesetzt haben. Dabei hatten sie schon 1999 SVG. Sie hatten sogar einen Applicationserver, der Flash aus SVG (kind of) generieren konnte.

Sie hätten in den letzten 10 Jahren zu jedem beliebigen Zeitpunkt eine IDE auf den Markt bringen können, die – dem Flash-Editor ähnlich – Animationen ins Web hätte bringen können. Sie wollten es nicht. Und dann kam irgendjemand (Welcher Idiot war das eigentlich?) auf die Idee, dass man mit Flash doch Filme im Netz verbreiten kann.

Und spätestens an dieser Stelle hätte jemandem auffallen müssen, dass es einer anderen Firma auch nicht gut ging, nachdem die meisten Filme mit deren Technik publiziert wurden: Real. Auch diese Firma dachte, dass nun die ewig sprudelnde Quelle gefunden sei. Bewegte Bilder? Real Video. Keine Frage!

Das ist noch nicht mal zehn Jahre her. CompuServe, Real, Imode (to be continued …)

Adobe hätte eigentlich schon 2005 eine Nachricht an die Börsenaufsicht schicken müssen:

Durch den Kauf von Macromedia Inc. haben wir uns in eine Situation gebracht, die es uns erheblich erschwert, flexibel am Markt zu agieren. Die Wünsche einer großen Anzahl von Werbetreibenden und Entwicklern werden uns in Zukunft daran hindern, strategisch sinnvolle Entscheidungen zu treffen. Früher oder später wird uns das auf die Füsse fallen. Mit erheblichen Risiken ist zu rechnen.

Sowohl bei der Bild (http://wap.bild.de/), der Sueddeutschen (http://m.sz.de/inm/sz/), beim Westen (http://mobil.derwesten.de/) als auch beim Stern (http://mobil.stern.de/op/stern/de/ct/) wird der iPad-Nutzer derzeit automatisch auf die mobilen Versionen der Sites umgeleitet. Diese sehen bei der hohen Auflösung nicht wirklich sexy aus. Einzig die Zeit fragt den Nutzer, ob er auf die mobile Version umgeleitet werden möchte.

Der User Agent String des Safari-Clones auf dem iPad lautet:

Mozilla/5.0(iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10

Die benutzten Browser-Erkennungen bleiben dabei offensichtlich am ‘iPhone’ hängen und schicken den Browser dann weiter.

Aber vielleicht merken die Verlage den Fehler ja gar nicht, da die Manager lieber die Seiten der NYT aufrufen, die zwar noch ein wenig Flash enthält ansonsten aber sehr ansehnlich aussieht.

ps: In den üblichen Statistik-Tools wie Sitestat oder Sitecatalyst werden die Aufrufe übrigens vorerst nicht auftauchen. Die haben schon beim iPhone ein halbes Jahr gebraucht bis die Browser-Erkennung funktionierte.

Da denke ich mir so: HTML5, Video-Tag, src-Attribut, Events? Und die Antwort sind 8 Zeilen JavaScript-Code. Nur als Proof-of-Concept und nicht zur Produktion gedacht (blödes Time-Out-Handling, ich weiss…). Aber das Script macht auch nichts weiter, als zu überprüfen, ob die Werbung durchgelaufen ist und wenn das der Fall ist, den Hauptfilm zu laden. Mit ein wenig Arbeit könnte man auch noch zwischendurch Werbung schalten und ein Banner wäre natürlich auch kein Problem.