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

Ganz einfach: statt ständig if(navigator.geolocation) und Konsorten abfragen zu müssen, gibt es mit meinem „Abstraction Layer“ nur noch einen Aufruf mit dem ein GeolocationWrapper-Objekt erzeugt wird und mit dem überprüft wird, ob eine wie auch immer geartete Unterstützung vorhanden ist. Im konkreten Anwendungsfall sieht das dann wie folgt aus:

geo = new GeolocationWrapper();

Anschließend kann mit den im W3C Standard beschriebenen Methoden (getCurrentPosition und watchPosition) auf die Position zugegriffen werden:

if(geo.api) {
	geo.getCurrentPosition(success, error, {enableHighAccuracy: true, maximumAge: 1000});
}

Der SuccessCallback-Funktion (in diesem Fall ist das die Funktion success) wird ein position-Objekt als Parameter übergeben, über das in der Funktion auf die Standortdaten des Benutzers zugegriffen werden kann.

Um bspw. den Breitengrad auszugeben, kann das wie folgt aussehen:

function success(position) {
	alert('Your position: ' + position.coords.latitude + ', ' + position.coords.longitude);
 }

Das Script mit einer Google Map als Beispiel gibt es zu sehen unter:
http://www.manuel-bieh.de/publikationen/scripts/geolocation/demo.html

Den Download findet ihr auf der eigens eingerichteten Google Project Seite:
http://code.google.com/p/better-geolocation-api/

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.

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.

Hier gehts es zum Artikel: Der iPhone-App Killer: Mobile Webbrowser bekommen endlich Zugriff auf die Geolocation! Und hier noch eine etwas ältere Ausführung von mir, von Anfang des Jahres, mit einigen Fragen und Wünschen: Einige Dinge die ich mich gelegentlich frage.

Dann dürfte es ja jetzt nur noch ein paar Jahre dauern, bis sowas vielleicht flächendeckend funktioniert, schön!

PayPal has launched its mobile payment platform, called, of course, PayPal Mobile.

Das ist jetzt inzwischen fast genau 3 Jahre her. Gerade habe ich nach langer Zeit wieder einmal versucht mich bei PayPal Mobile mit meinem E90 Communicator einzuloggen und was bekam ich dort zu sehen?

Fehler: PayPal-Handyzahlungen stehen in Ihrem Land zurzeit nicht zur Verfügung.

Geschlagene 3 Jahre gibt es den mobilen Dienst inzwischen, mittlerweile verfügbar in den USA, Australien, Kanada, Frankreich, Italien, Spanien und Groß-Britannien. Wieso dauert es so lange, den Dienst auch für Deutschland umzusetzen?

Ich will doch einfach endlich geile Webservices mit PayPal Mobile Bezahl-Abwicklung basteln können …

Gut, wirklich toll sieht das Ding nicht aus, aber da orientiert sich das mobile Portal wohl am Desktop-Bruder, der von der Optik her sicherlich auch nicht unbedingt auf der Höhe der Zeit ist. Immerhin passiert da überhaupt mal was in diese Richtung.

Zu finden sind die mobilen Versionen unter der äußerst praktischen Subdomain m:
m.studivz.net
m.schuelervz.net
m.meinvz.net

Google nutzt seinen Transcoder dabei zudem auch, um verlinkte Seiten aus der mobilen Googlemail-Version heraus zu transkodieren. Manchmal ist dies jedoch unerwünscht, nämlich in der Regal dann, wenn man eine eigene, gesonderte Webpräsenz für mobile Geräte besitzt. Stattdessen wäre es sinnvoller, den Benutzer lieber dorthin zu verweisen.

Dafür gibt es nun schon seit geraumer Zeit eine Möglichkeit, um dies mittels eines bestimmten <link>-Element zu bewerkstelligen. Diese Möglichkeit hatte ich aus Zeitmangel in meinem Buch leider nicht mehr beschrieben und möchte dies an dieser Stelle nachholen.

Einige Transcoder, wie zum Beispiel die oben beschriebenen erkennen dies, andere (wie Skweezr) leider nicht. Um die Transcoder also auf die eigene mobile Website umzuleiten, muss dazu einfach das folgende Element in den <head>-Bereich einer (Desktop-)Seite eingebaut werden:

<link rel="alternate" media="handheld" href="Link zur Mobile-Seite" />

http://www.manuel-bieh.de/blog/wp-content/uploads/2009/02/time.php

Ich wünsche ein angenehmes Wochenende!

1. Wann werden wir Location Based Services endlich vernünftig nutzen können?
2. Warum hält es kein Handset-Hersteller für nötig, per aktivierbarer Optionen in den Browsereinstellungen, die Übertragung der GPS-Koordinaten an die angeforderte Seite bspw. mittels Headerdaten o.Ä. zu erlauben, wenn GPS sowieso schon im Gerät integriert ist?
3. Wann portiert Google sein Gears-Framework inklusive Geolocation-API endlich auf Symbian und Co?
4. Warum muss das alles so kompliziert sein?

Zu 1.

Mit vernünftig meine ich: wirklich vernünftig! Vernünftig, im Hinblick auf Einfachheit, Integration und Standards. Ich möchte mir nicht für jede noch so kleine (aber dadurch nicht zwangsläufig weniger interessante) ortsbezogene Applikation eine Software laden und im Handy installieren müssen. In einigen Fällen, wie z.B. aka-aki, die sich auf Bluetooth Reichweite beschränken wollen, mag das noch sinnvoll sein. Auch Google Maps Mobile, deren Schwerpunkt (vorerst) nicht im Wesentlichen auf den ortsbasierten Infos liegt und was zudem ein sehr komplexes (aber gutes) Handling beinhaltet, nehme ich hier aus. Aber neuere (Smart-)Phones beherrschen inzwischen alle Javascript, zu teilen sogar XMLHttpRequest/AJAX, Flashlite und diverse andere üblichen Webtechnologien. Dennoch kocht hier jeder sein eigenes Süppchen und stellt umständlich, da notwendigerweise für unzählige Handsets einzeln optimiert, eigene Applikationen zur Verfügung, jeweils für Symbian, Windows Mobile, Android, iPhone OS und was es nicht noch alles gibt.

Zu 2.

Punkt 2 knüpft hier nahtlos an Punkt 1 an. Bedeutend einfacher wäre hier meiner Meinung nach, wenn die Mobiltelefon-Hersteller von sich aus eine simple, idiotensichere Funktion, in den ab Werk integrierten Handybrowser einbauen würden, die es dem Benutzer ermöglicht, einer aufgerufenen Seite per SEND-Header (bspw: "HTTP_USER_LOCATION=51.514285,7.464201" oder etwas ähnliches) die aktuellen Aufenthaltsdaten zukommen zu lassen. Diese werden mittels im Telefon integriertem GPS-Empfänger ausgelesen, und ein Seitenbetreiber kann so nun Standort-Informationen zu den vom Benutzer übermittelten Koordinaten zur Verfügung stellen. Mir ist durchaus klar, dass dies ein ziemlicher Datenschutz-/Sicherheits-GAU werden könnte, meiner Meinung nach würde es aber ausreichen wenn diese Funktion in der Werkseinstellung deaktiviert ist. Leute, die wissen was Sie tun, aktivieren die Option, alle anderen bekommen davon eben nichts mit und können auch nicht geortet werden.

Eine solche Option könnte für mich im Einstellungsmenü in etwa so aussehen:

Standortdaten beim Seitenaufruf übermitteln

Zu 3.

Google hat hier mit seiner MyLocation/Geolocation-API im Gears-Framework einen ersten Anfang gemacht. Diese API erlaubt es die aktuellen Standortdaten über Javascript abzufragen, jedoch nur dann, wenn Gears auf dem Client-Rechner installiert ist. Allerdings ist Gears proprietär und bisher nur für Windows, Mac, Linux und Android verfügbar, ob jemals eine wirklich (Mobile-)plattformübergreifende Version herausgebracht wird, ist angesichts der Tatsache, dass Google mit Android über ein eigenes Mobile OS verfügt, äußerst fraglich. Die Standortabfrage wäre dann jedoch im Browser ganz einfach möglich, mit dem folgenden kurzen Code-Schnipsel:

<script type="text/javascript" src="gears_init.js"></script>
<script type="text/javascript">
var geo = google.gears.factory.create('beta.geolocation');
function updatePosition(position) {
  alert('Current lat/lon is: ' + position.latitude + ',' + position.longitude);
}
function handleError(positionError) {
  alert('Attempt to get location failed: ' + positionError.message);
}
geo.getCurrentPosition(updatePosition, handleError);
</script>

Wird aber wohl erstmal ein Traum bleiben. Das W3C arbeitet zwar an einer Geolocation API, was das aber irgendwann mal ergibt, wie das in der Praxis aussieht was die Implementierung und Anwendbarkeit dieser durchaus interessant klingenden API angeht und wann diese Technik jemals flächendeckend verwendet werden kann, das steht wohl in den Sternen.

Zu 4.

Mit Google Maps Mobile, Aka-Aki und dem Nokia Sports Tracker befinden sich aktuell drei LBS-Anwendungen auf meinem E90 Communicator. Für jede Applikation, die sich auf meinen Standort berufen will, kommt eine weitere Anwendung hinzu, die installiert werden muss. Für mich als jemanden, der in diesem Bereich zuhause ist, ist das auch absolut kein Problem. Allerdings werden Location Based Services meiner Meinung nach nie zu dem Massen-Durchbruch kommen, der ihnen schon seit Jahren vorausgesagt wird, wenn sich an der Anwendbarkeit nicht schnell einiges ändert und vereinfacht wird. Und nein, auch das iPhone bietet für mich, trotz leichter Bedienbarkeit, keine zufriedenstellende Lösung. Es mag sein, dass es dort dank App-Store und allerhand netter Features recht einfach geworden ist, sich diese Tools auf das Gerät zu holen. Probleme wie die Plattformabhängigkeit bzw. die Notwendigkeit zur oft kostenintensiven Entwicklung für die verschiedensten Plattformen sind damit auch nicht gelöst, so lange das iPhone nicht 95% aller Marktanteile besitzt – äußerst unwahrscheinlich.

Was wir im mobile Web meiner Meinung nach wirklich brauchen, ist eine einheitliche, standardisierte Schnittstelle, ähnlich dem oben beschriebenen Google-Ansatz. Auch finde ich keine fundierten Gegenargumente, was gegen meinen Vorschlag mit den durch den Header gesendeten Standortdaten sprechen könnte. Aber ich fürchte dazu wird es weder in kurz- noch in mittelfristiger Zukunft mal kommen und die Anwender werden weiterhin jedes Mal damit belästigt, eine Software installieren zu müssen, möchten sie auf Location Based Services zurückgreifen.

Hier einmal das entsprechende Job-Angebot:

Auszubildenden zum Fachinformatiker,
Fachrichtung Anwendungsentwicklung (m/w)

Als Anwendungsentwickler bei der raphael GmbH lernen Sie in einem erfahrenen und dynamischen Team mit Hilfe moderner Technologien innovative Online-Anwendungen für unsere Kunden zu konzipieren und zu realisieren.

Ihr Profil
Sie haben die Schule mit Fachabitur/Abitur oder einem guten Realschulabschluss abgeschlossen und besitzen bereits gute HTML-Kenntnisse. Neben der Schule haben Sie bereits Erfahrungen mit einer Script- oder Programmiersprache gesammelt, am besten im Bereich der Internet-Anwendungen. Dazu sind Sie lernbereit und engagiert, besitzen ein ausgeprägtes logisches Denkvermögen, sind motiviert und teamfähig.

Besonders gern sehen wir es, wenn Sie bereits Kenntnisse in der Programmierung von kleineren Online-Anwendungen haben, insbesondere mit PHP, XHTML, CSS und Javascript, sowie im Umgang mit relationalen Datenbanksystemen (SQL). Auch erste Erfahrungen mit Content Management Systemen (ideal wäre Typo3) und Know-How in der Administration von Linux-Systemen bringen Sie Ihrem Ziel einen Schritt näher.

Ihre Perspektiven
Wir sind ein wachsendes Unternehmen, das namhafte Kunden betreut und sich auch überregional bereits einen Namen gemacht hat. Unsere Kunden wissen unsere Professionalität, unser Know-How und unsere Einsatzbereitschaft zu schätzen. Da wir uns vergrößern und unsere Geschäftsfelder weiter ausbauen wollen, besteht bei uns immer Bedarf an motivierten und engagierten Mitarbeitern. Alles ist möglich!

Wir freuen uns auf Ihre aussagekräftige Bewerbung (Lichtbild, Lebenslauf, Zeugnisse, Referenzen) per E-Mail an die Adresse info@raphael-gmbh.de.

Vor dem Eintritt in ein Ausbildungsverhältnis bieten wir Ihnen gern im Rahmen eines Praktikums die Möglichkeit, das Unternehmen und die Sie erwartende Aufgabenstellung näher kennen zu lernen.

Fragen beantworte ich gern vorab, dazu einfach eine E-Mail an m.bieh@mobilistics.de oder einfach die Kommentarfunktion hier benutzen.

Schön! Wobei ich bisher mit der inoffiziellen Variante unter http://de.wapedia.org/ auch ganz zufrieden war.

Seriöse Suchmaschinen sollten sich auch daran halten und entsprechend ausgezeichnete Seiten auch nicht indizieren. Nun ist es mir gerade in letzter Zeit häufig aufgefallen, dass bestimmte Bereiche einer Seite entweder als Bild eingebunden werden, um die Erfassung durch Suchmaschinen oder andere Bots zu verhindern (z.B. bei abgeordnetenwatch.de) oder das Realnamen von Benutzern nicht ausgeschrieben, sondern nur abgekürzt werden (ganz massiv in den Xing-Foren der Fall).

Seit einiger Zeit gibt es für Links, die von Suchmaschinen nicht verfolgt werden sollen, das Link-Attribut rel="nofollow", um das es eine hitzige Debatte über Sinn und Zweck gab. Aus diesem Grund möchte ich heute mal die Frage in den Raum werfen: in einer Zeit, in der mehr und mehr Leute ein Bewusstsein für Datenschutz und Wahrung der eigenen Reputation im Netz entwickeln, wäre es da nicht angebracht, eine Art „Mikroformat“ einzuführen, um Suchmaschinen sagen zu können: Stop! Hier nicht indizieren?

Das könnte in meinen Augen recht einfach realisiert werden durch ein simples:
<span class="noindex">Manuel Bieh</span> möchte anonym bleiben

Michael Jendryschik schreibt auf Mikroformate.de:

Mikroformate (engl. Microformats) sind im Wesentlichen Formate zur »Feinstrukturierung« von Webseiten. Dabei werden (X)HTML-Dokumente menschen- und maschinenlesbar durch zusätzliche Informationen ergänzt, indem Elementen an den richtigen Stellen class-, rel- oder rev-Attribute mit festgelegten Werten zugewiesen werden.

Dies wäre eine einfache Möglichkeit um Web-Autoren die Arbeit zu erleichtern und den Benutzern in einer Welt des User Generated Contents ein wenig Anonymität zu gewähren. Vielleicht gibt es ja bereits Überlegungen oder gar konkrete Implementierungen. Bisher habe ich so etwas jedoch noch nicht bewusst wahrgenommen.

Für Unkundige wird unter dem Code eine Kurzanleitung geliefert, wie man sich per SMS einen Reader auf das eigene Handy holen kann.

Realisiert wurde das Projekt durch die Mobilistics GmbH, ganz besonders freut es mich persönlich aber, dass ich wesentlichen Anteil am Code und dem dahinterstehenden Workflow habe. Jetzt bleibt nur noch zu hoffen, dass sich der Einsatz von mobile Tagging bei diesem „Pilotprojekt“ empfiehlt und der ein oder andere Dortmunder Kenntnis nimmt, von dieser schönen und zukunftsweisenden Technologie.

Ich behaupte jetzt einfach mal ganz selbstsicher, dass es sich dabei um Deutschlands größten öffentlichen QR-Code handelt. Oder kennt ihr größere Codes aus Deutschland?

(Kleiner Hinweis: die Fotos befinden sich unter Creative Commons Lizenz und können frei verwendet werden)

Social Networks und Communities nutzen überraschenderweise nur 19% der User, was mich persönlich ein wenig verwundert, so bietet doch zumindest Xing eine sehr schöne und durchdachte mobile Version seines Dienstes an. Neben regionaler Informationsbeschaffung (73%) werden Social Networks aber mit 63% zu den Services mit dem meisten Potential gezählt.

Die komplette Studie gibt es bei deutsche-startups.de:
http://www.deutsche-startups.de/2008/09/09/zweinull-trends-jeder-fuenfte-nutzt-das-internet-bereits-mobil/

Einigen wird sicherlich der Dienst www.tinyurl.com bekannt sein. Dort kann man eine sehr lange URL angeben und erhält daraufhin eine gekürzte URL von TinyURL zurück. Diese kann man dann einfach kopieren und weitergeben oder man kann sich einiges an Tipperei auf dem Handy sparen.

Was mich an TinyURL immer ein ganz klein wenig störte ist, dass ich dort teilweise drei mal den gleichen Buchstaben hintereinander als Kurz-URL erzeugt bekam. Das hieß auf dem Handy jedesmal Tippen, Pause, Tippen, Pause, Tippen. Nicht schön. Aus diesem Grund habe ich mich am Wochenende kurz hingesetzt und einen eigenen ShortURL-Service gebastelt. Die bewusst gewählte Domain WAPorize.net ist so aufgebaut, dass keine Taste auf einer deutschen Handyklaviatur zweimal hintereinander gedrückt werden muss, um zwei Buchstaben zu erhalten, was bedeutet, dass die Warterei entfällt.

Dies wird auch bei den erzeugten Links berücksichtigt, eine Zeichenkette wie aaaaa, abcabc oder ababab ist also nicht möglich. Zusätzlich zu den leicht zu tippenden URLs gibt es zu jeder generierten URL einen QRCode mit dem entsprechend kodierten WAPorize-Link. Wer also einen Barcode Reader in seinem Handy hat, der kann den Link einfach abfotografieren. Wer keinen hat, tippt einfach die kurze, leicht zu tippende URL ins Handy ein.

Einfach, oder?

Mögliche Bugs könnt ihr mir hier gern melden. Ich werde dann versuchen mich schnellstmöglich um die Behebung zu kümmern.

Sehr erwähnenswert ist an dieser Stelle „Mobilize and Share“ (kurz: MOSH) von Nokia. Benutzer können dort anderen Benutzern Spiele, Programme oder Themes, hauptsächlich natürlich für Nokia-Handys, vorstellen.

Eine andere Goldgrube mit kostenlosen Handygames habe ich gerade im Mobile Zeitgeist gefunden. Simyo bietet in seinem Mobil-Portal über 400 Handy-Spiele kostenlos zum Download an. Super Sache!

http://mgames.simyo.de/WhiteLabelWap/index.htm

Was mir daran jetzt aber nicht unbedingt gefällt ist die Tatsache das es so dargestellt wird, als wäre das Tagging wirklich nur dann von Interesse, wenn man plant seinen Urlaub in Japan zu verbringen. Außerdem wird dem Zuschauer in meinen Augen vorgegaukelt, dass man ein echtes High-End-Handy bräuchte. Doch oftmals reicht schon eine Kamera und die Unterstützung von Java-Applikationen, was inzwischen ja nun wirklich mindestens jedes zweite neu produzierte Handy leistet.

ShotCode ist einer dieser lizenzpflichtigen, runden und proprietären Codes. Und ShotCode hat just ein WordPress-Plugin veröffentlicht, mit denen Shotcodes erstellt werden können, die Links zum entsprechenden Blogeintrag beinhalten.

Ich habe eine kurze Weile überlegt, ob ich den Link zum Plugin hier veröffentlichen soll. Warum? Ganz einfach: die kommerzielle Nutzung der ShotCodes schlägt mit 50 € für 1-10 Codes zu Buche, ShotCode kann damit meiner Meinung nach schon fast als quasi „Premium-Anbieter“ im Bereich des Mobile Tagging gesehen werden. ShotCode versucht nun durch das Plugin seine Reichweite zu erhöhen und für mehr Akzeptanz zu sorgen. Dagegen ist natürlich nichts einzuwenden, schließlich steht dahinter ein Unternehmen welches nun mal Gewinne erwirtschaften möchte.

Doch Mobile Tagging findet hier in Europa (noch!) eine recht geringe Akzeptanz, die wenigsten Menschen hier wissen bisher etwas mit einem kryptischen 2D-Barcode anzufangen. Daher ist es meiner Meinung nach ein falscher Weg die Leute schon vor Alternativen zu stellen, bevor sich eine Technologie hier überhaupt durchgesetzt hat. Das erzeugt Verunsicherung und ggf. sogar Ablehnung gegen eine Technologie, die ich persönlich höchst innovativ und in vielen Bereichen super interessant finde.

Statt jetzt schon proprietäre Codes zu verbreiten, sollte dafür gesorgt werden, dass der gemeine Handy-Benutzer generell etwas mit derartigen Barcodes anfangen kann. Dazu eignen sich bisher QR-Codes und DataMatrix-Codes hervorragend. Beides sind ISO-Standards und beide wurden von der Open Mobile Alliance in einem Whitepaper (PDF als favorisierte 2D-Barcodes genannt (Mehr Infos dazu beim Mobile Zeitgeist). Zudem genießen diese beiden Codes in Asien bzw. der USA schon einiges an Beliebtheit.

Wer für ein Projekt die Unterstützung eines kommerziellen „High-End“-Anbieters im deutschsprachigen Raum benötigt, dem lege ich BeeTagg ans Herz. BeeTaggs sind vom Preis wesentlich günstiger, die Tags wurden für die Verwendung speziell mit Handykameras entwickelt und BeeTagg besitzt durch die Verwendung von einigen großen Unternehmen (darunter z.B. BMW oder Sony Ericsson) bereits einiges an Reputation, besonders im Heimatland Schweiz. Zudem erlaubt der BeeTagg-Scanner in der neuesten Version das Lesen von QR- und DataMatrix-Codes, was ihn zu einer echten Alternative werden lässt.

Wer das Shotcode-Plugin dennoch verwenden möchte, der kann es sich herunterladen unter der URL www.shotcode.org/wordpress. Die von mir eben angesprochenen Punkte sollten dabei aber bedacht und beherzigt werden. Wer sich stattdessen lieber einzelne QR- oder DataMatrix-Codes generieren möchte, der hat hier bzw. hier die Möglichkeit dazu.

Ein weiterer Beitrag zum Thema:
• Mobile Tagging Whitepaper: Expertenbefragung

Geändert hat sich seit dem Entwurf von November 2006 allerdings nichts mehr, was mich persönlich einerseits freut, andererseits auch ein wenig verwundert.

Die MWBP sind ein zentraler Bestandteil meines Buches über mobiles Webdesign. Diese werden dort auf gut 80 Seiten ausführlich erläutert und orientieren sich natürlich am Entwurf von November 2006. Beim Schreiben fiel mir auf, dass dort einige Passagen drin sind, die ich selbst für fragwürdig halte (entsprechende Stellen müssten im Buch gekennzeichnet sein).

Daher freue ich mich natürlich einerseits, dass das Buch nicht durch die Veröffentlichung der endgültigen Version an Aktualität verliert, andererseits wundere ich mich, dass diese fragwürdigen Stellen (ich weiß sie jetzt leider nicht aus dem Kopf) es tatsächlich in die endgültige Version geschafft haben.

Das erscheint mir ein wenig nach „Hey kommt Leute, wir verabschieden das Dokument jetzt einfach, dann haben wir mehr Platz für andere Dinge auf unserer ToDo-Liste“.

Wie dem auch sei, die MWBP 1.0 sind nun endlich final, wer seine mobilen Websites nach dem neuen Standard validieren will, findet beim W3C einen Validator, der sich allerdings ebenfalls noch im Betastatus befindet:
http://validator.w3.org/mobile/