Dabei besteht das Problem von Flash auf Touchgeräten nicht mal nur in Fixierung des gesamten Systems auf Maus und Maus-Cursor, die es eben auf einem Touch-Screen nicht gibt, sondern in der absoluten Trotteligkeit von mindestens 95% aller “Flasher”. Spricht man mit solchen Leuten, stellt man fest, dass diese sich sehr oft gar nicht als Programmierer begreifen, sondern eher als Kreative für Animation. Die Entwicklungsumgebung für Flash zieht offensichtlich viele Leute an, die eigentlich gerne mit Maya oder ähnlichem gearbeitet hätten, denen aber das notwendige Vorstellungsvermögen für die z-Achse fehlt. Einzig Ebenen übereinanderlegen und gegeneinander verschieben können die meisten.

Diese Beobachtung ist sicher subjektiv. Sie spiegelt aber sogar die Adobe-eigene Wahrnehmung wieder: schon 2008 kotzte sich einer der Chefentwickler von Flash über die “Flasher” aus.

Mit der Ankündigung der Aufkündigung von Flash für Android verabschiedet sich Adobe nun aus dem (Web-)Mobilmarkt. Weder für iOS noch für Android noch für Windows Phone oder Blackberry wird es Flash geben. Zwar haben Entwickler nach wie vor die Möglichkeit, Flash für die App-Entwicklung zu benutzen. Bis auf einige wenige Games findet dieser Weg keine Anhänger. Denn die Nutzer mögen keine seltsam aussehenden Apps.

Damit geht der letzte Akt in einem elenden Kapitel des Web zu Ende. Es begann Mitte der neunziger als der Netscape Navigator 2.0 mit der PlugIn-Schnittstelle veröffentlicht wurde. Jede Wald-und-Wiesen-Softwarebude brachte damals PlugIns für irgendwelche proprietären Formate raus. Mit dabei war Macromedia mit einem sehr erfolgreichen PlugIn für Shockwave Director. Eine kleine Firma entwickelt FutureSplash. Es ist einfach zu bedienen und lässt die Herzen der Animateure und derer Kunden schneller schlagen. Microsoft launcht auf dieser Basis die MSN-Zentrale. Damals hatten Compuserve und AOL noch statische Portale.

Microsoft hatte es damals allerdings versäumt, die Firma FutureWave zu kaufen. Statt dessen hat Macromedia zugegriffen, die dann später von Adobe gekauft wurden. Schon 1996 war allerdings klar, dass die Idee der PlugIns eigentlich eine dumme war. Für die Darstellung von PDFs bot ein Browser keinen Zusatznutzen sondern restriktierte den User nur unnötigerweise. Nur Audio und Videos liessen sich wegen Lizenzen und Codecs nicht ohne unter das Volk bringen.

Mit dem Versuch aus dieser komfortablen Situation der Abhängigkeit der Nutzer von proprietären PlugIns, Kapital zu schlagen sind jedoch alle gescheitert. Real, Microsoft und nun auch Adobe. Sie hätten es wissen können.

Bei der Nutzungsanalyse einer großen Site eines Kunden wunderte ich mich diese Woche mal wieder über die verhältnismäßig wenigen Zugriffen von Android-Geräten. Google Analytics weist für den September 2011 etwas über 15000 Visits aus. Im Februar 2012 sind es knapp doppelt so viele. Eine veritable Steigerung von 100% in fünf Monaten.

Wie komme ich also zu der Einschätzung, dass es verhältnismäßig wenige Android-Zugriffen seien?

Die Zuwächse bei den Android-Geräten fallen überraschend moderat aus. Eigentlich müsste man mit einem Wachstum über dem Marktdurchschnitt rechnen.

In diesen fünf Monaten haben Android-Geräte laut aller Marktanalysen die Führung übernommen. Von einem weltweiten Marktanteil von 8,7% im Q4 2009 ist der Android-Anteil auf 32,9% im Q4 2010 gewachsen. Innerhalb eines Jahres wurde der Anteil also fast vervierfacht und inzwischen ist jedes dritte Smartphone ein Android-Gerät. Hinzu kommt der Wachstum des Marktes selbst, der sich in dieser Zeit knapp verdoppelte.

Unter der Annahme, dass die untersuchte Site mit mehreren millionen Usern im Monat für Android-User genauso interessant ist, wie für jeden Anderen, hätte der Anteil der Android-Geräte in dem Beobachtungszeitraum erheblich stärker steigen müssen als dargestellt. Insbesondere vor dem Hintergrund, dass sich der Anteil der Mobil-Nutzer insgesamt auf der Site von Q4/2009 auf Q4/2010 fast verzehnfacht hat.

Stutzig wurde ich in einem Gespräch mit meinem Kollegen Ramon, der mir berichtete, dass der Standard-Browser seines HTC-Desire über eine Einstellung verfügt, die die Seiten in der klassischen (Desktop-)Variante darzustellen. Viele Web-Sites liefern für Handys angepasste Darstellungen. Deutlich zu sehen bei Wikipedia oder bei WordPress-Blogs. Und viele Android-Nutzer (und auch iOS-User wie mich) nervt diese Darstellung. Denn sie bedeutet, dass man sich mit einer anderen (häufig reduzierten) Funktionsweise beschäftigen muss.

Nicht jedermanns Sache: mobiles Interface für Wikipedia

Ein Test ergab, dass bei Änderung dieser Einstellung der User-Agent-String des Browsers geändert wird. Statt:

Mozilla/5.0 (Linux; U; Android 2.2.1; de-de; HTC_DesireZ_A7272 Build/FRG83D) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

wird bei Aktivierung der Einstellung:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_6) AppleWebKit/534.22+ (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4

im Header des Requests an den Server gesendet. Für den Server sieht es damit so aus, als ob ein ganz normaler Mac die Seite aufruft. Ebenfalls geändert werden die Properties im navigator-Objekt des Browsers unter JavaScript. Dem Server wird ein komplett anderer Browser vorgegaukelt damit die Seite möglichst so aussieht, wie der Nutzer es auf einem Notebook erwarten würde.

Da es sich bei dem Standard-Browser (und den meisten Alternativen auch) unter Android um einen WebKit-Browser handelt ist die Verwendung der Safari-Kennung naheliegend. Eventuelle Anpassungen dürften sich weitgehend gleich verhalten.

Nur eine Umfrage könnte tatsächlich ermitteln wie viele Android-User diese Einstellung vornehmen. Häufige Fragen in Nutzerforen, wie die mobile Darstellung abgeschaltet werden kann deutet allerdings darauf hin, dass dies nicht so selten geschieht.

Interessant am Rande ist darüber hinaus, dass selbst Google Analytics (wie alle anderen WebAnalytics-Anbieter auch) nach wie vor keine vernünftige Lösung für Ermittlung des Browsers bieten. Der normale User-Agent-String des genannten HTCs wird nicht – wie es korrekt wäre – als WebKit ausgezeichnet, sondern taucht als “HTC_DesireZ_A7272″. Bei Samsung und LG verhält es sich ähnlich.

Als Gegencheck habe ich mir die Entwicklung der Nutzungszahlen von Safari unter MacOSX angesehen. Vom September bis einschliesslich Februar wuchs die Zahl der Nutzer überdurchschnittlich um fast 40% von 250.000 Besuchen auf 350.000. Hochgerechnet auf ein Jahr ergäbe sich eine Verdopplung. Zwar wachsen die Verkaufszahlen laut Marktforschern aber sie verdoppeln sich nicht. Ausserdem verwendet ein wachsender Teil der User auch auf dem Mac einen anderen Browser als Safari (z.B. Firefox oder Chrome).

Ein weiteres Indiz für die fehlerhafte Erkennung der Android-Geräte ist die merkwürdige Häufung ungewöhnlicher Bildschirmgrößen bei den Safari-Nutzern unter Mac OSX. Eigentlich sollte man davon ausgehen, dass gerade die Apple-Rechner mit wenigen bekannten Auflösungen – 1280 x 800 beim MacBook Pro 13″ oder 1366 x 768 beim MacBook Air 11″ – daher kommen müssten. Es sind stattdessen jedoch signifikant viele Geräte mit “unrunden” Auflösungen zu verzeichnen.

Diese Tatsache ist damit zu erklären, dass bei Android ebenso wie bei iOS die Größe des Bildschirms nicht festgelegt ist, da der Browser die Seiten skaliert. Die tatsächliche Größe steht erst fest, wenn der Browser die Elemente tatsächlich kennt und darstellen kann. Wenn die Seite meint, dass sie nur 600 Pixel breit ist, wird in den meisten Fällen der Browser auch behaupten, dass der Screen 600 Pixel breit ist.

Nach diesen Betrachtungen ergibt sich, dass ein signifikanter Teil der Android-User in den Tracking-Tools schlicht als Mac-User gezählt werden. Fussend auf den Auffälligkeiten bei den Zahlen zur Safari-Nutzung schätze ich, dass mindestens ein Drittel aller Android-Geräte falsch gemessen werden.

Ein ähnliches Problem ergab sich übrigens schon vor 15 Jahren für den legendären Browser Omniweb unter NeXTSTEP. Auch dieser verfügte über einen Mimikry-Modus damit der User nicht immer nur die Seiten mit dem Hinweis auf den Netscape Navigator sahen (mein Artikel dazu bei Heise, leider kostenpflichtig …).