www.video-flash.de / html5-mobile.de

Flash CS6: Flashprojekt als HTML exportieren

Fri, 11 May 2012 20:06:18 +0200

Seit einigen Tagen gibt es die neue Version Flash CS6. Adobe selbst hebt dieses Mal recht wenige Neuerung hervor, u.a.: HTML-Export (CreateJS-Framework) Stage 3D-API und Starling-Framework 2D-Inhalte AIR-Anwendungen inklusive der Runtime (Captive Runtime) Simulation von AIR-Apps auf mobilen Endgeräten Spannend ist auf jeden Fall der HTML-Export von Flashprojekten, da damit zum ersten Mal ein gängiges [...]

Google+: Datenschutzkonformer Link zum Teilen von Inhalten

Wed, 25 Apr 2012 21:53:03 +0200

Google bietet jetzt endlich die Möglichkeit, das Teilen von Inhalten über einen einfachen URL-Aufruf anzustoßen. Bisher war die Share-Funktionalität lediglich über den +1-Button möglich, der jedoch die Einbindung eines JavaScripts von Google-Servern erforderlich machte — dies ist jedoch aus Datenschutz-Sicht bedenklich. Das Teilen auf Google+ mittels des neuen Share-Links stellt hier eine unbedenkliche Alternative dar, [...]

Mobile Website: Die Wahl der Domain

Sun, 01 Apr 2012 16:35:37 +0200

Das Festlegen einer Domain für die mobile Website scheint ein Detail am Rande zu sein, das oftmals vernachlässigt wird. Ein genauer Blick empfiehlt sich jedoch, da die verschiedenen Varianten durchaus signifikante Vor- und Nachteile haben.

Varianten für die mobile Domain

Beim Anlegen einer mobilen Website steht man vor der Wahl, wie diese zu erreichen sein soll. Die naheliegenden Varianten, die sich anbieten, dürften folgende sein:

neue Second-Level-Domain (z.B. example.mobi oder example-mobil.com)
neue Subdomain (z.B. m.example.com oder mobile.example.com)
neues Verzeichnis (z.B. www.example.com/mobile)

Um mein Fazit vorwegzunehmen: Meines Erachtens ist m.example.com die beste Lösung. Im Folgenden sowohl technische als fachliche Gründe, die aufzeigen, warum dies so ist.

Ein Plädoyer für m.

Kurz und knapp

Das Tippen auf einem Smartphone ist deutlich anstrengender als auf einer normalen Tastatur, weshalb die einzugebende URL möglichst kurz sein sollte. Hier kann die mobile Subdomain m. mit 2 Zeichen auftrumpfen, während eine Subdomain wie mobile.example.com deutlich länger ist und die Gefahr erhöht, sich zu verschreiben. Wermutstropfen: Leider ist das einzelne m dafür nicht mehr sprechend, so dass ganz unerfahrene Zielgruppen die Bedeutung „m(obile)” nicht verstehen könnten — ebenso wie sie es gewohnt sind, ihr Eingabe immer mit „www” zu beginnen.

An den populären Websites orientieren

Einen guten Anhaltspunkt bietet oftmals die Frage: Wie machen es die großen Anbieter? Hier ergibt sich ein eindeutiges Bild, wenn man die ersten Ränge der weltweit populärsten Websites betrachtet:

Die weltweit am häufigsten genutzten Websites verwenden die m.-Subdomain für die mobile Version

Da diese Websites die meisten Besucher haben, prägen sie das Bild der Nutzer und schaffen somit einen de facto Standard.

Die Marke stärken

Aus Marketing-Sicht setzt man häufig alles daran, den Nutzer auf die eigene Domain (www.example.com) zu bringen. Die gleiche Domain für die mobile Website zu verwenden (m.example.com) stärkt die Marke und verhindert, dass der Nutzer sich eine zweite Domain merken muss (z.B. www.example.mobi oder vielleicht etwas im Stile von www.example-online.mobi, da die gleichnamige Domain bereits anderweitig vergeben ist).

Suchmaschinenoptimierung (SEO)

Auch das Thema Suchmaschinenoptimierung spricht für eine Subdomain à la m.example.com: Man fängt nicht bei Null an, sondern bekommt einen „Bonus” durch die bereits existierende reguläre Website.

Länder-Websites

Im Corporate-Umfeld muss oftmals auch über die Landesgrenzen hinweg mitgedacht werden. Wenn Länder-Gesellschaften ihr eigenen Webauftritte unter der landesüblichen Domain (.de, .ch, .fr, etc.) haben, so kann das mobile Domainkonzept problemlos auf die gleiche Weise fortgeführt werden (m.example.fr). Bei einer .mobi-Domain muss eine andere Systematik eingeführt werden.

Hat man eine globale Domain (z.B. alle Länder unter .com), so muss man mit der m.-Subdomain lediglich neben der Ländererkennung noch eine weiteres Segment in der URL für die mobile Seite einführen. Wikipedia leitet beispielweise bei der Eingabe von m.wikipedia.org auf die mobile Website des entsprechenden Landes (de.m.wikipedia.org). Schöner als bei Wikipedia sieht das ganze aus, wenn man die Länder über Verzeichnisse erreicht (m.example.com/de/).

Cookie-Support

Erst auf den zweiten Blick fällt auf, dass ein Domainkonzept mit der mobilen Website unter der m.-Domain einen weiteren Vorteil bietet: Cookies erlauben es, so gesetzt zu werden, dass sie von allen Domains und Subdomains einer Second-Level-Domain ausgelesen werden können (z.B. .example.com, www.example.com, m.example.com) .

Somit ist es beim einem Kunden-Login beispielweise möglich, dass der eingeloggte Status auf der mobilen und regulären Website erhalten bleibt.

Wechsel zwischen regulärer und mobiler Website

Es kann durchaus vorkommen, dass man versehentlich auf der mobilen Website landet, wenn man im Desktop-Browser surft (z.B. über ein Link, der auf Facebook gepostet wird). Der Idealfall sieht dann so aus: Man ändert die Subdomain von m auf www und bekommt die reguläre Version dieser Seite zu sehen. Dies lässt sich am Beispiel YouTube übrigens in Aktion sehen (m.youtube.com/watch?v=V_MmgpGWqpA und www.youtube.com/watch?v=V_MmgpGWqpA).

Grundsätzlich ginge dies zwar auch mit einer .mobi-Domain, finde ich aber für den Nutzer dann nicht so offensichtlich zu erkennen.

Administration

Ganz pragmatisch gedacht, sprechen zuletzt administrative und finanzielle Gründe für die mobile m.-Subdomain:

Die Subdomain ist im Gegensatz zu Top-Level-Domains immer frei, kann nicht im Besitz von anderen sein und muss nicht angeschafft werden.
Die Subdomain verursacht keine zusätzlichen Kosten.
Die Einrichtung ist schnell und einfach.

Fazit

Fasst man alle Argumente zusammen, so ist die m.-Domain meiner Meinung nach der klare Sieger. Dies sollte mit einem sinnvollen Routing des mobilen Traffics von der regulären Seite kombiniert werden (dazu ein anderes Mal mehr).

Kennt ihr noch andere Gründe, die für oder gegen die besprochenen Varianten sprechen? Einfach einen Kommentar hinterlassen.

Die wichtigsten mobilen User Agents

Tue, 27 Mar 2012 20:35:52 +0200

In manchen Fällen ist es notwendig, mobile Devices anhand ihres User Agents zu erkennen (z.B. serverseitige Weiterleitung auf mobile Website). Im Folgenden ein Überblick über die User Agents der populärsten Devices (iOS, Android, BlackBerry, Kindle, Windows Phone).

Zur Erinnerung: Stellt ein Browser einen Request an einen Server, überträgt er seinen Namen („User Agent”) im HTTP-Header. Der Name wird in Form eines Strings übertragen, der z.B. über das Gerät, Betriebssystem und Browser inklusive entsprechender Version Auskunft gibt. Aus historischen Gründen sind auch einige Altlasten enthalten, so beginnen z.B. alle Browser mit Mozilla/5.0, nicht nur Firefox.

User Agent vs. Feature Detection

Grundsätzlich sollte man vorsichtig, einzelne Features und Funktionen anhand des User Agents (UA) auszuliefern. Das Problem hierbei ist, dass ständig neue User Agents im Umlauf sind und es schwierig ist, immer eine aktuelle und korrekte Zuordnung zu gewährleisten.

Sinnvoller ist stattdessen der Ansatz, über eine Feature Detection (z.B. mit der JavaScript-Bibliothek Modernizr) zu prüfen, was der Browser tatsächlich kann. Auch jQuery Mobile bietet eine JavaScript-Funktion gradeA, die zurückgibt, ob ein Device vollständig unterstützt wird und alle benötigten Funktion bietet.

Serverseitige Weiterleitung auf mobile Website

Nichtsdestotrotz gibt es Fälle, in denen man nicht am Auslesen des User Agents vorbeikommt. Hat man z.B. eine Website (www.domain..), die eine Startseite mit hoher Datenmenge besitzt, möchte man mobile Devices beim Aufrufen dieser direkt auf eine mobile Variante weiterleiten (m.domain..). Dies wäre mit einer Feature Detection in JavaScript nur bedingt sinnvoll, da das Device die „schwergewichtige” Startseite herunterladen muss.

Besser ist es, den User Agent serverseitig z.B. über den Apache oder PHP auszulesen und das Device direkt auf die mobile Website weiterzuleiten. So wird nur die mobile und optimierte Startseite mit geringer Datenmenge heruntergeladen, auf der man den Nutzer dann per Dialog noch fragen kann, ob er auch tatsächlich die mobile Website ansehen möchte.

Übersicht der wichtigsten User Agents

Im Folgenden eine Sammlung der wichtigsten User Agents und entsprechender Quellenangaben. Es handelt sich übrigens um Devices, die auch von jQuery Mobile unterstützt werden.

Außerdem habe ich jeweils einige Vorschläge für Regular Expressions hinzugefügt, um den User Agent abzufragen (am Beispiel einer PHP-Konstanten). Zum einen in einer recht einfachen Variante (die im Zweifel eher öfters greift), als auch ein exakteren Variante mit Versionsnummern.

iOS

Der User Agent unterscheidet sich bei den iOS-Geräten nur an der Stelle, die Auskunft über das Gerät (iPod, iPhone, iPad) gibt.

iPhone (Smartphone)

Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5

/*
* Simple:	iPhone
* Exact:	iPhone with iOS 3_2/3_2_ oder higher
*/
const iPhone_simple = "/iPhone/";	
const iPhone_exact = "/iPhone.* (([3]_[2-9](_| ))|([4-9]_[0-9](_| )))/";

iPod (Smartphone)

Mozilla/5.0 (iPod; U; CPU iPhone OS 4_3_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5

iPad (Tablet)

Mozilla/5.0 (iPad; U; CPU OS 4_3_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5

/*
* Simple:	iPad
* Exact:	iPad with iOS 3_2/3_2_ oder higher
*/
const iPad_simple = "/iPad/";	
const iPad_exact = "/iPad.* (([3]_[2-9](_| ))|([4-9]_[0-9](_| )))/";

Link: Apple Safari Web Content Guide

Android

Erwähneswert ist, dass bei Android-Smartphone immer die Kombination Android … Mobile vorkommt, während Android-Tablets lediglich Android (ohne Mobile) haben.

Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

/*
* Simple:	iPad
* Exact:	iPad with iOS 3_2/3_2_ oder higher
*/
const iPad_simple = "/Android.*Mobile/";

Link: Best Practices for Web Apps

BlackBerry

BlackBerry 6 and 7 (Smartphone)

Mozilla/5.0 (BlackBerry; U; BlackBerry AAAA; en-US) AppleWebKit/534.11+ (KHTML, like Gecko) Version/X.X.X.X Mobile Safari/534.11+

/*
* Simple:	BlackBerry
* Exact:	BlackBerry 6 or higher 
*/
const BlackBerry_simple = "/BlackBerry/";	
const BlackBerry_exact = "/BlackBerry.*Version\/[6-9]\./";

PlayBook (Tablet)

Mozilla/5.0 (PlayBook; U; RIM Tablet OS 1.0.0; en-US) AppleWebKit/534.8+ (KHTML, like Gecko) Version/0.0.1 Safari/534.8+

/*
* Simple:	PlayBook
* Exact:	PlayBook with OS 1.0 or greater
*/
const PlayBook_simple = "/PlayBook/";	
const PlayBook_exact = "/PlayBook.*OS [1-9]\./";

Link: How to detect the BlackBerry Browser

Kindle

Kindle (Tablet)

Mozilla/5.0 (Linux; U; en-US) AppleWebKit/528.5+ (KHTML, like Gecko, Safari/528.5+) Version/4.0 Kindle/3.0 (screen 600×800; rotate)

/*
* Simple:	Kindle
* Exact:	Kindle 3 or higher
*/
const Kindle_simple = "/Kindle/";	
const Kindle_exact = "/Kindle\/[3-9]/";

Kindle Fire (Tablet)

Mozilla/5.0 (Linux; U; Android 2.3.4; en-us; Kindle Fire Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

const KindleFire_simple = "/Kindle Fire/";

Link: The User Agent String of Kindle Fire Revealed

Opera Mobile

Opera/9.80 ($OS; Opera Mobi/$BUILD_NUMBER; U; $LANGUAGE) Presto/$PRESTO_VERSION Version/$VERSION

Link: Opera’s User Agent String

Windows Phone

IE9 on Mango

Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0; <manufacturer>; <model> [;<operator])

/*
* Simple:	Windows Phone
* Exact:	Windows Phone 7 or higher
*/
const WindowsPhone_simple = "/Windows Phone/";	
const WindowsPhone_exact = "/Windows Phone OS [7-9]/";

Link: Introducing the IE9 on Windows Phone “Mango” User Agent String
Link: Introducing IE9’s User Agent String

Neuer Blog html5-mobile.de

Sun, 25 Mar 2012 13:34:21 +0200

Ich möchte kurz auf meinen neuen Blog hinweisen: html5-mobile.de. Der Schwerpunkt liegt wie unschwer zu erkennen auf mobilen Web-Themen. Insgesamt ist die Seite noch im (technischen) Aufbau. Interessante Inhalte sind aber bereits publiziert — und auf die kommt es ja an: Website-Bilder für das Retina Display optimieren Mobile Devices: Viewport richtig einstellen Googles Android-Font: Kostenlose [...]

Website-Bilder für das Retina Display optimieren

Sun, 25 Mar 2012 11:03:00 +0200

Erstellt man Websites und betrachtet sie zum ersten Mal z.B. auf einem iPhone 4/4s, stellt eventuell man fest: Manche Bilder sind irgendwie nicht richtig scharf!

Die Ursache ist einfach erklärt: Im Falle der Apple-Geräte (ab iPhone 4) haben diese das sogenannte Retina-Display mit sehr hoher Pixeldichte, die „normale” Bilder vergleichweise unscharf aussehen lässt, wenn man diese mit „optimierten” Bildern vergleicht.

Im Folgenden deshalb zwei Möglichkeiten, wie man recht einfach Bilder mit höherer Auflösung integrieren kann, die dann deutlich besser aussehen.

Retina-Optimierung für das HTML-Element (`img`)

Das Prinzip, um ein Bild mithilfe des img-Elements für das hochauflösende Display zu verbessern, ist einfach: Man erstellt die Bilddatei mit den doppelten Maßen (z.B. 248×220 statt 124×110), zeigt sie jedoch in der einfachen Größe (124×110) an. Die vorhandenen Mehrinformationen im Bild werden auf einem hochauflösenden Display dargestellt, während z.B. am Rechner zwischen den beiden Bilder kein Unterschied zu sehen ist.

Der Faktor 2 ergibt sich übrigens aus den Vorgaben des Herstellers und ist somit (eigentlich) speziell für Apple iPhone und iPad.

Abfotografiert: Deutliche Unterschiede zwischen dem normalen Icon (links) und der optimierte Version (rechts)

Der Nachteil liegt in der gestiegenen Dateigröße der Bilder. Je nach Bildinhalt und verwendetem Dateiformat muss hier letztlich zwischen Ladezeit und Darstellungsqualität abgewogen werden. Bei Vektorgrafiken wie Icons, Firmenlogo, etc. lohnt sich dies in der Regel, da die Größe nur unwesentlich zunimmt, die Grafiken jedoch deutlich besser aussehen.

Am Rande sei erwähnt, dass aufgrund dieser Limitierung nicht umsonst in letzter Zeit die Rufe nach einem neuen HTML-Element (z.B. picture) laut werden, dass mehrere Bildquellen unterstützen soll. Dies würde die Möglichkeit bieten, sowohl für unterschiedliche Pixeldichten als auch Darstellungsgrößen (Stichwort „Responsive Webdesign”) verschiedene Bilder zu hinterlegen.

Ausprobieren lässt sich die Darstellungsqualität mit folgendem Beispiel (es handelt sich um die ersten beiden Logos). Das normale Bild (cloud-sd) hat tatsächlich 124x110px, während cloud-hd 248x110px hat.

<img width="124" height="110"  src="cloud-sd.png" />
<img width="124" height="110"  src="cloud-hd.png" />

Retina-Optimierung für Hintergrundbilder (CSS)

Etwas flexibler sind die Möglichkeiten, wenn man ein Bild als Hintergrund definiert. Hier kann man über Media Queries gezielt das Display mit der höheren Pixeldicht ansprechen und diesem gezielt eigene Styles zuordnen.

Das folgende Code-Beispiel zeigt einen unoptimierten div mit der Klasse cloud-default und einen div mit der Klasse cloud-for-retina für das Retina-Display. Zweiterer sieht auf normalen Displays gleich aus, der CSS-Stil wird jedoch für Retina-Displays überschrieben und verweist auf ein hochauflösendes Bild, was in einer besseren Darstellung resultiert.

<style type="text/css"> 
.cloud-default, .cloud-for-retina {                       
	width: 124px;
	height: 110px;
	background: url(cloud-sd.png);
	display: inline-block;
}
 
@media only screen and (-webkit-min-device-pixel-ratio: 2) {
	.cloud-for-retina {
		background: url(cloud-hd.png); 
		background-size: 124px 110px;
	}
}
</style>     
 
[...]
 
<div class="cloud-default">  
</div>
 
<div class="cloud-for-retina">  
</div>

Der obige Quellcode stammt aus dem gleichen Beispiel wie oben (es sind die letzten beiden Logos in der Ansicht).

Mobile Devices: Viewport richtig einstellen

Sat, 17 Mar 2012 13:46:53 +0100

Zu den absoluten Grundlagen der mobilen Entwicklung gehört das Meta-Element viewport. Diese eine Zeile HTML-Code sorgt für eine korrekte Skalierung der Website beim ersten Aufruf auf dem mobilen Gerät.

Die Browser der mobilen Devices gehen zuerst einmal davon aus, dass Websites nicht für mobile Endgeräte ausgelegt sind und die Website-Breite die Display-Breite um einiges übersteigt. Der Browser-Viewport (Anzeigebereich) ist deshalb z.B. in Mobile Safari auf eine Breite von 980 Pixeln eingestellt, so dass die meisten Website komplett zu sehen sind. Logischerweise mit dem Nachteil, dass die Inhalte sehr klein und Schriften nicht lesbar sind. Der Nutzer muss dementsprechend hineinzoomen.

Viewport für normale Websites einstellen

Die Einstellung des Viewport lässt sich sehr einfach über ein HTML-Element anpassen. Apple selbst schreibt, dass es sich dabei um die wichtigste Einzelmaßnahme zur Optimierung für iOS handelt.

This is the single most important optimization that you can do for iOS—make sure your webpage looks good the first time it is displayed on iOS.

Weicht die eigene Website von der oben genannten Standardbreite ab, so kann man den Viewport anpassen. Dadurch kann man dafür sorgen, dass Inhalt und Anzeigebereich übereinstimmen. Bei schmaleren Layouts wird dadurch z.B. kein unnötiger Platz verschenkt, sondern die Website in der möglichen Maximalgröße dargestellt.

Startansicht von apple.com auf mobilen Device (links) und gezoomte Ausschnitt mit lesbarer Schrift (rechts)

Für die Änderung fügt man folgende Zeile in den HTML-Head ein, die dann von mobilen Geräten ausgewertet wird.

<!DOCTYPE html>
<head>
    <meta name="viewport" content="width=1024" />
</head>
<body>
</body>

Viewport für mobile Websites anpassen

Handelt es sich um Website, die speziell für mobile Devices erstellt oder optimiert ist, geht man meist nicht den obigen Weg, eine fixe Breite für den Viewport anzugeben (Ein iPhone hat z.B. im Hochformat eine Breite von 320px und im Querformat 480px). Dies hätte zur Folge, dass im Hoch- und Querformat die gleichen Inhalte, lediglich in einem unterschiedlichen Zoomlevel, gezeigt würden.

Stattdessen wird deshalb üblicherweise folgende Formel verwendet: Breite des Viewports = Breite des Devices. Konkret bedeutet dies: Das iPhone hat 320px Breite im Hochformat, weshalb genau 320px der Website gezeigt werden (1:1-Darstellung). Ebenso werden im Querformat dann 480px gezeigt. Diese flexible Einstellung ist einerseits geräteunabhängig und ermöglicht es andererseits auch, im Querformat den gewonnen Platz in der Breite sinnvoll zu nutzen.

Vergleich: Ansicht auf mobilem Device mit Meta-Element im Quellcode (links; width=device-width) und ohne (rechts)

Dies abgebildete Beispiel lässt sich hier ausprobieren: Beispiel mit Viewport-Einstellung und Beispiel ohne Viewport-Einstellung

An dieser Stelle sei kurz auf einen iOS-Bug hingewiesen, der manchen beim Ausprobieren und Einstellen des Viewports verwirren könnte: Skalierungsfehler beim Drehen ins Querformat

Viewport-Einstellungen

Das Meta-Element für den Viewport besitzt neben der Breite weitere Eigenschaften, die komma-separiert aufgelistet werden.

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">

initial-scale: Der Wert legt den anfänglichen Zoomgrad fest. 1.0 führt dazu, dass die Inhalte 1:1 dargestellt werden, d.h. auf einem Screen mit 320px Breite füllt eine 320px-breite Grafik die komplette Breite aus (siehe auch Screenshot oben). Dementsprechend führt z.B. 2.0 zu einer 2x-fachen Vergrößerung.
user-scalable: Mit diesem Attribut kann man definieren, ob der Nutzer auf der Seite zoomen kann (yes) oder nicht (no).
minimum-scale und maximum-scale: Diese beiden Eigenschaft ermöglichen es, den Zoomgrad einzuschränken. Setzt man z.B. die maximale Skalierung auf 2.0, kann der Inhalt maximal 2x-fach vergrößert werden.

Quellen

Link: Configuring the Viewport (iOS)
Link: Targeting Screens from Web Apps (Android)

Googles Android-Font: Kostenlose Schrift Roboto

Tue, 13 Mar 2012 22:00:30 +0100

Die Schrift „Roboto” wurde mit Android 4.0 eingeführt. Sie kann jetzt kostenlos heruntergeladen werden.

Roboto has a dual nature. It has a mechanchical skeleton and the forms are largely geometric. At the same time, the font features friendly and open curves. While some grotesks distort their letterforms to force a rigid rhythm, Roboto doesn’t compromise, allowing letters to be settle in to their natural width. This makes for a more natural reading rhythm more commonly found in humanist sans serifs.

Die Schriftfamilie wurde speziell für Benutzeroberfläche und (mobile) Bildschirme mit hohen Auflösungen erstellt. Google erlaubt die Nutzung der Schrift ohne Einschränkungen. Ich habe sie testweise mit einen Online-Generator als Web-Schrift umgewandelt, so dass man sie auf einer Webseite einbinden kann: Beispiel anschauen (Schriftschnitt Black).

Link: Roboto Font (Android Design – Typography)
Link: Specimen Book (PDF)

Kostenlose 90-seitige Studie: Cross-Platform Developer Tools

Mon, 12 Mar 2012 21:14:50 +0100

Our report is based on a 6-month project, comprising a large-scale online developer survey (nearly 2,500 respondents) combined with meticulous research, vendor interviews and analysis of this complex market of over 100 tools vendors.

Wer sich zum Thema „Cross-Platform-Entwicklung” einen Überblick verschaffen, sollte die englischsprachige Studie von Vision Mobile lesen. Auf 90 Seiten sind u.a. die Ergebnisse einer Umfrage unter 2.500 Entwickler und aktuelle Marktanalysen aufbereitet. Der Download ist kostenlos.

Link: [New report] Cross-Platform Developer Tools 2012

Adobe Shadow: Remote-Debugging für den mobilen Browser

Wed, 07 Mar 2012 22:49:39 +0100

Adobe Shadow ist ein interessantes neues Tool von Adobe, das als Betaversion in den Adobe Labs heruntergeladen werden kann. Es ermöglicht eine Remote-Verbindung zu einem Browser auf iOS- oder Android-Devices. Außerdem kann man über die gewohnten Entwicklerwerkzeuge ein Remote-Debugging durchführen.

Was kann Adobe Shadow?

Die Devices zeigen die Webseite des Desktop-Browsers

Shadow ermöglicht eine Remote-Verbindung zu einem Browser auf dem mobilen Device. Konkret heißt dies: Man surft eine Seite im Browser des Desktop-Rechners an, worauf sich diese Seite automatisch im mobilen Browser öffnet. Dies funktioniert auch mit mehreren Devices, so dass man ein komplettes Gerät-Set „fernsteuern” kann. Verantwortlich für die Synchronisierung ist eine Browser-Extension auf dem Desktop-Rechner.

Remote Debugging

Bei Bedarf kann man eine spezielle Variante des Web Inspectors starten, dem Pendant zu Firebug in der Webkit-Welt. Dadurch hat man wie gewohnt Zugriff z.B. auf den Quellcode oder die Styles. Manipuliert man etwas im HTML-Code, ändert man einen Style oder führt JavaScript-Code in der Konsole aus, lassen sich die Auswirkungen direkt auf dem Gerät beurteilen. Selbst das Hervorheben des UI-Elements beim Mouseover über ein HTML-Element im Quellcode funktioniert.

Remote-Aufruf von JavaScript auf einem Device per Konsole des Desktop-Rechners

Wie funktioniert Shadow?

Shadow besteht aus 3 Teilen:

Eine Browser-Extension für Chrome dient zur Steuerung. Das aktuelle Fenster wird mit den gewünschten Devices synchronisiert.
Jedes Devices braucht eine App, die aus dem entsprechenden App-Store heruntergeladen werden kann. In dieser App wird dann die mobile Website angezeigt.
Damit die Verbindung zwischen den Geräten im Netz aufgebaut werden kann, wird eine kleine Anwendung benötigt, die lediglich auf dem Desktop im Hintergrund laufen muss.

Link: Adobe Shadow

iOS-Bug: Skalierungsfehler beim Drehen ins Querformat

Sun, 04 Mar 2012 11:17:28 +0100

Betrachtet man eine mobile Website auf dem iPhone und dreht das Gerät vom Hoch- ins Querformat, schlägt er meist zu: der iOS-Scale-Bug.

Skalierungsfehler beim Wechsel ins Querformat

Dreht man ein Website ins Querformat (Landscape), die per Quellcode das Hineinzoomen über die 2-Finger-Geste „Pinch-to-Zoom” erlaubt, tritt der iOS-Scale-Bug auf: Die Breite des Viewports wird nicht richtig bestimmt und es fehlt ein bisschen, da zu nah reingezoom wird (siehe Abbildung). Der Nutzer muss deshalb händisch etwas herauszoomen.

Beispiel: Ein Bild mit 100% Breite wird beim Wechsel ins Querformat nicht auf die Breite des Displays skaliert

Dieser Bug existiert schon seit längerer Zeit und wurde auch in iOS 5 nicht gefixt. Interessant ist allerdings, dass der Fehler in In-App-Browsern nicht auftritt. Native iOS-Apps, die die WebView benutzen, sind also nicht betroffen (obwohl die zugrunde liegenden WebView die gleiche ist wie bei Mobile Safari).

Wer dies selbst ausprobieren möchte: Einfach die folgende Beispielseite auf einem aktuellen iPhone von Hochformat (Portrait) ins Querformat (Landscape) drehen.

Wie kann der „iOS-Scale-Bug” verhindert werden?

Zoom ausschalten

Der Bug kann ganz leicht verhindert werden, indem man das Zoomen mit 2 Fingern („Pinch-to-Zoom”-Geste) ausschaltet. Dazu setzt man einfach die Minimum- und Maximum-Skalierung der Webseite auf den Faktor 1, womit kein anderer Zoomgrad möglich. Der Haken an der Sache: Man schränkt den Nutzer ein, da er nicht mehr wie gewohnt zoomen kann, was somit aus Usabilitygründen eigentlich nicht empfehlenswert ist. Dass das Problem dann nicht auftritt, zeigt diese Beispielseite.

<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1">

Workaround mittels Accelerometer

Seit kurzem gibt es einen Fix, der anhand des Beschleunigungssensor des Device bemerkt, wenn das Gerät gedreht wurde. Daraufhin deaktiviert das Skript kurzzeitig den Zoom, so dass die Skalierung im Querformat korrekt erfolgen kann. Anschließend wird der Zoom wieder aktiviert.

This fix works by listening to the device’s accelerometer to detect when an orientation change is about to occur. When it deems an orientation change imminent, the script disables user zooming, allowing the orientation change to occur properly, with zooming disabled. The script restores zoom again once the device is either oriented close to upright, or after its orientation has changed.

Was zunächst nach einem nicht sehr vertrauenswürdigen Workaround klingt, dürfte dennoch recht solide sein, da auch die kommende jQuery Mobile Version 1.1 diesen Fix integriert hat. Getestet wurde das Skript laut Autor auf iOS 4 und iOS 5. Ausprobieren lässt sich dies ebenfalls an einer Beispielseite

<script src="ios-orientationchange-fix.js"></script>

Link: A Fix for the iOS Orientationchange Zoom Bug
Link: iOS-Orientationchange-Fix (Github)

iOS: Links zu nativen Apps aus dem Browser heraus

Sat, 25 Feb 2012 19:57:22 +0100

Aus mobilen Websites oder Web-Apps kann man auf native Apps verlinken. Ob Telefonnummer wählen, Routenplaner starten oder Facebook-App öffnen: Dies alles funktioniert üblicherweise über die so genannte URL-Schemes.

Hier einige Aktionen, die man per Link aus dem mobilen Safari-Browser (iPhone und iPad) auslösen kann:

Email: Der Email-Client auf dem iPhone öffnet sich und man kann eine Email schreiben.
Telefon: Wählen einer Telefonnummer.
SMS: Senden einer SMS an eine Telefonnummer
Maps: Aufrufen der nativen Karten-App (Google Maps)
YouTube: Öffnen eines YouTube-Videos in der nativen YouTube-App.
Facebook: Öffnen der App und Anzeigen von bestimmten Inhalten

Der folgende Artikel zeigt, wie dies auf Apples iOS-Betriebssystem funktioniert. Auf einem iOS-Gerät kann man dies auch direkt an diesem Beispiel ausprobieren, das ich zu Demozwecken erstellt habe: Demo mit iOS-URL-Schemes.

Offizielle Apple-Apps aus dem Browser ansprechen

Der Vorteil der folgenden Apple-Apps liegt darin, dass diese auf jedem Apple-Gerät vorinstalliert und somit immer vorhanden sind. Dadurch funktionieren diese Links auf jeden Fall.

Email-Client öffnen

Bereits seit langem werden im Internet mailto:-Links verwendet, um den Standard-Email-Client zu öffnen. Auf dem iPhone geht dies auf die gleiche Weise, wodurch man z.B. den Empfänger, die CC-Empfänger, den Betreff und den Emailtext vordefinieren kann.

<a href="mailto:test@example.com">...</a>
<a href="mailto:test@example.com?cc=test2@example.com,test3@example.com">...</a>
<a href="mailto:test@example.com?subject=Neuer Betreff!&body=Neue Nachricht!">...</a>

Telefonnummer wählen und SMS schreiben

Sowohl des Anrufen einer Telefonnummer als auch das SMS-Schreiben funktionieren nach dem gleichen Prinzip: Man schreibt einfach einen gewöhnlichen Link mit der Ziel-URL tel: bzw. sms:. Bevor das Telefon die Nummer wählt, erfolgt ein Pop-Up mit einer Sicherheitsabfrage, ob der Anruf tatsächlich gewünscht ist. Ein Anruf auf dem iPad geht logischerweise nicht, weshalb das Tablet stattdessen die Option anbietet, die Nummer ins Adressbuch zu übernehmen. Da das iPad auch eine SMS-/Nachrichten-App, funktioniert das SMS-Schreiben auf dem Tablett von Apple ebenso.

<a href="tel:01234-123456">...</a>
<a href="sms:01234-123456">...</a>

Eigentlich sollten Telefonnummer auch automatisch erkannt werden, ohne diese speziell mit der genannten Methode explizit zu verlinken. Allerdings kann man so sicherstellen, dass dies auf jeden Fall korrekt implementiert ist. Werden fälscherweise andere Nummern auf der Website als Telefonnummer erkannt, lässt sich diese Auto-Erkennung übrigens auch deaktivieren.

iCal / Kalender

Ein Kalender im iCal-Format kann man über webcal:// verlinken, wodurch er in der iCal-App abonniert werden kann.

<a href="webcal://../basic.ics">...</a>

[ad]

Karten-App öffnen

Die Karten-App wird von iOS automatisch gestartet, wenn man von einer mobilen Website auf maps.google.com verlinkt. Es wird also anstatt eines URL Schemes einfach die Domainanfrage abgefangen. Mithilfe von Parametern in der URL kann man die gewünschte Darstellung festlegen. Man kann auch direkt in den Routenplaner-Modus springen, wenn man Source Address (saddr) und Destination Address (daddr) angibt. Eine Übersicht der Parameter findet man in der Apple-Doku.

<a href="http://maps.google.com/maps?q=marktplatz+bretten+deutschland">..</a>
<a href="http://maps.google.com/maps?saddr=Bretten,+Deutschland&amp;daddr=Karlsruhe,+Deutschland">...</a>

YouTube-Video anschauen

Um ein Video zu öffnen, muss man lediglich einen normalen Link auf YouTube setzen. iOS fängt dies wie bei Google Maps ab und öffnet darauf hin die native YouTube-App. Der Link setzt sich zusammen aus http://youtube.com/v/ und der Video-ID.

<a href="http://youtube.com/v/V_MmgpGWqpA">..</a>

Third-Party-Apps aus dem Browser öffnen

Alle nativen Apps können eigenen URL-Schemes definieren und auf einem iPhone registrieren, so dass diese z.B. aus Mobile Safari heraus aufgerufen werden.

One of the coolest features of the iPhone SDK is an application’s ability to “bind” itself to a custom URL scheme and for that scheme to be used to launch itself from either a browser or from another application on the iPhone.

Allerdings besteht das Problem, dass man nicht abfragen kann, welche Apps auf dem Smartphone installiert sind. Insofern ist ein bisschen Glückssache, ob der Link erfolgreich ausgeführt werden kann.

Facebook-App öffnen

Die bisher genannten Apple-Apps sind alle auf jedem iPhone vorhanden, was bei der offiziellen Facebook-App nicht der Fall ist. Allerdings ist die Wahrscheinlichkeit sehr hoch, dass ein Nutzer diese installiert hat, wenn er Facebook nutzt. Das passende URL-Schema für Facebook lautet fb:// und ist sehr umfangreich (und Facebook-typisch scheinbar nicht wirklich dokumentiert…). So öffnet fb://profile beispielsweise das Profil des Nutzers, fb://friends die Freundeliste oder fb://feed die aktuellen Neuigkeiten.

Interessant dürfte sicher die Frage sein, wie man einen bestimmten Nutzer (z.B. eine Fanpage) öffnet? Ganz einfach: Man öffnet seine Fanpage im Browser und ersetzt das www durch graph (z.B. http://graph.facebook.com/dm.Deutschland). Schon sieht man die User-ID, die man für das Schema fb://profile/[userid]/wall benötigt (fb://profile/129724513733284/wall).

Bei Details empfehle ich diese sehr umfangreiche Übersicht der Facebok-URL-Schemes, die knapp 200 Einträge enthält.

Quellen und Links

Link: Apple URL Scheme Reference
Link: iPhoneIntegration (Sample Code)
Link: Making a Phone Number clickable for iPhone Users
Link: Launching Your Own Application via a Custom URL Scheme
Link: IPhone URL Schemes

Swipe JS: Leichtgewichter Slider für Touch-Devices

Sat, 18 Feb 2012 12:08:06 +0100

Swipe JS ist ein leichtgewichtiges Slider-Skript, das den aus nativen Apps gewohnten Slide-Effekt beim „Swipen” nachahmt. Per Wische-Geste kann man so z.B. zwischen mehreren Bildern navigieren, wobei das Bild quasi am Finger „klebt”. Das Skript hat keine Abhängigkeiten zu anderen JavaScript-Bibliotheken. Swipe is a lightweight mobile slider with 1:1 touch movement. 1:1 touch movement is [...]

Firefox 10 mit Entwickler-Tools

Thu, 09 Feb 2012 00:15:00 +0100

Firefox hat in Version 10 ein Set an integrierten Entwickler-Tools spendiert bekommen. Enthalten sind im Wesentlichen die gängigen Funktionen, die man vom Firefox-Add-on Firebug oder dem Web Inspector der Webkit-basierten Browser kennt. With Page Inspector, developers can peek into a page’s structure and layout without having to leave Firefox. […] Style Inspector makes editing the [...]

Kostenloses PlayBook bei App-Einreichung bis 13. Februar

Sun, 05 Feb 2012 11:01:43 +0100

Kurz und knapp: Wer bis zum 13. Februar eine App in BlackBerry Store (BlackBerry App Worlds) einreicht, bekommt ein gratis BlackBerry PlayBook. Ursprünglich war diese Aktion gedacht, um die Möglichkeit zu bewerben, dass man als Entwickler nun auch Android-Apps sehr einfach auf das PlayBook portieren kann. Mittlerweile wurde die Aktion kurzfristig jedoch auch für die [...]

Twitter Bootstrap 2.0 erschienen

Thu, 02 Feb 2012 20:47:32 +0100

Im August 2011 hatte ich hier im Blog die erste Version von Twitter vorgestellt, einem HTML-/CSS-Framework, das ich übrigens auch für mein Projekt embed-swf.org verwendet habe. Nun ist die zweite Version des empfehlenswerten HTML-/CSS-Frameworks erschienen. Twitter gibt unter anderem folgende Verbesserung an: Completely overhauled documentation for nearly every component A brand new Customize page to [...]

HTML5: „Cut the rope” als Browserspiel

Tue, 10 Jan 2012 20:15:16 +0100

Das bekannte Casual Game „Cut the rope” wurde jetzt als HTML5-Browsergame veröffentlicht. Knapp 15.000 Zeilen JavaScript-Code zeigen, was mittlerweile in aktuellen Browser an Multimedialität und Interaktivität auf HTML-Basis möglich ist. Der interessante Hintergrundbericht „Behind the Scenes” gibt ergänzend dazu einen Einblick über die Portierung des Codes von Objective C nach JavaScript und die Performancebetrachtungen. Ein [...]

Vektorgrafiken aus Illustrator in HTML5-Canvas exportieren

Sat, 07 Jan 2012 00:47:39 +0100

Seit einiger Zeit gibt es ein Plug-In für Adobe Illustrator, um Vektorgrafiken in Richtung HTML5 zu exportieren. Das kostenlose „Ai->Canvas Plug-in” wandelt eine Illustratordatei in HTML-/JavaScript-Code um, der die Inhalte in ein HTML5-Canvas-Element zeichnet. Dies funktioniert nicht nur mit einfachen Grafiken, sondern auch mit komplexen Gestaltungen sehr gut. The Ai->Canvas plug-in enables Adobe Illustrator to [...]

HTML5: Eigene data-Attribute verwenden (data-*)

Sat, 17 Dec 2011 17:59:23 +0100

Ein neues Feature von HTML5 sind frei wählbare data-Attribute für HTML-Elemente, die sogenannten „Custom Data Attributes”. Die Idee ist dahinter ganz einfach: Man möchte eigene Daten an einem HTML-Element abspeichern, für die es kein vorgefertigtes Attribut gibt und die auch nicht direkt im Frontend zu sehen sein sollen. Insgesamt ein sehr nützliches Features, das im [...]

iOS: Links zu nativen Apps aus dem Browser heraus

Sun, 11 Dec 2011 17:36:10 +0100

In mobilen Websites oder Web-Apps kann es vorkommen, dass man gerne auf native Apps verlinken möchte. Ob Telefonnummer wählen, SMS schicken oder Facebook-App öffnen: Dies alles funktioniert üblicherweise über spezielle URLs, bei denen das http durch ein anderes Kürzel ersetzt wird (sogenannte URL-Schemes). Hier einige Aktionen, die man per Link aus dem mobilen Safari-Browser (iPhone [...]

www.video-flash.de / html5-mobile.de

Flash CS6: Flashprojekt als HTML exportieren

Google+: Datenschutzkonformer Link zum Teilen von Inhalten

Mobile Website: Die Wahl der Domain

Varianten für die mobile Domain

Ein Plädoyer für m.

Kurz und knapp

An den populären Websites orientieren

Die Marke stärken

Suchmaschinenoptimierung (SEO)

Länder-Websites

Cookie-Support

Wechsel zwischen regulärer und mobiler Website

Administration

Fazit

Die wichtigsten mobilen User Agents

User Agent vs. Feature Detection

Serverseitige Weiterleitung auf mobile Website

Übersicht der wichtigsten User Agents

iOS

iPhone (Smartphone)

iPod (Smartphone)

iPad (Tablet)

Android

BlackBerry

BlackBerry 6 and 7 (Smartphone)

PlayBook (Tablet)

Kindle

Kindle (Tablet)

Kindle Fire (Tablet)

Opera Mobile

Opera Mobile

Windows Phone

IE9 on Mango

Neuer Blog html5-mobile.de

Website-Bilder für das Retina Display optimieren

Retina-Optimierung für das HTML-Element (img)

Retina-Optimierung für Hintergrundbilder (CSS)

Mobile Devices: Viewport richtig einstellen

Viewport für normale Websites einstellen

Viewport für mobile Websites anpassen

Viewport-Einstellungen

Quellen

Googles Android-Font: Kostenlose Schrift Roboto

Kostenlose 90-seitige Studie: Cross-Platform Developer Tools

Adobe Shadow: Remote-Debugging für den mobilen Browser

Was kann Adobe Shadow?

Die Devices zeigen die Webseite des Desktop-Browsers

Remote Debugging

Wie funktioniert Shadow?

iOS-Bug: Skalierungs­fehler beim Drehen ins Querformat

Skalierungsfehler beim Wechsel ins Querformat

Wie kann der „iOS-Scale-Bug” verhindert werden?

Zoom ausschalten

Workaround mittels Accelerometer

iOS: Links zu nativen Apps aus dem Browser heraus

Offizielle Apple-Apps aus dem Browser ansprechen

Email-Client öffnen

Telefonnummer wählen und SMS schreiben

iCal / Kalender

Karten-App öffnen

YouTube-Video anschauen

Third-Party-Apps aus dem Browser öffnen

Facebook-App öffnen

Quellen und Links

Swipe JS: Leichtgewichter Slider für Touch-Devices

Firefox 10 mit Entwickler-Tools

Kostenloses PlayBook bei App-Einreichung bis 13. Februar

Twitter Bootstrap 2.0 erschienen

HTML5: „Cut the rope” als Browserspiel

Vektorgrafiken aus Illustrator in HTML5-Canvas exportieren

HTML5: Eigene data-Attribute verwenden (data-*)

iOS: Links zu nativen Apps aus dem Browser heraus

Retina-Optimierung für das HTML-Element (`img`)

iOS-Bug: Skalierungsfehler beim Drehen ins Querformat