Inspiriert durch “Flipboard and the mobile web” - Christian Heilmann

Unlängst wurde bei Medienmonster die Landing-Page zum Thema Mobile rocks - warum Webseiten für mobile Endgeräte optimiert werden sollten fertiggestellt. Im Laufe der Entwicklung kam dabei mehrfach die Frage nach der Performance von Animationen auf, in Fall der Landing Page handelt es sich um SVG, die mit Hilfe von SMIL Animationen in Bewegtbild verwandelt wurden.

Falls die obige Spezifikation durch das W3C zu technisch ist: Im Grunde lassen sich mit Hilfe von SMIL-Animationen einzelne Bestandteile von Vektorgrafiken bewegen / skalieren / rotieren. Grundsätzlich funktioniert die Animation von SVG zwar auch per CSS, jedoch können dann nicht alle sogenannten presentation attributes beeinflusst werden, so dass komplexe Animationen nicht mit CSS, sondern nur durch Verwendung deklarativer Animationen innerhalb des SVG-Elements möglich sind.

Jedoch zeigte sich, dass die Darstellung dieser Animationen nicht auf allen Geräten unproblematisch ist: Insbesondere einige Mobilgeräte, an die sich die Landing-Page in erster Linie richtet, ließen keine flüssige Darstellung der SVG-Animationen zu. So erreicht etwa ein iPad der dritten Generation keine flüssige Darstellung, also die 60 Bilder pro Sekunde (frames per second, fps), von denen im Titel die Rede ist.

Warum überhaupt 60 fps?

Diese Frage ist insbesondere dann verständlich, wenn man sich einmal vor Augen führt, dass das Kino - als erstes Massenmedium für Bewegtbild überhaupt - schon immer Filme mit 24 Bildern pro Sekunde zeigt; Auch wenn diese feste Größe durch High Frame Rate (HFR) Produktionen, wie z.B. der Hobbit, in 48 fps inzwischen verändert wurde, so hatte sie doch im Prinzip seit der Erfindung des Films Bestand.

Auch andere Medien nutzten über lange Zeiträume hinweg Bildraten von 25 oder 30 pro Sekunde, selbst im Masterstudium am Fachbereich Medien stellte sich bei der Produktion von Fulldome-Videos im Mediendom immer wieder die Frage, ob eine Produktion in 60 fps wirklich notwendig sei - immerhin müssen dafür doppelt soviele Bilder berechnet werden wie für eine Wiedergabe mit 30 Bildern pro Sekunde.

Demgegenüber schaue man sich einmal die Vergleiche auf der Website 30fps vs 60fps an. Der Betreiber empfiehlt, sich den Videoloop mit 30 Bildern / Sekunde (auf der linken Seite) jeweils ein paar Mal hintereinander anzusehen, damit er sich einprägt, und ihn dann mit dem rechten Videoloop (60 Bilder / Sekunde) zu vergleichen. Dabei wird relativ schnell deutlich, dass Videos und Animationen mit 60 fps als deutlich flüssiger wahrgenommen werden.

Und im Web?

In der Zeit des mobile Web müssen angesichts steigender Nutzungszahlen Webseiten zunehmend mit nativen Apps für die jeweiligen Endgeräte konkurrieren. Um die User Experience einer App auf einer Website überhaupt zu erreichen, spielen eben auch Animationen, die den Nutzer führen oder aktivieren eine maßgebliche Rolle. Kurzum: Moderne User Interfaces erfordern Animationen. Und mittels Progressive Enhancement werden bei Webseiten dann eben auch die Nutzer größerer Bildschirme - etwa via Notebook oder klassischem Desktop-PC - einbezogen.

Und so ist zwar vermeintlich der Ruf nach einer größeren Animations API durch die Kollegen vom Smashing Magazine erhört worden, jedoch ist die Verwendung von Animationen scheinbar noch nicht konsistent möglich. Um hier gar nicht erst von WebGL auf mobilen Geräten mit schmaler Grafik-Hardware zu sprechen…

Abhilfe schafft, aus Erfahrung, zunächst einmal die Beachtung der Parameter, welche animiert werden. Auf CSS Triggers lässt sich recht gut erkennen, wodurch die unterschiedlichen Berechnungsvorgänge zur Darstellung der Webseite im Browser angestoßen werden. Es gilt: Weniger ist mehr. Denn zunächst sollte natürlich immer der Content, also die Information, im Vordergrund stehen.

Dann gibt es da natürlich noch diejenigen, über die Chris Heilmann schreibt: Flipboard etwa, die versucht haben, das native User Interface ihrer App ins Web zu bringen. Leider aber ohne Rücksicht auf Verluste.
Denn einem Medium wie dem Web, dessen Basis seine universelle und ubiquitäre Nutzung bildet, steht es nicht gut zu Gesicht, wenn eine Website lediglich eine Nutzung unter bestimmten, eingeschränkten Bedingungen erlaubt - dazu bar jeder Semantik.

Lasst uns, liebe Webworker-Kollegen, lieber weiter am universellen, ubiquitären und (möglichst) barrierefreien Web arbeiten. In diesem Sinne: Frohes Schaffen!