senäh

17senäh und so…

HTML5 Dreizack

HTML/CSS/JS
24. Mrz 2013
Kommentare: 2

Ein Plädoyer für native Bedienelemente

Kategorien: HTML/CSS/JS | 24. Mrz 2013 | Kommentare: 2

Vor etwas längerer Zeit sprach ich mit einem Mitstudenten über ein Problem, auf das er bei der Umsetzung einer Webseite gestoßen war. Er hatte einen Container, dessen Inhalt scrollbar sein sollte. Das Problem dabei war, dass die nativen Scrollbalken vergleichsweise hässlich sind. Dementsprechend hat er auf die native Funktionalität verzichtet und sie stattdessen selbst mit JavaScript nachgebaut.

Invertiertes und natürliches Scrollen

An sich stellt das Vorhaben keine allzu große Herausforderung dar. Über JavaScript werden Scrollevents abgefangen, ein Element am rechten Rand spiegelt die aktuelle Scrollposition und ist vom Benutzer direkt bewegbar. Et voilà: ein Scrollbalken in Eigenbau.

Dadurch ergibt sich aber ein weiteres Problem: die Scrollrichtigung ist auf manchen Geräten invertiert. Während wir an klassischen Desktop-Rechnern gewohnt sind, beim Scrollen den Scrollbalken zu steuern, bewegen wir den Inhalt auf Mobilgeräten direkter. Am Desktop bewegen wir das Mausrad von oben nach unten, um nach unten zu scrollen. Am Smartphone oder Tablet aber bewegen wir den Finger nach oben, um weiter nach unten zu gelangen.

Nun könnte man “einfach” für Mobilgeräte die Scrollrichtung umdrehen, um dieses Verhalten zu korrigieren. Aber da gibt es ja noch die Apple-Rechner, diese Hipster-Geräte, die immer eine Extrawurst benötigen. Mac-User haben seit OS X Lion die Wahl dieses natürliche Scrollen – und ja, wenn ihr ehrlich seid, ist es natürlicher – auch auf dem Desktop zu aktivieren. Die Unterteilung in “Desktop” und “Mobil” macht dann keinen Sinn mehr.

Stellt sich die Frage: was tun? Um den Spannungsbogen aber noch nicht zu früh abflachen zu lassen, erst noch ein anderes Beispiel dieser Art:

Dropdowns über JavaScript – wie einfach sich Zugänglichkeit beschränken lässt

Während das Beispiel der nachgebauten Scrollbalken sich nur mit der Frage nach der Richtung auseinandersetzen muss, sind die Stolpersteine wesentlich zahlreicher, wenn man versucht Dropdown-Listen selbst zu stylen. Die Browser geben dem Entwickler dafür leider herzlich wenig Möglichkeiten an die Hand. Das Aussehen dieser Elemente soll nur bedingt verändert werden.

Doch JavaScript to the rescue. Wir können das <select>-Dropdown in eine beliebig zu gestaltende <ul>-Liste umwandeln, indem wir für jede <option> ein <li>-Element anlegen. Sobald ein <li> geklickt wird, muss das korrelierende <option>-Element “behind the scenes” aktiviert werden. Schön und gut, geht einfach, wird auch oft gemacht.

Aber: Benutzer kennen ihre heißgeliebten Formularelemente. Manche von ihnen sind es gewohnt mit der Tab-Taste durch die einzelnen Element zu navigieren, um sich Mausklickerei zu ersparen. Außerdem lässt sich in nativen Dropdowns mit den Pfeiltasten navigieren, man kann sogar die ersten Buchstaben eines Eintrags eintippen, um ihn zu aktivieren. Über die Space- bzw. Enter-Taste lässt sich der aktivierte Eintrag dann auswählen.

Was ist mit diesen Interaktionsmöglichkeiten? Hättet ihr daran gedacht, diese umzusetzen? Viele vorgefertigte JavaScript-Plugins tun das erfahrungsgemäß nicht. Als Benutzer fühlt man sich durch solche selbstgebastelten Eingabefelder an eine Flash-Applikation erinnert, die ähnlich stark mit fehlender Zugänglichkeit brillieren würde. Und das will niemand. Sonst wird Steve Jobs wiederauferstehen und mit einem HTML5-Teufelsdreizack durch’s Land ziehen um euch Usability-Bewusstsein in eure kleinen Entwickler-Hintern einzupieksen.

Von der Kunst die Dinge so zu lassen wie sie sind

Es gibt Gründe, warum bestimmte Elemente in ihrer Gestaltung über CSS eingeschränkt sind. Sobald etwas stylebar ist, wird es gestylet. Ich erinnere an dieser Stelle gern an pinke Scrollbalken, die ihre Blütezeit um die Jahrtausendwende hatten.

Ein Betriebssystem gibt dem Benutzer Orientierung durch die Verwendung bekannter Elemente, vor allem bei Formularen. Das Formularelement wird als solches erkannt und – so wie immer – als Eingabemöglichkeit verwendet. Der Benutzer erkennt schnell, was von ihm verlangt wird, und kann so ohne das Interface studieren zu müssen mit der Software interagieren. Diesen Vorgang zu optimieren bedeutet Software benutzerfreundlicher zu machen.

Damit diese Benutzerfreundlichkeit auch im Browser erhalten bleibt, müssen Formularfelder nativ bleiben. Ausrufezeichen.

Gestaltung ist nicht alles, nicht im Web

Ok, ok. Mehr Flexibilität für den Webdesigner wäre cool. Kreativer Designer ist kreativ und so.

Allerdings geht es beim Design immer noch primär um die Kommunikation mit dem Benutzer, um die Vermittlung von Informationen. Auch wenn der technikaffine Volksmund beim Wort Designer eher an den Macbook-Besitzer aus dem Starbucks denkt, der sich den ganzen Tag nur mit Farbschemata, runden Ecken und möglichst aufdringlichen Spiegelungen beschäftigt.

Die Form sollte immer der function followen. Es geht um den Benutzer und seine Erfahrung. Ein “guck mal hier, Dropdown, kennste ne?” funktioniert im schlechtesten Fall genauso gut, wie eine selbst gestylte Liste, die das native Verhalten mimt. Nativ ist also immer eine gleichberechtigte, wenn nicht sogar bessere Wahl als selbst gestylte Eingabefelder.

Nicht-native Bedienelemente müssen vom Benutzer erst als solche erkannt werden, was Zeit kosten kann. Zeit, die der Benutzer vielleicht nicht hat, weswegen er eure mit so viel Herz aufgebaute Webseite umgehend verlässt. Die Tragödie nimmt ihren Lauf und ihr verliert einen Besucher. Unnötigerweise. Und das nur, weil sich die Farbe des nativen Scrollbalkens nicht so gut in euer Design eingepasst hat.

Und mal ehrlich: bei Text-Inputs können wir uns gestalterisch mittlerweile ganz gut austoben, oder? Das ist auch ok, in der Regel sind diese Felder auch nach der Gestaltung noch deutlich als solche erkennbar. Bei allen anderen Elementen sollte man aber meiner Meinung nach vorsichtig sein.

Fazit

Native Elemente machen Sinn und ihr solltet einen triftigen Grund haben diese nicht zu verwenden. Denkt dran: wir sind hier nicht im Print-, sondern im Webdesign. Es geht um die Vermittlung von Informationen an und die Interaktion mit dem Benutzer. Der Benutzer ist mit den Elementen vertraut und das ist wichtig. Der Benutzer ist das primäre Ziel, nicht die visuelle Erscheinung!

Und was ich noch sagen wollte: der Benutzer!

Autor: Enno

Ich bin Enno. PHP ist mein Ding, aber auch alles Neue rund um die Themen HTML5, CSS3 & Co finde ich interessant. Ich mag es Leuten zu helfen und mein Wissen weiterzugeben. Sollte dir mein Beitrag gefallen haben, lass doch nen Kommentar da oder benutze einen der Social Buttons, um deinen Dank auszudrücken ;)