Manuel-Bieh.de – Web-Development & Consulting

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.

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.

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.

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! ;-)

… wenn vielleicht auch nur langsam: bei insFX ist ein Artikel erschienen in dem schön beschrieben wird, was ich hier ja bereits öfters bemängelt hatte; nämlich die native Unterstützung der Standortermittlung im Browser.

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!

Nur mal eine kurze Zwischenfrage: kennt irgendwer eine Möglichkeit um Google Gears auf Symbian S60 3rd Geräten ans Laufen zu bringen? In meinem konkreten Fall geht es um den Nokia E90 Communicator. Wie es aussieht, scheint Gears nur auf Windows Mobile 5/6 Geräten und natürlich Android zu laufen. Jedenfalls konnte ich nichts anderes finden. Hat da also jemand vielleicht einen heißen Tipp für mich?

Michael Arrington schrieb am 22. März 2006 bei TechCrunch:

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 …

Die Wikipedia ist nun offiziell auch mobil erreichbar:
http://mobile.wikipedia.org/

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

Mal wieder etwas Werbung in eigener Sache.

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.