→

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.

Via fscklog.

→

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

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.

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)

daringfireball.net

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?

Some rights reserved by Masked Malayan

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.

Wirklich albern.

So tomorrow, next week, next month, but as soon as you can, I want you to try this experiment with your clients, whether they be external or internal at your organisation.

Ask them outright,

What would you prefer me to do?

Spend my time hacking around issues in older technologies like Internet Explorer 6 or would you like that time spent making the site look the best that it can on better desktop browsers, as well as on the iPhone, iPod Touch, iPad, Blackberry and a whole host of other mobile devices?

I have a feeling I know what the answer will be, but I don’t have your clients or your day job or your approach to dealing with people. I have my own.

forabeautifulweb.com

http://www.youtube.com/watch?v=7IOTrqlz4jo

Hab ich mir jetzt ein paar Mal angesehen, und den total aufgeregten Gizwindowmodo-Artikel dazu gelesen und alles was ich mich frage ist: was passiert, wenn man das Telefon quer hält?

Seit iPhone 3.0 geht im Safari:

navigator.geolocation.getCurrentPosition(foundLocation(position){^
	var lat = position.coords.latitude;
	var long = position.coords.longitude;
	alert('Found location: ' + lat + ', ' + long);
}, noLocation(){
	alert('Could not find location');
});

Weil ich die veraltete Information aber auch gerade nochmal in einem Buch gelesen habe und dort beinahe ausschließlich auf jQuery gesetzt wird: es gibt natürlich auch ein entsprechendes jQuery-Plugin: jquery-geolocation. Die ist kompatibel zum Safari/iPhone ab Version 3.0 und Firefox ab 3.5.

$.geolocation.find(function(location){
   alert(location.latitude+", "+location.longitude);
}, function(){
   alert("Your device doesn't support jquery.geolocation.js");
});

Braucht das mobile Web eine Extrawurst? Ich stehe sicherlich nicht allein da, wenn ich behaupte – Nein! Das mobile Web ist schon Vergangenheit. Heute gibt es nur noch das Internet. Nehmen wir das bereits angesprochene iPhone. Auf dem Apple-Produkt kann man alle normalen Webseiten, bis auf wenige Ausnahmen, völlig normal betrachten. Es kann angenehm gezoomt werden und alle Texte sind ohne Probleme lesbar. Nur sehr aufwändige Seiten, die einige Daten übertragen müssen (zum Beispiel viele Bilder), sollten für mobile Endgeräte optimiert werden. Deviantart ist hier ein gutes Beispiel. Ansonsten sind bei entsprechend guter Planung im voraus und effektiver Umsetzung gemäß den Standards, in den seltensten Fällen großartige Anpassungen nötig.

webstandard.kulando.de

Sehe ich ganz genauso.

Was macht Fireeagle? Nun, Yahoo stellt damit einen Service und ein API zur Verfügung, bei dem mobile Nutzer ihren aktuellen Standort bekanntgeben. Unter Nutzung des API können Programme entwickelt werden, die diese Information – gebunden an eine Erlaubnis des Nutzers natürlich – verarbeiten können. Der Nutzer kann dabei übrigens auch bestimmen, wie genau die Information ausgegeben wird, bspw. nur die Stadt, statt gleich der genauen Geodaten. Ausführlicher hier nachzulesen.

Jeder mag selbst entscheiden, wie gut es ist, einen starken Service zu haben, der über unsere Stadorte informiert ist, anderseits ist eben der starke Service auch der Vorteil, denn: mehr Nutzer = mehr Apps = mehr Services. Und die sind dann location based, endlich, das Hypewort von vor drei Jahren könnte sich mit Leben füllen.

Ist noch ein wenig buggy, funktioniert aber meistens, ummm oft. Fragt sich halt nur, wie man ohne copy-and-paste sinnvoll bloggen soll?!

Puh, wie ich solche Studien hasse. Einerseits fragt man sich, ob sowas wirklich stimmen kann, andererseits wundert man sich auch irgendwie nicht mehr, wenn einen die Leute schief ansehen, wenn man in der Bahn mal twittert oder ZEIT Online absurft. Das System hat keinen Fehler, es ist der Fehler.

Der Rest der Studie klingt ein wenig, wie meine Einschätzung des Handysurfmarktes, das ist leider ein wenig pessimistisch. Zumal wir uns ja in den Kommentaren darauf geeinigt hatten, dass das nicht ganz zu Ende gedacht war. Aber eine Studie denkt eben auch nicht und schon gar nicht zu Ende. 79% der Befragten gaben an, dass ihnen ihr PC ausreichen würde. Hä? Ich sehe selten Leute ihren PC durch die Gegend schleppen, zumal, die langen Kabel wären bestimmt ziemlich teuer!

Aber, es spiegelt sich auch in dieser Studie, dass die Kosten als zu hoch wahrgenommen werden. Und von Angst vor hohen Kosten ist die Rede. Was seltsam ist, denn genau so ging es mir ja auch, bis ich merkte, dass da noch ziemlich viel Luft im, zugegebenermaßen nicht ganz billigen, Mobilsurftarif war. Möglicherweise gibt es eine allgemeine Angts vor versteckten bzw. überraschenden Handy- und/oder Telefongebühren. Schließlcih kennt jeder jemanden, der an seinen Telefongebühren bankrott gegangen ist. Oder nicht? Tja, Ängste.

Die Angst vor hohen Kosten spiegelt sich in der Art der Nutzung wider: So bevorzugen Mobilsurfer unterwegs Dienste, die wenig Zeit und Datenvolumen in Anspruch nehmen, darunter E-Mail (54 Prozent), Nachrichten (44 Prozent) und Informationen über das Wetter (32 Prozent). Über ein Drittel (36 Prozent) der Befragten gab sogar an, nur in Ausnahmefällen über das Mobiltelefon online zu gehen.

So what? Hier sehe ich ganz klar eine Tendenz, die ich jetzt mal kurz für mich behalte, weil sie im nächsten Absatz noch deutlicher wird:

[…] Kaum einer lädt Musikstücke oder Videos mobil aus dem Internet (13 Prozent und 9 Prozent). Auch Social Networks nutzen nur wenige (9 Prozent) über das Mobiltelefon.

www.golem.de

Kann es einfach sein, dass mobiles Musik- und Videoladen tatsächlich nicht die richtigen mobilen Anwendungen sind? Ich meine Mail-, Wetter- und/oder Nachrichtenchecken ist soviel mobiler und näher dran auch am Bedürfnis des mobil und aber trotzdem informiert sein… das liegt doch auf der Hand, oder? Musik ziehen mit dem Handy, eh’ wozu? Klar, das das floppt. Oder Videos.

Was ist jedoch mit Maps? Da wartet doch das Killerfeature und noch dazu ein datenintensives. Da wird das iPhone noch viel Pionierarbeit leisten. Und News werden schon heute mobil konsumiert. Wo sich der Kreis schliesst: Leute, es wird Zeit, sich nochmal mit Webdesign für mobiles Surfen zu beschäftigen. Je öfter ich mit meinem Opera mini ankomme und feststellen muss, dass eine Site nicht optimiert ist umso klarer wird mir das… Studien ändern daran gar nichts, sondern halten nur auf. Längere Akkulaufzeiten, das würde ich mal begrüßen. ;)

Ein Beispiel: ich kann mich zwar noch an mein Modem (14.4) erinnern und auch an die astronomische Telefonrechnung die ich eines Tags meinen Eltern damit bescherte. Basierend auf dieser Erfahrung habe ich bei erster Gelegenheit eine Internet-Flatrate abgeschlossen und dann mir nie wieder Gedanken gemacht über Onlinezeit oder gar übertragene Datenmengen.

Nun hab ich mir jüngst ein Datenpaket fürs das Handy zugelegt und der gesteht mir monatlich 200MB zu, die ich mit meinem Handybrowser verbraten kann. Schluck! Das klingt aber wenig. Jetzt fang’ ich am Ende noch an Bytes zu zählen? Hab’ ich gedacht: versuchste Mal ein Gefühl dafür zu entwicklen, was Dein Opera Mini so tut. Ich hab also den Monat über getwittert, ein paar Feeds gelesen, Mails kontrolliert, ein paar Fotos gepostet, ein oder zweimal per Bluetooth mein Macbook mit Internet versorgt. Und irgendwann hatte ich das Gefühl: jetzt sei mal langsam vorsichtig.

Heute kam die Rechnung. Im Einzelverbindungsnachweis kann man sich die verbrauchte Datenmenge freundlich selbst per Hand zusammenrechnen.

Von 200 möglichen habe ich bloss 17 MB verbraucht. Gnnpf. Das ist ausbaufähig würde ich mal sagen.

Da ist es ja nur umso erschreckender, wie teuer dagegen SMS ist. Ein MB Daten per SMS versenden ist ja viermal so teuer, als dieselbe Menge Daten beim Weltraumteleskop Hubble abzuholen. Da wundert einen ja gar nichts mehr. [Thanx, Ron.]