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.

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?!