Responsive Design ist mehr als Pixelschubsen

[Update: Die im Artikel angesprochenen Device-APIs werden von w3c nicht mehr verfolgt: https://dev.w3.org/2009/dap/system-info/#system-properties]
Responsive Layout wird nun schon seit einiger Zeit durchs Dorf getrieben. Und obwohl sich langsam die Meinung durchsetzt das Responsive Design für eigentlich Default sein sollte, ist das noch lange nicht Realität. Die Anzahl der Design–Prozess, die beim kleinsten Screen starten, um echte Responsiveness zu implementieren, ist noch sehr gering (und auch wir haben aus Zeitgründen beim Launch unserer eigenen Seiten darauf verzichtet).

Sketch zur Nutzung von visitstockholm.com in unterschiedlichen Nutzungskontexten

Um Responsiveness anhand des Nutzungskontextes geht es hier nicht, ist aber auch ein interessanter Ansatz. — Bild von James Royal-Lawson, flickr

Doch auch, wenn sich Responsive Layout immer weiter durchsetzt, so wird responsive Layout doch in den meisten Fällen auf die Adaption des Layouts auf die zur Verfügung stehenden Breite reduziert. Im besten Fall wird noch daran gedacht die Bildergrößen bei kleineren Auflösungen/Screengrößen zu reduzieren.
Doch heute möchte ich angeregt durch zwei Artikel aus den letzten Wochen ein wenig weiterdenken. Es kommt schließlich nicht nur auf die Größe an — sondern noch auf weitere Faktoren und mit ein wenig Glück können wir die sogar ermitteln.

Maps und Batterieladestand als Inspiration

Ecliptic schreibt über die Adaption der Seite an den Batterieladestand (Link auf archive.org, da ecliptik.co.uk disconnected wurde). So wird angeregt bei niedrigem Batteriestand den Nutzer zu Fragen, ob Features reduziert werden sollen, um Batterieverbrauch und CPU zu sparen.
Brad Frost hingegen regt an Karten per default static und nicht interactive einzubinden. Vorteil wäre: Performance (sowohl Ladezeit, als auch Speicherverbrauch) und natürlich, dass man den User direkt an eine native Applikation weiterleiten kann, wenn er wirklich Interaktivität braucht. Schließlich sind die nativen Apps aller Wahrscheinlichkeit nach deutlich besser, was kontextbezogene Interaktion und Steuerung angeht (schon mal versucht Google Maps über den Browser auf dem iPhone zu bedienen? Gruselig.).

Verfügbare Device–APIs und erste Nutzungsideen

Grobe Übersicht über Device–APIs von http://dev.w3.org/2009/dap/system-info/#system-properties

Grobe Übersicht über Device–APIs von https://dev.w3.org/2009/dap/system-info/#system-properties

Was also gibt es so an Device APIs und was könnten wir damit machen? Als Basis gehen wir http://www.w3.org/2009/dap/ durch, für den Hinterkopf gilt natürlich, dass man im Einzelfall checken muss, wie weit die Implementierung aktuell in der eigenen Nutzerschaft verbreitet ist.

  • Battery Status — Features Downsizen, um Batterie zu sparen
  • HTML Media Capture — Bei Verfügbarkeit von Mikrofon oder Kamera Formulare für entsprechende Möglichkeiten optimieren, zum Beispiel Profil–Foto jetzt aufnehmen (mehr Informationen über Media–Captures im W3–Wiki)
  • Network Information API — Dateigrößen anhand der Netzwerkgeschwindigkeit anpassen und nicht anhand des Devices. Zum Beispiel kann ein Desktop–Rechner via Tethering bei Edge–Verbindung geringere Größen verkraften, als ein Telefon im W–Lan. Weniger Content laden und mehr On–Request einbinden, wenn die Geschwindigkeit gering ist, Anpassungen in der Caching– und Prefetch–Policy. Vor diesem Hintergrund natürlich direct die Erkenntnisse aus der Network Service Discovery API einfließen lassen.
  • Ambient Light Events — Anpassung des Designs auf Helligkeit. Kontraste hochfahren, bei schwierigem Umgebungslicht, hellere Farben, bei dunklerer Umgebung. Fast noch spannender wäre natürlich die Helligkeitseinstellung des Monitors an sich…
  • Vibration API — Bestimmte Aktionen sind einfacher auszuführen, wenn das Device geschüttelt wird. Beispielsweise wird Refreshing häufig durch Apps ausgelöst. Paging–Clicks könnten ebenfalls gut funktionieren. Dazu könnten bestimmte Aktionen bei Vibration ausgesetzt werden, weil der Nutzungskontext sich geändert hat. Bei starker Vibration könnte es unter Umständen sinnvoll sein Formulareingaben zu pausieren, oder Formulareingaben erst zu übermitteln, wenn keine Vibration mehr existiert. Ich habe beispielsweise schon öfter versehentlich Formulare abgeschickt, weil ich beim Loslaufen das Telefon noch nicht in den Still-Modus geschickt habe.

Und natürlich kann man sich jetzt schon Gedanken machen, was man machen würde, wenn eine der erst im Entwurfs–Modus befindlichen APIs live gehen. Mit der Ambient Temperature Events–API könnte man X Grad an Sonnencreme erinnern oder Werbung für Grillgut statt Regenschirm machen (klar, dass könnte man auch jahreszeitenbasiert machen, wäre aber nicht ganz so schön), vor allem in Verbindung mit der Art des Devices kann ich mir schöne Anwendungsfälle vorstellen.

Whatever. Derzeit ist das wegen der fehlenden Verbreitung der entsprechenden Sensoren noch auf Edge–Cases und Seiten mit speziellen Nutzergruppen beschränkt, macht aber deutlich, dass wir Responsiveness nicht nur daran festmachen können, ob eine Seite immer noch gut aussieht, wenn wir den Browser verkleinern oder die Seite mit einem anderen Browser, von einem anderen Endgerät oder ähnliches aufrufen.

Und natürlich vergessen wir an der Stelle auch, dass die Basis echter Responsiveness immer ein schlankes, vor allem valides und accessibles HTML ist. Denn Responsiveness ist eigentlich nur die Erkenntnis, dass man Seiten von Endgerät unabhängig machen muss, weil es zu viele Endgeräte gibt, die auf das Internet zugreifen.

BTW: Wer von Euch hat schon einmal darüber nachgedacht, was für folgen die Verbreitung von Google Glass auf das Bauen von Webseiten haben wird?

Die eigentliche Schlussfrage: Welche der Ideen haltet Ihr für realistisch? Welche API bräuchte man noch unbedingt und welche Anwendungsfälle fallen Euch noch ein?


Kommentare

Harald Zimmer am 25. Juli 2013 um 07:37:29

Moin Johan,

cooler Artikel! Vielen Dank … Nur was den Teil mit der Temperatur betrifft habe ich dich durchschaut … wenn man weiß wie warm iphone , Android und co im Betrieb werden … ist doch dein eigentliches Ziel das ganze Jahr über Grillwerbung zu bekommen ;)

LG
Harald

Jan am 25. Juli 2013 um 08:31:03

Hey Johan,

sehr kreativ, mir gefällt die Denkweise sehr! Das nenne ich wirklich mal über den Tellerrand geschaut.

BG
Jan

Robert am 21. August 2014 um 11:04:02

Ist die Uhrzeit nicht auch ein interessanter Aspekt? Mein Gmail ändert ab 20:00 Uhr glaube ich, das Hintergrundbild in ein dunkleres. Viele Apps auf meinem Smartphone haben auch einen Nachtmodus, welchen ich aber erst aktivieren muss.

Der ecliptik.co.uk Link ist leider tot :(

Johan Hülsen am 21. August 2014 um 11:16:40

Hallo Robert,

danke für den Hinweis, der Link ist aktualisiert. 301–Weiterleitungen sind auch eine Frage von Responsiveness. ;)

Uhrzeit ist prinzipiell interessant, muss aber theoretisch mit mehreren Faktoren abgeglichen werden, etwa Geolocation (Wann ist da Sonnenuntergang?) und eigentlich auch umgebenden WLANs/Drinnen vs. draußen. Drinnen ist vermutlich künstliche Beleuchtung und damit weniger Notwendigkeit.

Danke,
Johan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.