Archiv:

Latest photoblog

photoblog

Blog

Mobiles Webdesign: Konzeption, Gestaltung, Entwicklung

Das folgende Interview wurde in der Ausgabe 2/2011 der Internet Intern veröffentlicht.

Mobiles Webdesign bedeutet in der Praxis, dass man eine für Desktop-PCs gestaltete Webseite für die kleinen Screens der Smartphones oder Tablets umgestaltet. Oder nicht?
Mobiles Webdesign bedeutet in der Praxis im Grunde genommen mehr, als der Begriff Webdesign vermuten lassen würde. Bei einer mobilen Website stehen neben dem eigentlichen Design an sich bei der Adaption einer bestehenden Website vor allem wohl konzeptionelle Gedanken an erster Stelle.

Mit welchen Konsequenzen?
Wie auch bei einer gewöhnlichen Website für Desktop-PCs werden eine ganze Reihe Vorüberlegungen notwendig. Welche Inhalte werden von der bestehenden Website übernommen? Gibt es mobil spezifische Inhalte, die sich auf dem Handy aufgrund der gegebenen Umstände besonders anbieten? In der Hauptsache dürften das wohl standortbezogene Dienste sein wie z. B. der klassische Tankstellen- oder Restaurantfinder. Grob lässt sich der Prozess des mobilen Webdesigns aber tatsächlich so wie von Ihnen genannt beschreiben: nämlich die Adaption der für Desktop-PCs gestalteten Website für kleinere Screens.

Gilt heute nicht eher Handys und Smartphones zuerst, wenn es um das Design einer Seite geht?
Das kann so sein, muss aber nicht unbedingt. Zwar gibt es diverse Studien und Hochrechnungen von Expertengruppen, die besagen, dass in einigen Jahren bis zu 90 Prozent des Internettraffics über Handys und Smartphones abgewickelt werden wird. Doch davon sind wir immer noch ziemlich weit entfernt. Im Grunde genommen kann man sagen, dass in der heutigen Zeit sowohl die Desktop-Version als auch die mobile Version einer Website allmählich eine ähnlich hohe Priorität genießen sollten.

Für welche mobilen Plattformen (OS) muss das mobile Design angeboten werden?
Die Fragmentierung der Plattformen erstreckt sich hier nicht, wie am Desktop, über 3 bis 4 große Browser, sondern über diverse Geräte mit diversen Betriebssystem-Versionen und entsprechend unterschiedlichen Browsern, die alle ihre Eigenarten haben. Ein aktuelles Must-have in Sachen mobile Plattformabdeckung sind, und das wird sich wohl auch in der nächsten Zeit erst einmal nicht ändern, natürlich die Platzhirsche Apples iOS und Android. Aber auch neue Systeme wie das Palm WebOS oder das neue BlackBerry OS 6 sollte man unbedingt im Auge behalten.

Welche Schriftarten können mobile Geräte darstellen?
Neuere Browsergenerationen auf Smartphones unterstützen die Schrifteinbettung von CSS3 und könnten somit theoretisch jede beliebige Schrift darstellen. Bei älteren Geräten hatte man oft nur die Wahl zwischen serif und non-serif. Bei noch älteren gab es oft sogar nichtproportionale Monospace-Schriften. Die Zeiten haben wir inzwischen längst hinter uns gelassen. Mittlerweile sollte man ganz gut fahren, indem man auf die bekannten Desktop-Fonts setzt und als Fallback im CSS eben „serif“ oder „non-serif“ angibt. Das Thema Schrift ist dank CSS3 ein sehr komplexes.

Mobil sein, heißt auch oft, auf das heimische schnelle WLAN verzichten zu müssen. Was sollte man weglassen an Ballast für mobile Seiten?
Der hier wohl sinnvollste Tipp ist, dass man große Bilder möglichst bereits serverseitig auf die Displaygröße des Geräts kleinskalieren sollte. Dabei helfen Dienste wie die eben bereits angesprochenen oder auch TinySrc (www.tinysrc.net). Wer dann noch auf einen sauberen und validen XHTML- oder HTML5-Quelltext achtet, der sollte mit einer langsamen Verbindung keine Probleme bekommen.

Ist es überhaupt nötig, Websites an die Darstellung auf dem Smartphone anzupassen?
Ja. Auch wenn bspw. Apple damit wirbt, auch herkömmliche Websites komfortabel auf dem iPhone benutzen zu können, ist die Auslegung dieser Website doch immer eine andere. Nicht nur das Display ist kleiner, sondern auch die Bedienung und dadurch die komplette Usability. Das größte Problem beim Betrachten einer herkömmlichen Desktop-Website auf dem Handy ist gar nicht mal die Auflösung der Seite, sondern vielmehr die mangelhafte Bedienung. Es muss umständlich in die verschiedenen Seitenbereiche gezoomt werden, um den Text vernünftig lesen zu können, verlinkte Inhalte sind oft von der Klickfläche her zu klein, als dass man die Seite komfortabel bedienen kann.

Bitte geben Sie unseren Lesern eine Checkliste, was sie unbedingt bei mobilen Seiten
beachten sollten. Gerne auch technische Dinge.

Bei der Konzeption und Erstellung einer Seite für mobile Geräte sollte man sich einige Fragen
stellen die hilfreich für den Erfolg der Seite sind:

  1. Wer wird wann, wo und aus welchem Grund meine Seite besuchen?
  2. Welche Inhalte wird sich mein Besucher auf seinem kleinen Handydisplay tatsächlich
    anschauen oder durchlesen wollen?
  3. Welchen Mehrwert kann ich meinem mobilen Besucher bieten? (Standortbezogene
    Zusatzdienste, automatisch verlinkte Telefonnummern, …).
  4. Welche Geräte nutzt meine Zielgruppe überwiegend? (Im Nachgang hilfreich ist hier z.B.
    das Tracking von mobilen Besuchern in den ersten Wochen und Monaten nach dem
    Launch).

Darüber hinaus sollte man darauf achten, dass man dem mobilen Benutzer immer die
Möglichkeit bietet von einer mobilen Version auf die herkömmliche Desktop-Version navigieren
zu können und von dieser auch immer wieder zurück auf die mobile Seite gelangt.

Interview als PDF herunterladen [674 KB]

Xify jQuery-Plugin

[English version below!]
Da ich die Funktion aus der iPhone-Safari Adressleiste schon immer sehr praktisch fand, und mir diese schon oft für Eingabefelder auf Websites gewünscht habe, habe ich mich gestern kurz hingesetzt und ein kleines jQuery-Plugin gebaut, welches mir diese Funktionalität abbildet.

„Xify“ erzeugt einen X-Button zu einem Textfeld wie man ihn aus der Adressleiste des iPhone-Safari kennt. Ein Klick auf das Symbol löscht den kompletten Text des dazugehörigen Textfelds. Benötigt jQuery ab Version 1.2.3.

Die Anwendung

$('input:text').xify();
$('input:password').xify({color: "red"});

Parameter

color
Hintergrundfarbe des Buttons
Typ: CSS Farbangabe
Standardwert: #bbb
size
Größe des Buttons
Typ: integer
Standardwert: 12
left
Angabe um wieviel Pixel der Button im Eingabefeld nach links gerückt werden soll
Typ: integer
Standardwert: 4
callback
Callbackfunktion die aufgerufen wird, wenn das X geklickt wird. Muss true oder false zurückgeben.
Typ: function

Demo

http://www.manuel-bieh.de/publikationen/scripts/jquery/xify/

Download

http://plugins.jquery.com/project/xify

English description

You can use this plugin to automatically add a small „X“ to each input field to remove the current value by clicking or touching the X. You may know this function from the iPhone Safari URL bar. Requires jQuery 1.2.3+

Usage

$('input:text').xify();
$('input:password').xify({color: "red"});

Parameters

color
Backgroundcolor of the button.
Type: CSS color value
Default: #bbb
size
Size of the button.
Type: integer
Default: 12
left
Amount of pixels the button is moved to the left within the input field.
Type: integer
Default: 4
callback
Callback which is executed when the X is clicked. Must return true or false.
Type: function

Demo

http://www.manuel-bieh.de/publikationen/scripts/jquery/xify/

Download

http://plugins.jquery.com/project/xify

Geolocation: und dein Browser weiß, wo du bist

Viele Web-Entwickler haben lange darauf gewartet, mit aktuellen Smartphones und auch neueren Browsern am Desktop ist es nun endlich möglich: die zielgenaue Ortung des Besuchers einer Website. Die W3C Geolocation API hilft dabei.

Damit wird es einem Seitenbetreiber nun ermöglicht – vorheriges Einverständnis des Besuchers vorausgesetzt – dessen aktuelle Position (Längengrad, Breitengrad, Höhenlage), die Reisegeschwindigkeit, sowie die Himmelsrichtung zu ermitteln und daran angelehnt entsprechend geolokalisierte Inhalte auszuliefern. Für einen Tankstellenbetreiber wäre es damit z.B. möglich, einen Tankstellenfinder zu realisieren, der dem Besucher die umliegenden Tankstellen inklusive Entfernung oder sogar eine genaue Wegbeschreibung auf dem Handy präsentiert. Auch eine Tracking-Anwendung, die bspw. die zurückgelegte Wegstrecke beim Joggen für die spätere Analyse am PC aufzeichnet, könnte so – ohne eine App zu installieren – mit dem Browser realisiert werden.

Anders als bei bisherigen Methoden wird dabei nicht ausschließlich auf die IP des anfragenden Clients geachtet, sondern es werden darüber hinaus Parameter wie umliegende öffentliche W-LAN SSIDs (inkl. Stärke des Empfangs) oder ein möglicherweise vorhandenes GPS-Modul abgefragt. Um datenschutzrechtliche Bedenken aus der Welt zu schaffen, wird der Benutzer beim Versuch einer Ortung jedoch vorab um Erlaubnis gefragt. Sollte dieser die Anfrage verneinen, ist der Zugriff auf den Standort über die API nicht möglich.

Wie bei den meisten Technologien, die sich gerade in den Kinderschuhen befinden, gibt es aber auch bei der Implementierung der Geolocation API leider noch einige Tücken. So unterstützen nicht alle Browser mit grundsätzlicher Unterstützung der Geolocation API auch alle Funktionen, die in der Spezifikation vorgesehen sind, und auch die Methoden, mit der die Daten abgefragt werden können, unterscheiden sich teilweise erheblich. Darüber hinaus nagt häufiges Orten bei mobilen Geräten, also Geräten ohne permanenten Strom-Anschluss, stark am jeweiligen Akku. Die Lokalisierung sollte also nicht unnötig oft oder mit einem übertrieben kurzen Intervall durchgeführt werden.

Zumindest um das Problem mit dem nicht einheitlichen Interface zu umgehen, gibt es einige frei nutzbare Open Source JavaScript Libraries, die ein vereinheitlichtes Interface zur Verfügung stellen, wie beispielsweise Geo-location-javascript oder Better Geolocation API.

Eine generelle Unterstützung des Standards, ob vollständig oder nicht, gibt es im Wesentlichen bisher in den folgenden Browsern bzw. Geräten:

  • Android Webkit und Dolphin HD
  • Apple iPhone/iPod Safari iOS 3.0+
  • Blackberry OS 4.1+
  • Firefox 3.5+ (< 3.5 mit installiertem Geode Addon)
  • Google Chrome
  • Opera 10.6+
  • Alle Browser mit installiertem Google Gears

Um eine Ortung in einem Browser durchzuführen, der den Standard korrekt implementiert, kann der folgende exemplarische Code verwendet werden:

var successCallback = function(position) {
    alert('Ihre Position: ' + position.coords.latitude + ', ' + position.coords.longitude);
}
 
var errorCallback = function(error) {
alert('Es konnte keine Ortung durchgeführt werden. Fehlercode: ' + error.code);
}
 
if(typeof (navigator.geolocation) != 'undefined') {
    navigator.geolocation.getCurrentPosition(
        successCallback,
        errorCallback,
        {
            enableHighAccuracy: true,
            maximumAge: 10000
        }
    );
}


Zur Erklärung: Mittels typeof(navigator.geolocation) != 'undefined' wird abgefragt, ob der Browser des Benutzers die Geolokalisierung unterstützt. Daraufhin wird die Methode getCurrentPosition() aufgerufen, welche versucht, die aktuelle Position des Benutzers zu ermitteln. Gelingt dies, wird die als successCallback angegebene Funktion aufgerufen und ein Objekt position übergeben. Dieses erhält dann in position.coords.longitude bspw. den ermittelten Längengrad in Dezimalform (z.B. 7.45333164).

Schlägt eine Ortung hingegen fehl, wird die als errorCallback angegebene Callback-Funktion aufgerufen. Als Übergabe gibt es hier das PositionError-Objekt, das gemäß Spezifikation die Zahlenwerte 0 (Unbekannter Fehler), 1 (Ortung nicht erlaubt), 2 (Position konnte nicht ermittelt werden) oder 3 (Timeout) enthalten kann.

Als dritter, zusätzlicher und zugleich optionaler Parameter kann noch ein Objekt in JSON-Notation angegeben werden, um die Eigenschaften der Abfrage genauer zu spezifizieren. Gültige Eigenschaften des Objekts sind:

  • enableHighAccuracy
  • maximumAge
  • timeout

Die Eigenschaft enableHighAccuracy soll sicherstellen, dass ein besonders genaues Ortungsergebnis erzielt wird. Dies geht allerdings, wie eingangs angesprochen, einerseits auf Kosten des Akkus, andererseits verzögert es die Ortung unter Umständen massiv. Im Gegenzug wird dafür die Fehleranfälligkeit sowie die Möglichkeit der Fehlortun verringert.

Über die Eigenschaft maximumAge kann festgelegt werden, wie alt das Ergebnis der letzten Ortung maximal sein darf (in Millisekunden), bevor eine erneute Ortung durchgeführt wird. Setzt man den Wert sehr hoch, ist das Ergebnis, sollte man sich in der Zeit seit der letzten Ortung bereits weit vom Ursprungsort weg bewegt haben, sehr ungenau. Setzt man es hingegen sehr niedrig an, geht das auch hier zu Lasten des Akkus. Einen empfehlenswerten Erfahrungswert gibt es hier nicht, da kommt es sehr auf den jeweiligen Anwendungsfall und etwas Fingerspitzengefühl an.
Mittels der dritten Eigenschaft, timeout, kann angegeben werden wie lange das Gerät bzw. der Browser probiert, die Position herauszufinden, bevor die errorCallback-Funktion mit dem Vermerk Timeout aufgerufen wird.

Neben der getCurrentPosition()-Methode, gibt es auch noch eine zweite Methode watchPosition(). Mit dieser Methode, die die gleichen Parameter erwartet wie auch getCurrentPosition(), ist es möglich, die Bewegung eines Benutzers zu verfolgen und die als successCallback definierte Funktion bei jeder Positionsänderung erneut aufzurufen. Um dieses Verhalten zu stoppen, muss die dritte und letzte Methode der API, clearWatch(), mit der Rückgabe-ID des watchPosition() Aufrufs aufgerufen werden.

Am konkreten Beispiel:

if(typeof (navigator.geolocation) != 'undefined') {
    var watchExample = navigator.geolocation.watchPosition(
        successCallback,
        errorCallback,
        {
            enableHighAccuracy: true, maximumAge: 10000
        }
    );
 
    // watchPosition wieder anhalten:
    navigator.geolocation.clearWatch(watchExample);
 
}

Die Geolocation API bietet eine sehr interessante Möglichkeit für Seitenbetreiber, die ihre Seite mit standortspezifischen Daten anreichern möchten. Man kann davon ausgehen, dass in Zukunft mehr mobile Geräte und mehr Browser den Standard korrekt unterstützen werden. Wenn die Hürden der Vereinheitlichung des Interfaces erst einmal genommen sind oder man sich mit den genannten Möglichkeiten weiterhilft, entstehen so viele neue Möglichkeiten, um das Web mit sinnvollen zusätzlichen Funktionen anreichern zu können. Der Kreativität des Web-Entwicklers sind dabei (fast) keine Grenzen gesetzt.

Dieser Artikel entstand im Rahmen des Webkrauts Adventskalenders und wurde dort am 3. Dezember 2010 erstveröffentlicht.

Debugging: DOM Exception 7 am iPad

Gestern habe ich mir beim Entwickeln einer WebApp für das iPad die Zähne ausgebissen an einem Problem das so simpel schien, ich aber trotzdem lange gebraucht habe um des Rätsels Lösung zu finden. Ich wollte dynamisch per XMLHttpRequest() einen <style>-Knoten nachladen und in mein aktuelles Dokument einfügen. Dazu nutzte ich den folgenden Code:

(function() {
	var style = document.createElement('style');
	style.innerHTML = 'body {background: #ACC;}';
	document.getElementsByTagName('head')[0].appendChild(style);
})();

Einfach, logisch, funktioniert. Sollte man denken. Funktioniert am Desktop und am iPhone auch fantastisch, das iPad schmeißt mir hingegen den Fehler NO_MODIFICATION_ALLOWED_ERR DOM Exception 7 und fügt keinen neuen style-Knoten in mein Dokument ein. Des Rätsels Lösung ist hier einfach und liegt am innerHTML. Diese Anweisung scheint das iPad bei Styles nicht zu interpretieren. Nutzen sollte man hier stattdessen:

(function() {
	var style = document.createElement('style');
	var text = document.createTextNode('body {background: #ACC;}');
	style.appendChild(text);
	document.getElementsByTagName('head')[0].appendChild(style);
})();

Dann fügt auch das iPad ohne zu murren den Style ins Dokument.

Mobile Webentwicklung: warum nicht mal FITML?

Wer dieser Tage eine mobile Website erstellen möchte findet dafür eine ganze Menge Alternativen am Markt, die allesamt schnellen Erfolg versprechen. Für iPhone, iPad und Android-Geräte sprießen die JavaScript-Frameworks nur so aus dem Boden. Da hätten wir zum Beispiel SenchaTouch, jqTouch oder jQueryMobile um nur die bekanntesten Vertreter zu nennen. Wer darüber hinaus, auf kommerzieller Ebene, „etwas mehr“ möchte, für den hat mein derzeitiger Arbeitgeber Sevenval gerade eine sehr schöne Alternative im Angebot: FITML4.

FITML ist eine eigens auf mobile Aspekte optimierte Markup-Sprache mit der einfach und komfortabel eine mobile Multi-Channel Website erstellt werden kann. Anders als bei den oben genannten Frameworks wird dabei nicht ausschließlich auf JavaScript gesetzt und ältere Geräte und Nicht-Smartphones somit oftmals ausgeschlossen, sondern es wird für jedes Gerät die jeweils bestmögliche Variante ausgeliefert und das in der Regel – mit nur sehr wenig Mehraufwand (größtenteils sogar völlig ohne!) – vollautomatisch.

So kann man als Entwickler, um mal ein kleines Beispiel zu nennen, auf einfache Art und Weise ein JavaScript-Carousel in die Website integrieren bei dem auf Touch-Geräten per Wischgeste ein Element weiter geblättert werden kann, während alte Nokia-Geräte mit nur begrenzter JavaScript-Funktionalität eine statische Version mit serverseitigem Fallback und dem klassischen „Weiter“-Button ausgeliefert bekommen. Dafür, dass auch stets die richtige Variante der Website ausgeliefert wird, sorgt eine eigene Geräte-Datenbank die OpenSource-Alternativen wie WURFL aber auch kommerzielle Kollegen wie z.B. DeviceAtlas in Sachen Zuverlässigkeit teilweise deutlich aussticht und auch wesentlich detailliertere Auswahlmöglichkeiten bietet.

Die FITML-Markup selbst ist eine im Microformat-Stil angereicherte, gewöhnliche HTML-Syntax in die ein gewöhnlicher HTML-Frontend-Entwickler sich rasch eingearbeitet haben sollte, auch wenn die vielen div-Elemente im ersten Moment sicher gewöhnungsbedürftig anmuten. Ich selbst musste jedenfalls, als ich hier im Oktober 2010 meinen Dienst antrat erstmal durchatmen. Davon sollte man sich im ersten Moment aber nicht abschrecken lassen, die Ergebnisse die man mit FITML binnen kürzester Zeit bekommen kann entschädigen für alles. Ich denke, wer tatsächlich auf kommerzieller Ebene mobile High-Performance Websites entwickeln möchte sollte tatsächlich mal, vielleicht auch in der Mittagspause, länger als nur 5 Minuten probieren sich in FITML einzuarbeiten, und das sage ich nicht aus dem Grund, weil ich selbst bei Sevenval beschäftigt bin sondern weil ich die Fallbackfähigkeit bei den ansonsten wirklich geilen Frameworks doch schon des Öfteren schmerzlich vermisst habe.

Warum ich überhaupt probiere euch das schmackhaft zu machen? Aktuell befindet sich FITML in der Version 4 noch in der Private Beta Phase. Wer möchte kann schon mal einen exklusiven Blick auf FITML4 werfen und auch eigene Websites erstellen und für die Zeit der Beta-Phase auch kostenfrei betreiben. Wenn ihr also tatsächlich Interesse haben solltet, in nächster Zeit mobile Projekte ins Haus stehen oder ihr einfach nur neugierig sein solltet, dann könnt ihr einfach hier nachlesen, was ihr dazu tun müsst um am Beta-Programm teilnehmen zu können: http://www.sevenval.com/de/news/FITML4_Private-Beta_FIT-Platform.html. Wer nicht bei Twitter ist, für den kann ich sicherlich auch anders einen Beta-Zugang besorgen. Ein Exklusiv-Service für Blogleser, sozusagen ;-). Hinterlasst einfach euren Namen und eure E-Mail-Adresse hier in den Kommentaren. Update: Die Beta-Zugänge werden ausschließlich über Twitter vergeben! Wer teilnehmen möchte der loggt sich bei seinem Twitter Account ein und schickt eine kurze Reply an @fitml!

Da die Entwicklung von FITML4 sehr Entwickler- und Community forciert ist werde ich (u.A.) hier in nächster Zeit wohl immer mal wieder den einen oder anderen nützlichen Tipp zu FITML geben.

Und nun wünsch ich euch viel Spaß beim Ausprobieren! ;-)

Was war, was wird? Prognosen für 2011


Bild: CJLUC

Das Jahr neigt sich dem Ende zu und so liest man, wie jedes Jahr aufs Neue, zahlreiche Expertenmeinungen was 2011 im Web angesagt sein wird. Da ich letztes Jahr eine solche Vorschau für 2010 bereits angefangen, dann aber leider nie fertiggestellt hatte, ich mit meinen Gedanken aber sogar ziemlich richtig lag, wage ich für 2011 einen neuen Versuch.

Was wird uns 2011 nicht bieten?

Eins vorab, da ich da schon 2010 drüber schmunzeln musste: auch 2011 wird nicht das Jahr des Mega-Durchbruchs von Augmented Reality, so cool die Technologie auch letztendlich ist. Noch immer ist die Anwendung Nerds und Early Adopters vorbehalten. Wer glaubt, mit einer Augmented Reality App die breite Masse erreichen und den großen Reibach machen zu können, der muss schon extrem harte Geschütze auffahren und ein Konzept umsetzen, das alles bisher da gewesene in den Schatten stellt. Glaubt ihr dran? Ich nicht.

… und was wird 2011 uns bieten?

HTML5 wird definitiv kommen und wir werden eine ganze Menge Demos erleben was in der neuen Version an Interaktivität alles denkbar und möglich ist, so wie wir es auch schon 2009 und vor allem 2010 erlebt haben. 2011 wird das noch mal etwas weiter treiben und ich bin mir sicher wir sehen auch in diesem Jahr eine ganze Menge coole Showcases die uns die Kinnlade zu Boden fallen lassen. Hinzu kommt, dass die Browser-Unterstützung bei den neuen Technologien immer besser wird, so dass wir auch immer mehr und mehr Praxisbeispiele finden werden. Und wenn ich von HTML5 rede, dann sollte ich im gleichen Atemzug natürlich auch CSS3 nicht vergessen. Mit dem Internet Explorer 9 gibt es nun erstmals einen Browser aus dem Hause Microsoft, der alle CSS3 Selektoren und auch viele coole Eigenschaften unterstützt. Längst nicht alle, so müssen wir auf border-radius im IE auch weiterhin noch warten, eine erhebliche Steigerung zum Betriebsunfall IE8 ist es alle mal.

Die logische Konsequenz aus der Entwicklung im Bereich HTML5/CSS3 sind mobile Anwendungen im Browser. Für gefühlte 90% aller Apps (Spiele mal außen vor) in den Appstores der großen Handset-Hersteller würde dank Webkit-Implementierung in den aktuellen Geräten im Grunde genommen schon heute der Browser reichen. Ich denke, dass viele Unternehmen das erkennen und neue Wege gehen werden. Vielleicht auch noch nicht 2011, dazu ist es einfach zu lukrativ und verlockend den Appstore-Hype noch mitzunehmen, der selbst gute 3 Jahre nach der Veröffentlichung des ersten iPhones noch nicht ganz abgeflacht ist. Um jedoch schon mal ein Beispiel zu nennen wie man es machen kann, „Die Zeit“ erweist ihrem Namen alle Ehre und geht mit selbiger: nach der Umstellung auf HTML5 gibt es nun auch eine iPad-Version die bei gleichem Markup eine massiv verbesserte User-Experience an den Tag legt. Ich denke auch andere werden diesem Beispiel folgen.

Big in 2011

Mobile Marketing und mobile Advertising (und irgendwie auch mobile Commerce). Irgendwelchen Super-Experten zufolge sollen in den kommenden Jahren Milliarden über Milliarden von Euros über das Handy umgesetzt werden. Ich gebe für gewöhnlich nicht allzu viel auf solche Prognosen, unbestritten dürfte aber eins sein: im mobilen Markt ist Geld zu machen und zwar eine ganze Menge. Sei es mit mobiler Bannervermarktung, mobilen Points of Sale oder auf Agenturseite durch mobile Kampagnen oder die Mobilisierung der bisherigen Websites großer bis mittelgroßer Unternehmen. Klar, was gibt es auch großartigeres für ein Unternehmen als ständig für den Kunden erreichbar zu sein. Am simpelsten ist das wohl über eine mobil optimierte Version der eigenen Unternehmenswebsite möglich.

Mobile, mobile, mobile und es nimmt kein Ende: Location Based Services. Bereits seit Jahren wünsche ich mir auch hier im Blog die Möglichkeit auf die Standortdaten eines Benutzers am Mobiltelefon zugreifen zu können. Dank inzwischen weitläufiger Browser-Implementierung der W3C Geolocation API (die übrigens entgegen der weit verbreiteter Meinung NICHT zu HTML5 gehört sondern ein vollständig eigenständiger Standard ist) ist das nun ohne größere Probleme möglich. Checkin-Dienste wie Foursquare, GoWalla, Latitude, Loca.li oder Places sind nur ein ganz kleiner Teil von dem, was möglich ist. In mittelfristiger Zukunft werden Location Based Services das Web maßgeblich beeinflussen. Ob es regionale eBay-Kleinanzeigen sind, Wohnungssuche mit Standortbezug oder Navigations-Szenarien wie Google Maps. „Location is everywhere!“ – und das einzige was noch im Weg steht ist die Akku-Laufzeit. Wenn ich von „Mobile“ rede, zähle ich Tablets übrigens dazu.

Facebook und das Wachstum

Gerade sprach ich kurz Places an: Facebook wird weiter wachsen und weiter wachsen. Mitte des Jahres gab es 500 Mio Nutzer bei der Plattform, die man mittlerweile als größten Google Konkurrenten sehen kann. Ich denke die 600 Mio Marke werden wir 2011 noch locker erleben, doch irgendwann nimmt auch das Wachstum beim populärsten Service ein Ende. Je mehr Nutzer angemeldet sind, desto weniger gibt es schließlich die sich noch anmelden könnten, Wachstum ist endlich, logisch. Vermutlich werden wir trotzdem noch die 650 Mio Marke knacken. Dann ist aber mal langsam irgendwann gut. Geplant hat Facebook den Gerüchten zufolge einen eigenen Zahlungsdienst. Das könnte der Killer werden aber ebenso auch floppen. Wenn man sich anschaut mit welch rasantem Tempo sich die Leute die Like-Buttons auf ihre Website gepackt haben, kann man wohl eher von ersterem ausgehen. Da liegt es ganz einfach an Facebook und der Komplexität der Lösung. Das ganze muss noch einfacher sein als Paypal und sollte auch für Micropayments lukrativ sein. Dann steht dem nächsten großen Coup von Facebook nichts mehr im Wege. Als heimlicher Fan des Dienstes vertraue ich den Jungs einfach mal dass sie wissen was sie da tun.

What about Google?

Um Google erschien es in den letzten Wochen und Monaten, abgesehen von einigen angeblichen Datenschutzskandalen durch Streetview (Hey, meine Hausfassade ist schließlich meine intimer Lebensbereich) im Prinzip ziemlich ruhig. Nun gibt es Streetview schon eine ganze Weile in anderen Ländern und sprengt daher nicht wirklich die Innovationsskala. Das gehypte Google Wave, auf das wir nach den ersten Previews alle gespannt gewartet haben, wurde eingestellt noch bevor es aus der Beta-Phase herauskam. Das Projekt lebt weiter unter dem Dach von Apache, wo es nun als Apache Wave weiterentwickelt wird. Das mobile Betriebssystem Android gewinnt mehr und mehr Marktanteile, der (wirklich coole!) Chrome-Browser gewinnt langsam Marktanteile und 2011 wird das Chrome OS auf den Markt kommen. Der Gedanke eines webbasierten Betriebssystems ist in der Tat cool und in meinen Augen auch zukunftstauglich und auch die ersten Eindrücke sind durchaus positiv, da wir aber immer noch lange nicht über ein voll ausgebautes 4G/LTE-Netz mit erschwinglichen Tarifen verfügen wird auch das in 2011 nicht durchstarten. Bin dennoch gespannt womit Google uns 2011 vom Hocker hauen wird. An der Zeit für einen Hammer wie seinerzeit Maps, Streetview oder Googlemail wäre es nach dem Flop von Wave eigentlich mal wieder.

Die Startup-Szene

Seit Jahren verfolge ich gebannt die Entwicklung in der deutschen Startup-Szene – zwischen 2008 und 2010 versuchte ich mich vergeblich selbst daran ein Imperium im mobilen Internet zu errichten – und ich denke wir konnten auch in 2010 wieder eine ganze Menge interessanter Neugründungen verfolgen. Rein Subjektiv scheint aber sowohl die Menge als auch die Qualität der erfolgversprechenden Startups abgenommen zu haben. So nehme ich es jedenfalls wahr, denn außer dem Groupon Ableger Citydeal, der mittlerweile von seinem großen Bruder Groupon aus den USA übernommen wurde, gab es kaum spektakuläre Gründungen in der deutschen Internet-Szene. Kein zweites Xing, kein zweites Spreadshirt, kein weiterer ernstzunehmender Konkurrent für die VZ-Netzwerke und auch kein großer deutscher Twitter-Klon. Am interessantesten ist es wohl, hier einmal zu beobachten wo sich im neuen Jahr Team Europe, European Founders und vor allem Hackfwd so alles beteiligen werden und auf diese Beteiligungen mal ein Auge zu werfen. Persönlich klingt loved.by so, als könnte das am ehesten überzeugen. Man wird sehen.

2011 – das Jahr der Browsergames?

Schon Ewig gibt es Browsergames, schon ewig ist da auch die ein oder andere echte Perle dabei. Irgendwie habe ich aber das Gefühl dass Browsergames, gerade wenn ich mir Farm-, Frontier- und Cityville, Brainbuddies oder sonst was bei Facebook anschaue in 2011 richtig durchstarten werden. Sehr gespannt bin ich auf Fliplife und auch im Hackfwd-Portfolio sind Browser-Games vertreten. Wenn man sich überlegt, dass auch der Browsergame-Hersteller Zynga nach eigenen Angaben eine halbe Milliarde Dollar Umsatz machen wird ist der Social Gaming-Markt wohl neben dem Mobile-Markt einer der Wachstumsmärkte mit dem meisten Potential.

Fazit

Wir werden in 2011 wieder einige interessante Startups erleben. Ob eins davon vom Kaliber Twitter oder Facebook sein wird würde ich noch bezweifeln. Vielleicht werden wir ja überrascht. Bekannte Stars im Web-Business werden interessante Projekte rausbringen und es wird viel im mobilen Internet passieren, Geräte-Fortschritt sei Dank. Ich wage keine Prognose welches Projekt definitiv rocken wird aber ich rechne Fliplife, loved.by und auch Foursquare, welches nach Deutschland expandieren will gute Chancen ein. Wir werden Technologiesprünge erleben und Showcases die uns begeistern werden. Interessant wird sein, ob und wann Apple ein neues iPhone herausbringt und ob dieses vielleicht sogar einen NFC-Chip integriert hat. In dem Fall könnte die Entwicklung auf dem Gebiet ungewöhnlich schnell voran gehen. Trotzdem sind das alles nur Spekulationen und Mutmaßungen. Man wird sehen was es am Ende wird, dürfen gespannt sein und uns auf interessante Services und Projekte in 2011 freuen – ich tu es auf jeden Fall und freue mich über jede echte Überraschung und Innovation!

Online-Adventskalender für Web-Developer

Da ich es immer wieder schön finde in der Adventszeit täglich einen neuen Artikel in den zahlreichen „Web-Adventskalendern“ zu lesen, hier mal eine kleine Auflistung an schicken Kalendern die ich so gefunden habe in der Zwischenzeit:

  • Webkrauts – deutsche Artikel zum Thema Internet. Schwerpunkt dieses Jahr: Kunden
  • Maddesigns.de + Webstandardsblog – zwei Seiten, eine Kooperation: ein deutscher Kalender mit vielen Praxisbeispielen was heute schon mit CSS3 möglich ist oder bald sein wird
  • 24 ways to impress your friends – englisch, in den letzten Jahren oftmals mit innovativen und sehr sehenswerten Praxisbeispielen
  • PHP Advent – englisch, wie der Name vermuten lässt mit dem Schwerpunkt PHP-Entwicklung
  • HTML5Adventure Calendar 2010 – ebenfalls englisch, jeden Tag ein beeindruckendes Beispiel was mit HTML5 möglich ist

Bei den Webkrauts sei noch darauf hingewiesen, dass sich hinter dem dritten Törchen ein Artikel von mir zum Thema „Geolocation API“ befindet. Wünsche euch viel Spaß an den kommenden 11 Tagen an denen ein „Törchen“ geöffnet wird. Solltet ihr noch themenrelevante Kalender kennen die hier nicht gelistet sind: ich freue mich über einen Hinweis als Kommentar!

W3C Geolocation API Polyfill

Ich habe meine freie Zeit gerade etwas genutzt um ein Javascript zu erstellen, mit dem man aus dem Browser heraus auf eine einheitliche Geolocation API zugreifen kann. Aktuell unterstützt das Script offiziell die folgenden Browser:

  • Android Webkit
  • Android Dolphin HD
  • Apple iPhone/iPod Safari iOS 3.0+
  • Blackberry OS 4.1+
  • Firefox 3.5+
  • Firefox < 3.5 mit Geode Addon
  • Google Chrome
  • Opera 10.6+
  • Alle Browsers mit installiertem Google Gears

Andere Browser bieten zur Zeit keine Unterstützung für Geolocation (korrigiert mich bitte wenn ich einem Browser Unrecht tue).

Wie wird das Script verwendet?

Das Script muss einfach vor dem ersten Geolocation Request eines Dokuments mittels <script src="geolocation.js"></script> eingebunden werden. Danach kann einheitlich durch navigator.geolocation.* auf die Methoden aus dem W3C Standard zugegriffen werden. Namentlich sind das getCurrentPosition(), watchPosition() und clearWatch().

Das Script mappt dann die proprietären Abfragemethoden (Blackberry Location, Google Gears) auf das navigator.geolocation Objekt und stellt eine einheitliche API zur Abfrage bereit.

Demo

http://www.manuel-bieh.de/publikationen/scripts/geolocation/demo.html

Download

Das Script gibt es bei Github und auf Google Code. Zieht es euch dort, wo es euch lieber ist. Ich halte für gewöhnlich beide Versionen auf dem aktuellen Stand
Google Code: http://code.google.com/p/better-geolocation-api/
Github: https://github.com/manuelbieh/Geolocation-API-Polyfill

Bin wieder da und kann wieder bloggen

Hach, herrlich. Nachdem irgendeine Sicherheitslücke in einem lang nicht mehr aktualisierten WordPress zur Folge hatte das mein Blog-Backend nicht mehr funktionierte, kam ich am Wochenende endlich dazu mal die brandaktuelle Version 2.9.2 hier aufzuspielen.

Nun funktioniert, nach Monaten(!) in denen ich nicht die Zeit hatte oder die Lust fand mein System upzugraden, auch das Backend wieder fehlerfrei, so dass ich in Zukunft hier auch mal wieder etwas veröffentlichen kann. Zwar hab ich dazu wegen Studium und Arbeit nur sehr wenig Zeit dafür, 10 Minuten für kleinere Beiträge kann man aber ja eigentlich immer irgendwo abzwacken.

Ist jedenfalls ein schönes Gefühl endlich wieder bloggen zu können. Solltet ihr irgendwo noch einen Fehler finden der möglicherweise im Update seine Ursache findet, so gebt mir doch bitte kurz Bescheid.

Abschließend möchte ich noch darauf hinweisen, dass ich (mit einigen sehr wenigen Modifikationen) vom Code her noch immer das gleiche Template benutze wie bei der ersten Version dieses Blogs vor ziemlich genau 5 Jahren, als hier noch WordPress 1.2 Verwendung fand. Und es funktioniert tatsächlich immer noch. Das fasziniert mich ein wenig.

QR-Code vs. Datamatrix

Kürzlich haben wir bei der Mobilistics GmbH ein weiteres Projekt abgewickelt, bei dem wieder einmal ein QR-Code als einfache Verlinkung von der Print-Werbung zum Mobile-Content zum Einsatz kam. Der Code dient in diesem Fall dazu, um Teilnehmern eines Gewinnspiels eine einfache Teilnahme direkt vor Ort zu ermöglichen, ohne das dabei die doch recht lange URL mit der „Mäuseklaviatur“ umständlich am Handy eingetippt werden muss. Gedruckt wurde der Code auf eine Postkarte, die gleichzeitig eine Erläuterung zur Teilnahme enthält.

Generell kamen bisher bei allen von uns abgewickelten „Mobile Tagging“-Projekten ein QR-Code zum Einsatz, obwohl unser eigens zum Verwalten solcher Kampagnen entwickelter „Mobilistics Application Server“, neben dem QR-Code durchaus auch das Semacode-/Datamatrix-Format (und theoretisch auch den weniger verbreiteten Aztec-Code) unterstützt, das immerhin gut 20% weniger Fläche bei gleichem Inhalt benötigt. Die Gründe bzw. den Grund für den QR-Code möchte ich hier kurz ausführen.

Wie eben erwähnt benötigt ein Datamatrix-Code nur eine Fläche die rund 20% kleiner ist als die eines QR-Codes gleichen Inhalts. Dennoch nutzten wir bisher ausschließlich QR-Codes. Dies hat, so muss ich zugeben, ausschließlich rein ästhetische Gründe und entspringt keiner wirklich technisch-rationalen Entscheidung. Diese wäre vermutlich, eben wegen der geringeren Größe, zu Gunsten der Datamatrix ausgefallen. Jedoch ist es so, dass jeder mir bekannte 2D-Barcode-Reader sowohl den QR-Code als auch den Datamatrix-Standard unterstützt.

Der QR-Code ist jedoch durch seine drei großen schwarzen Identifikationspunkte in den Ecken unserer Meinung nach wie geschaffen dazu, um vom Nutzer wiedererkannt zu werden. Ein solches signifikantes Merkmal fehlt bei der Datamatrix jedoch (fast) völlig. Dieser ist eine einfach Schachbrett ähnliche Pixelfläche bei der der Novize nicht unbedingt etwas mit anzufangen weiß. Natürlich weiß ein absoluter Novize auch bei einem QR-Code nicht direkt etwas damit anzufangen. Doch sorgen die drei markanten Punkte in den Ecken wie gesagt für einen höheren Wiedererkennungswert als das bei dem Datamatrix-Schachbrett der Fall ist. Generell meine ich aber zudem auch Tendenzen erkennen zu können, dass die Mehrzahl der bisher bekannt gewordenen „Mobile Tagging“-Projekte eher auf den QR-Code, statt auf die Datamatrix gesetzt haben. Die Suchergebnisse bei Flickr sprechen da ebenfalls für sich (589/376 bei Datamatrix/Semacode ggü. 2479 beim QR-Code).

Beide Code-Typen wurden vom Mobile Code Consortium (MC2) als „Quasi-Standard“ zur Verwendung in Mobile Marketing Aktionen empfohlen. Wir denken hier aber, dass die Entwicklung einzig aus den gerade genannten Gründen zum QR-Code übergehen wird. Lassen wir uns überraschen.

Wer noch etwas Lesestoff zum Thema haben möchte: die Absatzwirtschaft berichtet über Mobile Tagging als Teil des Mobilen Marketings.