Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Ambient Light Responsive Webdesign

Gerätesensoren per Javascript und CSS nutzen

Ambient Light Responsive Webdesign

Responsive Websites können nicht nur auf die Änderung des Browserfensters reagieren – auch die Umgebungshelligkeit kann die Gestaltung beeinflussen. Mit Javascript lassen sich entsprechende Sensoren abfragen und für das Design nutzen.

Traditionell denkt man bei responsivem Webdesign an Layouts, die auf die Änderung der Browserfenstergröße – bzw. des Viewports – reagieren (wenn man bei einer so jungen Disziplin von Traditionen sprechen kann). In der Regel werden dann das Layout der Seite oder einzelne CSS-Eigenschaften verändert, z.B. die Schriftgröße, um die Benutzung für Besucher unter den für sie geltenden Bedingungen (besonders kleine oder große Bildschirme) zu verbessern. Tatsächlich gibt es aber ein ganze Reihe von Umgebungsbedingungen, auf die eine Website reagieren könnte.

Schön wäre es doch, wenn ein elegant Ton in Ton gestaltetes Design auch bei grellem Sonnenlicht gut lesbar wäre – indem sich der Kontrast den Lichtverhältnissen anpasst. Tatsächlich ist das möglich. Mit der W3C Candidate Recommendation Ambient Light Events hat die Mozilla Foundation eine Spezifikation eingereicht, mit der sich das über einen Lichtsensor gemessene Umgebungslicht auslesen und verwerten lässt (wenn auch momentan die Browserunterstützung noch sehr ausbaufähig ist). Auch der aktuelle Draft der Mediaqueries Level 4 sieht eine Reaktion auf Helligkeitsunterschiede vor – das Media Feature luminosity. Während die Mediaqueries noch nicht einmal testbar sind, lässt der Mozilla-Vorschlag mit Mobile Firefox > 15 oder auf FirefoxOS bereits nutzen (z.B. einem Nexus 7 der 1. Generation).

Die Abfrage an sich ist recht einfach. Mit einem Event Listener wird der Sensor direkt abgefragt:

  1. window.addEventListener("devicelight", function (light) {
  2.     var ambientlight = light.value;
  3.    …
  4. });

Mit dem gewonnenen Helligkeitswert in Lux könnt ihr nun Abfragen für die Anpassung des Design an die Umgebungshelligkeit schreiben. Der Wert lässt sich natürlich auch direkt anzeigen. Die folgende Funktion setzt je nach Helligkeit unterschiedliche Klassen und gibt den Lichtwert aus:

  1.                
  2. <script src="http://code.jquery.com/jquery-1.10.1.min.js"></script>
  3. <script>
  4.    var currentClass = 'medium';
  5.    $('body').addClass(currentClass);
  6.    function readLight(light) {
  7.       var header = "<h1>Ambient Light Responsive Webdesign &trade;</h1>";
  8.       $('body').removeClass(currentClass);
  9.       if (light.value > 1800) {
  10.          currentClass = 'sunny';
  11.          header = "<h1>Ein schöner Tag!</h1>";
  12.          }
  13.       else if (light.value < 500) {
  14.          currentClass = 'dark';
  15.          }
  16.       else {
  17.          currentClass = 'medium';
  18.          header = "<h1>Ein dunkles Grau vor hellgrauem Hintergrund ist elegant, aber schlecht lesbar.</h1>";
  19.          }
  20.       $('body').addClass(currentClass);
  21.  
  22.       var d = document.getElementById("message");
  23.       d.innerHTML = header + "<p>Der aktuelle Lichtwert beträgt <em>" + light.value + " Lux</em>.</p>";
  24.       }
  25.    window.addEventListener("devicelight", readLight, true);
  26. </script>

Das Skript wird im Kopf der Website platziert und stellt die vergebenen Klassen zum Styling zur Verfügung. Außerdem verändert es den Inhalt des Elements mit der id "message". Mit einer CSS-Transition könnt ihr den Übergang noch etwas verfeinern und für den Alltagseinsatz wäre es sinnvoll, die Schwellenwerte so zu gestalten, dass die Darstellung nicht andauernd umspringt (Hysterese).

Um den Effekt zu sehen, müsst ihr die Demoseite mit Mobile Firefox auf einem Gerät mit Helligkeitssensor aufrufen.

Es gibt noch mehr!

Auf die Umgebungshelligkeit zu reagieren, ist nur eine Möglichkeit, die wachsende Anzahl von Sensoren moderner Mobilgeräte zu nutzen.

Wie wäre es zum Beispiel, wenn die Website eines Restaurants beim Aufruf durch ein mobiles Gerät »in der Nähe« mit der prominenten Anzeige der Tageskarte und der Adresse reagieren würde? Die meisten modernen Smartphones haben außerdem einen Kompass und einen Neigungssensor an Bord, so dass sich die Position des Geräts im Raum exakt bestimmen lässt. Eine Kleinigkeit, nun auch noch die Entfernung und Richtung zum Ziel anzuzeigen.

Bei der Nutzung von Sensoren stellt sich natürlich die Frage nach Datenschutz und Überwachung. Da die Sensorendaten vom Gerät bereit gestellt werden und per Javascript verarbeitet werden, bleiben alle Informationen zunächst auch dort (natürlich lassen sie sich dann auch weitergeben). Manch Nutzer wird sich aber dennoch durch Funktionen irritiert fühlen, die zeigen, dass »die Website« seine Position kennt. Mit einem Datenschutzhinweis, der die Funktion erläutert, nehmt ihr diese Bedenken ernst. Im Zweifel könnt ihr Lokalisierungsfunktionen auch so umsetzen, dass sie erst eingeschaltet werden müssen.

Progressive Enhancement statt Bevormundung

Mobilsite ohne Informationen außer der Anschrift
So nicht – eine mobile Website ist mehr
als ein Adressaufkleber!

Bei aller Freude über zusätzliche Information solltet ihr jedoch nicht vergessen, dass Sensordaten immer nur Informationen aus zweiter Hand sind – einen Sensor für die Gedanken des Nutzers gibt es glücklicherweise (noch) nicht. Bietet daher aufgrund von sensorgestützten Vermutungen zusätzliche Verbesserungen an – trefft keine ausschließenden Entscheidungen für die Nutzer. Ein abschreckendes Beispiel sind »mobile Websites«, die nur die Anschrift eines Unternehmens anbieten, in der irrigen Annahme, dass mobile Nutzer ihr Smartphone oder Tablet immer nur unterwegs nutzen.

Kommentare

Christian Heilmann
am 09.12.2013 - 10:25

Und wenn man das dann mit WebAudio verbindet, kann man ein Theremin bauen: http://jsfiddle.net/codepo8/jQ59c/1/

Permanenter Link
Jens Grochtdreis

Jens Grochtdreis (Webkraut)
am 09.12.2013 - 17:28

Was eine coole Idee! Und wie nutzlos :-)

Permanenter Link

Nomade
am 09.12.2013 - 14:01

Man sollte allerdings nicht vergessen, dass sich viele Geräte automatisch an die Helligkeit anpassen. Wenn die Website dann auch sich dynamisch anpasst, kann sich der Effekt in sein Gegenteil umkehren. Andere Idee, wie wäre es mit passener Werbung? Wenn das Handy kalt ist, gibt es Werbung für Handschuhe, wenn es heiß ist für Eiscrmé.

Permanenter Link

Andrey
am 10.12.2013 - 13:44

Warum im Codebeispiel jQuery Verwendung findet erschließt sich mir nicht. Das Wechseln der Klasse geht nativ doch so simpel.

Permanenter Link

lab
am 10.12.2013 - 18:23

Um es sauber zu machen, braucht man schon ein paar Zeilen. Habe ich hier aus Gründen der Einfachheit darauf verzichtet. Aber es geht natürlich auch ohne jQuery. Wenn Du Lust hast, kannst Du das ja als jsFiddle ergänzen...

Permanenter Link

nikosch
am 10.12.2013 - 21:46

Danke für den letzten Absatz. So wie in der Demo würde ich mit Sicherheit nie einen Anwender bevormunden. Für mehr als um ein Auswahlmenü mit Kontrasten einzublenden (oder eine dezente Infoleiste), sollte man IMHO Sensordaten nicht nutzen. (Und genau genommen könnte man das auch ohne Sensor tun). Man stelle sich nur den Nutzer vor, der krampfhaft versucht, auch im schattigen Bereich die kontrastreiche Variante beizubehalten. Ich meine, so etwas ist absehbar, inklusive Nutzerfrust.

Permanenter Link
Kai Laborenz

Kai Laborenz (Autor)
am 11.12.2013 - 17:24

Hier geht es ja darum, eine technische Möglichkeit vorzustellen und als Demo möglichst deutlich zu sein. Ein sinnvolles Maß muss natürlich der Designer im Rahmen seines konkreten Projekts finden. Glücklicherweise hat im Web ja das Userstylesheet das letzte Wort (einigermaßen fachkundige Umsetzung vorausgesetzt). Wer als User also seine Vorgaben von Farben und Kontrasten auf jeden Fall durchsetzen will (oder muss), kann das immer tun. Davon abgesehen ist jedes Design eine "Bevormundung" des Nutzers - seine Vorstellungen von Aussehen und Funktion zu entwickeln, ist Aufgabe des Designers. Wenn er dabei spezifischer auf die Umgebungsbedingungen reagieren kann, ist das von Vorteil.
Permanenter Link

Gunnar Bittersmann
am 13.01.2014 - 16:07

Statt in einer Klasse ist die Information sicher besser in einem data-Attribut aufgehoben; das spart einem das Löschen.
Und statt beim body besser ganz oben beim html-Element.
Siehe meinen Kommentar

Permanenter Link
Jens Grochtdreis

Jens Grochtdreis (Webkraut)
am 13.01.2014 - 16:32

Kann man sicher auch auf ein data-Attribut packen. Das ist eher Geschmackssache als eine Frage von richtig oder falsch. Ich kenne auch Artikel, die sich vehement gegen die Nutzung der Data-Attribute im Zusammenhang mit CSS aussprechen. So hat jeder seinen eigenen Fetisch.

Permanenter Link

Gunnar Bittersmann
am 13.01.2014 - 16:39

Es gibt auch Artikel, die sich gegen die Nutzung von IDs im Zusammenhang mit CSS aussprechen. Muss man nichts drauf geben.

Permanenter Link
Jens Grochtdreis

Jens Grochtdreis (Webkraut)
am 13.01.2014 - 16:40

Auf diese Artikel gebe ich auch wirklich nichts. :-)

Permanenter Link

Die Kommentare sind geschlossen.