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

Viewport resizer: Responsive Webdesign testen

Thu, 25 Oct 2012 23:31:45 +0200

Bookmarklet

Viewport Resizer ist ein kleines Browser-Bookmarklet, das beim Testen und Betrachten von Websites mit Responsive Webdesign hilft.

Das Browser-Bookmarklet Viewport Resizer wird zuerst in der Lesezeichenleiste abgespeichert. Anschließend steht es fortan bereit, um die gerade geöffnete Website in verschiedene Größen darzustellen. Bei Aktivierung erscheint eine Werkzeugleiste mit verschiedene Device-Presets (Smartphone, Tablet, selbst definierte Pixelmaße, etc.) und Ausrichtungen (Hoch-/Querformat). Per Klick kann man zwischen den verschiedenen Ansichten wählen.

Viewport Resizer ersetzt natürlich den Test mit echten Devices nicht, stellt aber eine schnelle Möglichkeit, um Websites in verschiedenen Maßen anzuschauen. Und dies ganz ohne den Browser selbst in der Größe zu ändern.

Geöffnete Website in der Smartphone-Ansicht

Link: Viewport Resizer

Performance-Studie: Wie schnell sind Websites beim mobilen Zugriff wirklich?

Sun, 14 Oct 2012 11:17:00 +0200

Eine aktuelle Studie von strangeloop enthält interessante Anhaltspunkte über die Performance von mobilen Websites. Im Juli und September 2012 wurden mit aktuellen Geräten (iPhone 4 + 5, iPad 2, Samsung Galaxy S + S3 + Tablet) über 200 E-Commerce-Sites getestet. Die Fragestellung lautet dabei hauptsächlich, wie die Performance über eine Mobilfunkverbindungen ist.

Einige Erkenntnisse sind beispielsweise:

Die durchschnittliche Ladezeit über 3G beträgt etwas über 11 Sekunden (während die meisten Nutzer eigentlich 4 Sekunden Ladezeit erwarten)
LTE ist in der Praxis lediglich 30% schneller (und nicht 10x schneller, wie es vermarktet wird)

Darüber sind noch einige Statistiken enthalten, die über die reine Performance hinausgehen (z.B. wie viele Websites sind nicht mobile-optimiert? Wo werden Tablets hingeleitet? etc.).

Tablets: Mobile Website oder „normale” Website?

Interessant finde ich z.B.: Ausnahmlos alle getesteten Websites führten ihre Besucher mit dem iPad auf die normale Website. Dies entspricht auch der landläufigen Meinung, dass ein Tabletnutzer das vollen Angebot genießen möchte.

Bei Android Tablet wurden nur 66% auf die reguläre Website geleitet, die restlichen 34% auf die mobile Website. Meiner Erachtens könnte dies auch daran liegen, dass aufgrund der geringen Anzahl an Android-Tablets die Android-Smartphone-Erkennung hier versehentlich zuschlägt (Anmerkung: Hier hatte ich beschrieben, wie man Android-Tablets und -Smartphones erkennen kann).

Link: How fast do sites really load for mobile user?
Link: State of mobile e-commerce performance

Android: Remote Debugging mit Chrome

Mon, 08 Oct 2012 22:20:36 +0200

Nach dem Artikel über Remote Debugging in iOS6 folgt eine kurze Anleitung, wie man ein solches Remote Debugging auch auf einem Android-Gerät durchführen kann.

Device vorbereiten

Als Basis dient ein Android-Smartphone mit Android 4 (Ice Cream Sandwich).

Zuerst muss man auf dem Android-Gerät die Option „Einstellungen > Entwickler-Optionen > USB-Debugging” aktivieren. Anschließend hängt man das Gerät per USB-Kabel an den Rechner.

Chrome

Man lädt Chrome aus dem Google Play Store, startet den Browser und aktiviert innerhalb des Programms den Menüpunkt „Einstellungen > Entwickler-Tools > Web-Debugging via USB aktivieren”.

Android SDK

Zuletzt ist noch das Android-SDK erforderlich. Nach dem Herunterladen muss man zuerst die Anwendung tools/android starten. Sie dient dazu, weitere Bestandteile nachzuladen. Für das Remote Debugging benötigt man die Android SDK Platform-tools (siehe Screenshot).

Installation des Android SDKs

Nach deren erfolgreicher Installation, enthält man einen neuen Ordner platform-tools mit der Anwendung adb.

Sicherheitshalber kann man mit adb devices prüfen, ob das Device korrekt erkannt wird (siehe Screenshot). Wenn ja, aktiviert man das Port-Forwarding über folgenden Befehl: adb forward tcp:9222 localabstract:chrome_devtools_remote

Remote Debugging Session starten

Nach den Vorbereitungen kann man nun los legen: Die Desktop-Version von Chrome starten und die URL localhost:9222 eingeben. Et voilà: Man sieht die Tabs von der mobilen Chrome-Version und kann über den Web Inspector die Inhalte vom Rechner debuggen.

Remote Debugging einer Website mit Chrome (Android)

Link: Remote Debugging

Neu in iOS6: Image-Sets

Sat, 29 Sep 2012 13:00:12 +0200

Ich hatte bereits erklärt, wie man Bilder für das Retina-Display optimiert. Neu in iOS6 ist eine vereinfachte Syntax, um die Bilder in unterschiedlichen Auflösungen anzugeben.

Mit der in iOS6 verwendeten Webkit-Version sind erstmals Image-Sets möglich. Dies bedeutet, man kann mehrere Bilder angeben und der Browser entscheidet, welches er laden und anzeigen möchte.

Beispiel:
background-image: -webkit-image-set( url(cloud-sd.png) 1x, url(cloud-hd.png) 2x).

„1x” bedeutet, dass das Bild für ein normales Display gilt, während „2x” für ein hochauflösendes Display steht (das Retina-Display hat bekanntlich die doppelte Auflösung).

Image-Set: Normales Bild (links) und hochauflösendes Bild (rechts) im Chrome-Browser, iOS6

Neue Syntax als Alternative zu Media Queries

Die neue Syntax kann somit als Alternative zu den Media Queries verwendet werden (siehe in der Einleitung verlinkter Artikel). Der Vorteil: Die neue Syntax ist wesentlich kompakter, leichter zu lesen und alle Infos stehen an einer Stelle im CSS.

Die Image-Sets funktionieren jedoch nur für Hintergrund-Bilder, nicht für img-Elemente.

Zukünftig könnte man sich vorstellen, dass die Browser die Angaben nicht nur hinsichtlich des Displays auswerten, sondern z.B. auch die aktuelle Internetverbindungen berücksichtigen (und so z.B. trotz Retina-Display bei einer Edge-Verbindung das normale Bild laden).

Voraussetzung für Image-Sets

Die Image-Sets funktionieren zurzeit auf jeden Fall in Mobile Safari und Chrome auf iOS6. Ob es auch auf einem Macbook mit Retina-Display funktioniert, kann ich leider nicht sagen.

Beispiel-Code für Image-Set

Hier ein konkretes Beispiel, dass die neue Syntax in Aktion zeigt. Über CSS wird einem div ein Image-Set zugewiesen. Kennt ein Browser keine Image-Sets, so greift nur die erste Zeile.

background: url(cloud-sd.png); background-image: -webkit-image-set(url(cloud-sd.png) 1x, url(cloud-hd.png) 2x);

Adobe Edge Web Fonts: Über 500 kostenlose Schriften

Tue, 25 Sep 2012 22:18:45 +0200

Mit Adobe Edge Web Fonts startet Adobe einen neuen kostenloses Webfonts-Service.

Neues Mitglied in der Adobe-Familie: Der Webfont-Dienst Adobe Edge Web Fonts

Im Zug der Vorstellung der Edge-Produktfamilie hat Adobe bekannt gegeben, dass auch ein kostenloser Service für Webschriften Teil dessen ist: Adobe Edge Web Fonts. Die Lösung bietet über 500 kostenlose Schriften, die auf einfache Weise in die eigene Website eingebunden werden können.

Edge Web Fonts features hundreds of web fonts, including a sampling of fonts from the Adobe library as well as a large collection of open source fonts. Under the hood, the service is powered by Typekit

Hier zeigen sich also die ersten Ergebnisse der Acquise von Typekit, die von Adobe im Oktober 2011 übernommen wurden. Somit kann man sich auch sicher sein, dass hier die gewünschte Performanz und Stabilität gewährleistet ist.

Die entsprechende Code-Beispiel zur Einbindung werden mitgeliefert.

Link: html.adobe.com/edge/webfonts/
Link: www.edgefonts.com
Link: Introducing Adobe Edge Web Fonts (Typekit)

iOS6: Remote Debugging

Sun, 23 Sep 2012 23:13:06 +0200

Mit dem kürzlich erschienen iOS6 wurde endlich eine vernünftige Remote-Debugging-Lösung geschaffen, um eine Website zur Laufzeit zu untersuchen (wie von Firebug oder Web-Inspector auf dem Desktop gewohnt).

Remote Debugging: Der Web Inspector auf dem Rechner zeigt die Inhalte von Mobile Safari

Wie funktioniert das Remote-Debugging für iOS-Devices?

Ganz einfach: Man kann eine Website und deren Zustand auf dem mobilen Device untersuchen und ggf. auch manipulieren. Dazu wird der Web Inspector verwendet, der jedoch auf der Desktop-Version von Safari läuft. Man verknüpft ihn mit dem gewünschten Browserfenster auf dem iPhone, woraufhin die Inhalte der auf dem mobilen Device laufenden Website angezeigt werden. Deshalb auch Remote Debugging.

Bis iOS5 stand lediglich ein sehr einfache Konsole bereit, die jedoch keinerlei tiefergreifende Analysen ermöglichte. Da nun der Web Inspector verwendet wird, stehen einem somit alle gängige Werkzeuge zur Verfügung (HTML-Code, JavaScript, Konsole, Netzwerk-Requests, etc), die auch in der Desktop-Entwicklung zum Zug kommen.

Anleitung: iOS Remote Debugging

Neben den aktuellen Version der Browser (Safari 6 Desktop bzw. iOS 6 auf dem iPhone) sind folgende Vorbereitungen zu treffen:

Device per USB mit dem Rechner verbinden.
Desktop-Safari: Falls nicht bereits geschehen, das Entwickler-Menü aktivieren („Einstellungen > Erweitert”).
Auf dem iPhone die „Webinformationen” aktivieren (unter „Einstellungen > Safari > Erweitert”). Hinweis: Der Private-Modus von Mobile Safari darf nicht aktiviert sein.

Menü auf dem iPhone, um das Remote Debugging zu aktivieren

Nun ist alles soweit vorbereitet, dass man auf dem iPhone die zu untersuchende Website öffnen kann. Anschließend findet man im Entwickler-Menü des Desktop-Safaris das angeschlossene iPhone samt allen weiteren vorhandenen Tabs. Falls man mehrere ähnliche Tabs offen haben sollte, erkannt man den richtigen daran, dass bei Mouseover des Menüeintrags die Website auf dem iPhone blau markiert wird.

Die einzelnen Tabs des Devices (links) und Hervorhebung bei Mouseover des gerade geöffneten Tabs (rechts)

Das war’s auch schon. Der Web Inspector öffnet sich und lässt sich wie gewohnt bedienen — mit dem Unterschied, dass das Frontend sich auf dem Device befindet. Selbst das Hervorheben von einzelnen HTML-Elemente beim Mouseover funktioniert.

Fazit: Ein deutliche Verbesserung im Vergleich zur äußerst einfach Web-Konsole in iOS5, da man nun erstmals vollen Zugriff auf die gerade geöffnete Website hat.

So geht’s: Neues Smart App Banner für iOS6 einbinden

Thu, 20 Sep 2012 21:06:24 +0200

Mit iOS6 führt Apple die Smart App Banner ein. Im Folgenden der notwendige Quellcode, wie man dieses App-Werbebanner in die eigene (mobile) Website einbindet.

Das Smart App Banner erscheint am oberen Rand des Browsers und bewirbt die native App

Die Funktionalität der Smart App Banner ist einfach erklärt: Ein kleiner Meta-Tag im HTML-Code sorgt dafür, dass ein kleines Werbebanner von der mobilen Website auf eine vorhandene native App hinweist. Klickt man darauf, landet man im App Store.

If the user doesn’t have your app on his device, tapping on the banner will take him to the app’s entry in the App Store. When he returns to your website, a progress bar appears in the banner, indicating how much longer the download will take to complete. When the app finishes downloading, the View button changes to an Open button, and tapping the banner will open the app while preserving the user’s context from your website.

Somit sind hoffentlich die Zeiten (zumindest auf iOS) vorbei, in denen man auf unterschiedlichste Weise (Fullscreen, Popup, Layer, etc.) auf die Apps hingewiesen wird — stattdessen wird ein Banner eingeführt, dass nicht zu sehr dominiert und im Laufe der Zeit sicher aufgrund des einheitliches Erscheinungsbildes auf verschiedenen Websites vom User erkannt und als glaubwürdig eingeschätzt wird.

Das Banner kann darüber hinaus nicht nur für eine App werben, sondern erkennt auch, ob diese bereits installiert ist. Wenn ja, ändert das Banner seinen Inhalt und zeigt einen „Öffnen”-Button.

If the app is already installed on a user’s device, the banner intelligently changes its action, and tapping the banner will simply open the app.

Verschieden Zustände des Smart App Banner: nicht installiert (links), App wird gerade heruntergeladen (Mitte), App installiert (rechts)

Generelle Voraussetzung für die Smart App Banner ist, dass der Nutzer ein iOS6-Gerät verwendet.

Smart App Banner einbinden

Um das Banner zu erstellen, muss lediglich im HTML-Head eine Zeile eingefügt werden:

<!DOCTYPE html>
<html>
 
<head>
<meta name="apple-itunes-app" content="app-id=284882215">
</head>
 
<body></body>

Es gibt drei Parameter, die aneinandergehängt werden können (app-id=..., app-argument=..):

app-id (Pflichtangabe): 9-stellige App-ID aus dem App-Store. Diese lässt sich über den Apple Link Maker herausfinden.
affiliate-data (optional): Affiliate-Code für iTunes-Verkäufe
app-argument (optional): Übergabe von Informationen an die App (z.B. Sessionparameter, ein Navigationspfad, etc.)

Der letzte Parameter app-argument bietet interessante Möglichkeiten und sorgt dafür, dass für dem Nutzer ein nahtloser Weg in die App geebnet wird (und er nicht zwangsläufig immer nur auf der Startseite der App landen muss). Die native App muss logischerweise angepasst werden und das übergebene Argument verarbeiten.

Fazit: Die Integration ist dank des 1-Zeilers sehr einfach. Setzt man den HTML-Schnippsel z.B. in Verbindungen mit einem Content-Management-System oder serverseitiger Programmierung dynamisch ein, lassen sich auch fortgeschrittene Konzepte umsetzen.

Link: Promoting Apps with Smart App Banners (Apple Developer Documentation)
Beispiel 1: Smart App Banner für Facebook-App (dürfte die meisten installiert haben)
Beispiel 2: Smart App Banner für Kobo App

Retina-Display: HTML-Canvas optimieren

Sat, 21 Jul 2012 15:49:08 +0200

Viele HTML-Elemente von mobilen Websites werden automatisch auf Geräten mit Retina-Display optimal dargestellt. Nicht jedoch das canvas-Element.

Das HTML-Element canvas (vom engl. Wort für Leinwand) ist eine Fläche, auf der mit JavaScript gezeichnet werden. So werden beispielweise Grafiken, Linien, Kreise, Bèzierkurven oder Farbverläufe unterstützt. Wie auch Website-Bilder (PNG, JPG) für das Retina-Display optimiert werden müssen, so ist dies auch für canvas-Elemente auf iOS-Geräten erforderlich.

Es folgt ein Überblick, wie man das Canvas-Element für iOS optimiert — und dabei auch bereits die neuen MacBooks mit Retina-Display berücksichtigt.

Optimale Darstellung, wenn Canvas-Pixel = Device-Pixel

Wie bereits im Artikel Unterschiede zwischen CSS-, Bild- und Device-Pixel erklärt, ist es wichtig, dass die Bild- und Device-Pixel übereinstimmen. Man muss also dafür sorgen, dass die Größe des Canvas (= Bild-Pixel) mit dem Display übereinstimmt. Konkret bedeutet dies, dass der Canvas z.B. statt 320x240px eine Auflösung von 640x480px besitzen muss, um scharf auszusehen.

Unterschiede zwischen nicht-optimiertem Canvas (oben) und Optimierung.

Unterschiede zwischen iOS und OS X

Ein wichtiger Unterschied zwischen iOS und Mac OS X liegt darin, dass OS X diese Pixelverdopplung des Canvas automatisch erledigt. Auf einem Desktop ist genügend Leistung vorhanden, so dass ohne jegliche Veränderung des Website-Codes automatisch alle Canvas-Elemente auf einem neuen Macbook mit Retina Display scharf sind.

Auf mobilen Endgeräten soll der Website-Entwickler jedoch aus Performance-Gesichtpunkten selbst entscheiden können, ob er die Verdopplung der Auflösung (= 4-fache Anzahl an Pixeln) anbieten möchte oder nicht.

Daraus ergibt sich folgende Aufgabe:

Herausfinden, ob es sich um ein Retina-Display handelt oder nicht.
Herausfinden, ob es der Canvas bereits vom Betriebssystem verdoppelt wird oder nicht. Wenn ja, dann darf nichts mehr verdoppelt werden (sonst erhielte man die 4-fache Canvas-Größe). Wenn nein, muss die Canvas-Größe verdoppelt werden.

Canvas

Retina-Display erkennen (`windows.devicePixelRatio`)

Als erstes stellt sich die Frage, woran erkennt mit die Devices mit hochauflösendem Bildschirm? Dies lässt sich in JavaScript über die Eigenschaft windows.devicePixelRatio herausfinden.

windows.devicePixelRatio == 1 oder undefined → normaler Screen
windows.devicePixelRatio == 2 → Retina-Display

Automatische Pixel-Verdopplung bei Canvas erkennen (`context.webkitBackingStorePixelRatio`)

Im Anschluss muss geprüft werden, ob die Canvas-Pixel vom Betriebssystem bereits verdoppelt werden. Hier gibt es eine neue Eigenschaft (var ctx = canvas.getContext('2d'); ctx.webkitBackingStorePixelRatio ).

webkitBackingStorePixelRatio == 1 oder undefined → keine automatische Verdopplung der Canvas-Pixel (also iOS-Gerät)
webkitBackingStorePixelRatio == 2 → automatische Verdopplung der Pixel (also zwangsläufig OS X mit Retina-Display)

devicePixelRatio und webkitBackingStorePixelRatio

Beispiele

Das erste Beispiel dient zur Betrachtung auf einem iPhone mit Retina-Display. Es zeigt lediglich die Unterschiede, zwischen einem nicht-optimierten und einem optimierten Canvas-Element (Screenshot siehe oben).

Wie man die beiden Erkennungen (Retina-Display und automatische Verdopplung) nun als generische Lösung implementieren kann, zeigt das zweite Beispiel. Auf diese Weise wird die Canvas-Verdopplung nur auf iOS-Geräten mit Retina-Display durchgeführt, auf anderen Geräten und Desktop-Rechner nicht.

if (canvas.getContext) {
 var ctx = canvas.getContext('2d');
 
 var factor = 1;
 
 // retina display?
 var isRetina = (window.devicePixelRatio > 1);
 
 // iOS? (-> no auto double)
 var isIOS = ((ctx.webkitBackingStorePixelRatio < 2) || (ctx.webkitBackingStorePixelRatio == undefined));
 
 if (isRetina && isIOS) {
  factor = 2;	
 }		
 
 canvas.setAttribute('width', 350*factor);
 canvas.setAttribute('height', 120*factor);
 ctx.scale(factor, factor);

Retina-Display: Unterschiede zwischen CSS-, Bild- und Device-Pixel

Wed, 11 Jul 2012 22:59:49 +0200

Dieser Beitrag erklärt die unterschiedlichen Pixelangaben, um eine optimale Darstellung auf den hochauflösenden Retina-Display zu erreichen.

Im Artikel Website-Bilder für das Retina-Display optimieren hatte ich bereits zwei Methoden vorgestellt, wie die Bildqualität für iPhone, iPad und mittlerweile auch Macbook verbessert werden kann. Ergänzend hierzu noch einmal einige grundlegende Erklärungen.

Grundsätzlich ist es wichtig, die folgenden Pixelangaben zu verstehen und unterscheiden zu können:

CSS-Pixel: Pixelgröße, in der das Bild dargestellt wird.
Bild-Pixel: Anzahl der Pixel, die ein Bild tatsächlich hat (z.B. 320×240).
Device- bzw. Display-Pixel: Tatsächliche Pixel des Device-Bildschirms, auf denen das Bild dargestellt wird

Am einfachsten lässt sich dies an Beispielen erklären.

Beispiel 1: Der Normalfall

Man bindet eine Bitmap-Grafik (z.B. PNG oder JPEG) ganz gewöhnlich im HTML-Code ein: <img src="bild.jpg" width="3" height="1" />.

Man gibt als Größe also 3×1 Pixel an, da das Bild genau diese Maße hat. Somit entsprechen die Angaben zu HTML-/CSS-Pixel genau den Bild-Pixeln.

Wird dieses Bild nun auf auf 3×1 Pixeln des Device-Displays abgebildet, ist die Darstellung optimal. Jede Information kann genau einem entsprechende Device-Pixel zugeordnet werden.

Normaler Screen: Häufiger Fall, dass CSS-Pixel = Bild-Pixel = Device-Pixel

Beispiel 2: Retina Display

Der Unterschied beim hochauflösenden Retina-Display liegt darin, dass die Auflösung doppelt so hoch ist. Dies bedeutet, dass die Device-Pixel in diesem Beispiel bei 6×2 Pixel liegen.

Hat das Bild weiterhin 3×1 Pixel, so wird die feinere Auflösung des Displays gar nicht genutzt. Es sind nicht genügend Bildinformationen vorhanden. Jeder Bildpixel wird lediglich auf 4 Devicepixel verteilt, das Bild erscheint auf dem Retina-Display unscharf.

Bild mit normaler Größe (3×1) auf Retina-Display (6×2) erscheint unscharf

Beispiel 3: Retina-Display

Im dritten Beispiel besteht nun der Unterschied, dass die Bilddatei ebenfalls eine höhere Auflösung hat: 6×2 Pixel. Jetzt sind Bild-Pixel und Device-Pixel identisch, so dass das Bild optimal und scharf dargestellt wird.

Man sieht außerdem, dass die CSS-Pixel also lediglich die dargestellte Fläche auf der Website definieren.

Das Bild hat genügend Auflösung, um die Auflösung des Retina-Displays zu nutzen

Somit ist zum einen festzuhalten, dass CSS-Pixel von Device-Pixeln abweichen können. Zum anderen ist wichtig, dass Bilder immer dann ideal dargestellt werden, wenn „Bild-Pixel = Device-Pixel” gilt.

Abschließend noch ein kurzer Hinweis zum Thema „DPI”: Durch die DPI-Angabe in Photoshop sollte man sich nicht irritieren lassen, da es sich lediglich um ein Meta-Datum handelt. Letztlich ist nur relevant, wie viele Pixel (=Bildinformationen) in einem Bild wirklich enthalten sind. Insofern kann man dies getrost bei den obigen Ausführungen gedanklich ausblenden.

iOS 6: Upload von Bildern und Videos

Sun, 08 Jul 2012 23:23:37 +0200

Mit iOS 6 wird endlich das Hochladen von Bildern und Videos unterstützt.

Bislang war es nicht möglich, auf iPhone oder iPad mit dem Browser Medieninhalte über ein Formular hochzuladen (<input type="file" ....). Dies wird sich mit iOS 6 ändern: Der Button zur Dateiauswahl ist nicht mehr wie bisher ausgegraut, sondern kann geklickt werden. Er dient allerdings ausschließlich für den Upload von Bildern und Videos.

Der Dialog beginnt mit „Take photo or video” oder „Choose Existing” — man kann also direkt ein Bild oder Video erstellen oder aus der Camera Roll aus bereits vorhandenen Bildern und Videos auswählen.

Diese kleine Verbesserung dürfte sich als äußerst nützlich erwiesen.

Der nächste Schritt — der unmittelbare Zugriff auf die Kamera und deren Bilddaten — lässt leider noch auf sich warten, da dies weiterhin nur nativen Apps vorbehalten ist.

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, [...]

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 [...]

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 [...]