3.2 Browser-Inkonsistenzen

3.2 Browser-Inkonsistenzen

Die Komponenten Select & Datalist variieren sowohl in der Ansicht als auch in der Interaktion. Die Unterschiede sind system-, browser- und komponentenabhängig. Nachfolgend sind die Inkonsistenzen genauer erläutert.

3.2.1 UI-Unterschiede

Das Select ist in der geschlossenen Form auf der rechten Seite mit mindestens einem Pfeil nach unten ausgestattet. Safari (OSX und iOS) verwendet als Icon einen Doppelpfeil (Abbildung 3.1). Firefox zeigt das Feld in Grau (Abbildung 3.2). Chrome und Edge verwenden hingegen einen weissen Hintergrund (Abbildung 3.3). Safari auf iOS stellt die Komponente ohne Rahmen dar und deswegen ist der Hintergrund in einem hellen Grau gehalten. Da der Fokus dieser Arbeit auf der Desktop-Anwendung liegt, finden sich die Bilder der Mobile-Browser im Anhang C.

Die geöffnete Liste ist bei Firefox als Einziges relativ konsistent. Sie erscheint in einem grauen Container. Die anderen Browser sind einstellungsabhängig. Sie zeigen den Container weiss oder dunkelgrau (Abbildungen 3.4 und 3.5) an. Je nach Anzahl der enthaltenen Elemente erscheint die Liste darunter (darüber) oder überdeckt die Detail-Ansicht. Am wenigsten lässt sich das Element in Safari stylen.

Da nicht jeder Browser ein Icon anzeigt, ist die Datalist weniger konsistent. Safari und Firefox stellen keinen visuellen Hinweis (Abbildungen 3.6 und 3.7) auf die Liste dar. Safari auf iOS zeigt hingegen in jedem Fall – bezogen auf den textuellen Typ – einen nach unten zeigenden Pfeil an. Andere Browser blenden auf der rechten Seite beim Hovern oder beim Besitzen des Fokus das Icon (Dreieck nach unten zeigend) ein.

Bei Firefox unterscheidet sich das Öffnen der Liste ebenfalls. Wenn das Feld den Fokus noch nicht besitzt, benötigt es zwei Klicks. Die anderen Browser lassen die Liste bereits beim ersten Klick erscheinen. Die Liste selbst verhält sich je nach Browser und Inhalt verschieden. Sie erscheint seitlich oder darunter (darüber). Die Übernahme des Dark- bzw. Light-Modes als Container-Farbe hängt vom Browser und dem Anwendungskontext ab. Die Liste überdeckt das Eingabefeld nie. Die Abbildungen 3.8 und 3.9 zeigen Beispiele der geöffneten Datalist.

Ein Blick auf die mobilen Browser wie iOS-Safari, Android-Firefox und -DuckDuckGo zeigen weitere UI-Unterschiede. Für eine bessere Bedienbarkeit zeigen sich die geöffneten Selects auf Android – gegenüber den Desktop-Versionen – in einem anderen Design. Die Liste öffnet sich als Dialog-Popup und füllt je nach Anzahl der Werte fast das komplette Display aus. Das selektierte Element besitzt einen ausgefüllten Radio-Button auf der rechten Seite. Auf iOS-Browsern erhält die ausgewählte Option auf der linken Seite ein Check-Icon (✓). Der Listen-Container erscheint ähnlich zum OSX-Browser als Dropdown-Liste. Nach einer Auswahl schliessen die mobilen Selects automatisch.

Die Datalist zeigt ihren Inhalt nur bei der Interaktion mit Pfeil auf der rechten Seite. Abgesehen von der Grösse der einzelnen Einträge für die Bedienbarkeit unterscheiden sich diese kaum von den Desktop-Versionen. Die Selektionen erscheinen gegenüber den anderen Optionen in keinem speziellen Design.

Weitere Inkonsistenzen sind in den Bildern im Anhang C zu sehen. Die nachfolgenden Abschnitte 3.2.2 bis 3.2.6 beschreiben die möglichen Interaktionen. Die Tabellen stellen Datalist, Single- und Multiselect einander gegenüber. Im Anschluss an die Gegenüberstellungen der Browser weist das Kapitel Fazit auf die Inkonsistenzen hin.

3.2.2 Edge Browser

Die folgende Tabelle 3.2 zeigt den Vergleich der typischen Interaktionen in Edge auf Windows. Der Vergleich folgt zwischen der Datalist, dem Single- und dem Multiselect. Auf Windows verhält sich Edge sehr ähnlich wie Chrome, da die Codebasis beider Browser Chromium ist.

Tabelle 3.2: Vergleich Interaktion Datalist & Select in Edge (Windows)

[1] Blinkender Strich in einem Eingabefeld [2] Filter: Input-Begriffe and-verknüpft enthalten; Liste verändern je nach Anzahl passender Werte [3] Suche: Erster zu der Eingabe passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ letzter noch übereinstimmender Wert; Liste unverändert; nach Pause / Debounce-Ablauf ⇒ neue Suche [4] Wert von dem size-Attribut [5] Verhalten der CSS-Position fixed

3.2.3 Chrome Browser

Die Gegenüberstellung 3.3 beschreibt die Bedienungsmöglichkeiten der drei existierenden Auswahlkomponenten in Chrome. Dabei spielt das System (Windows oder Mac) nur bei der Tastenkombination und nicht bei der Reaktion eine Rolle. Auf dem Mac verhält sich Chrome ähnlich wie auf Windows, Designaspekte können sich unterscheiden.

Tabelle 3.3: Vergleich Interaktion Datalist & Select in Chrome (Mac / Windows)

[1] Blinkender Strich in einem Eingabefeld [2] Filter: Input-Begriffe and-verknüpft enthalten; Liste verändern je nach Anzahl passender Werte [3] Suche: Erster zu der Eingabe passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ letzter noch übereinstimmender Wert; Liste unverändert; nach Pause / Debounce-Ablauf ⇒ neue Suche [4] Wert von dem size-Attribut [5] Verhalten der CSS-Position fixed

3.2.4 Firefox Browser

Die nachfolgende Aufstellung 3.4 zeigt die Reaktionen auf gewisse Benutzerinteraktionen in Firefox. Wie auch auf Windows zeigt Firefox auf dem Mac konsistentes Verhalten, jedoch mit typischen OSX-Designanpassungen. Die Interaktions-Feedbacks auf Mac können sich leicht von der Windows-Version unterscheiden.

Tabelle 3.4: Vergleich Interaktion Datalist & Select in Firefox (Mac / Windows)

[1] Blinkender Strich in einem Eingabefeld [2] Filter: Leerschlag als normales Symbol gezählt; Liste verändern je nach Anzahl passender Werte [3] Suche: Erster zu der Eingabe passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ letzter noch übereinstimmender Wert; Liste unverändert; nach Pause / Debounce-Ablauf ⇒ neue Suche

3.2.5 Safari-Browser

Die Interaktionen auf Safari sind in der Tabelle 3.5 einander gegenübergestellt. Der Apple-Standard-Browser zeigt zu den bisher gesehenen Vergleichen die grösste Abweichung.

Tabelle 3.5: Vergleich Interaktion Datalist & Select in Safari (Mac)

[1] Blinkender Strich in einem Eingabefeld [2] Filter: Leerschlag als normales Symbol gezählt; Liste verändern je nach Anzahl passender Werte [3] Suche: Erster zu der Eingabe passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ sortiert nachfolgender Wert; Liste unverändert; nach Pause / Debounce-Ablauf ⇒ neue Suche [4] Wert von dem size-Attribut

3.2.6 Browser auf Andriod & iOS

Der Vergleich der Tabellen 3.6 und 3.7 zeigt, dass auf Android-Geräten Abweichungen existieren. Nicht alle Bedienungsmöglichkeiten führen zur selben Reaktion.

Tabelle 3.6: Vergleich Interaktion Datalist & Select in Firefox (Android, Mobile)

[*] nicht möglich: Virtuelle Tastatur ist nicht sichtbar, somit kann keine Interaktion stattfinden

Tabelle 3.7: Vergleich Interaktion Datalist & Select in DuckDuckGo (Android, Mobile)

[*] nicht möglich: Virtuelle Tastatur ist nicht sichtbar, somit kann keine Interaktion stattfinden

[1] Filter: Leerschlag als normales Symbol gezählt; Liste verändern je nach Anzahl passender Werte; nicht scrollbar

Im Gegensatz zu den oben gezeigten Andriod-Browsern zeigen die meisten iOS-Browser die datalist und die selects auf derselben Basis an. Der iOS-Safari – als Stellvertreter – zeigt den Vergleich in Tabelle 3.8 auf.

Tabelle 3.8: Vergleich Interaktion Datalist & Select in Safari (iOS, Mobile)

[*] nicht möglich: Virtuelle Tastatur ist nicht sichtbar, somit kann keine Interaktion stattfinden

Wie in den Tabellen 3.6 bis 3.8 zu sehen ist, erlauben Mobilgeräte weniger Interaktionen als Desktop-Computer. Zum einen stellen die verschiedenen virtuellen Tastaturen eine geringere Auswahl an Interaktionen an. Auf der anderen Seite öffnet sich die virtuelle Tastatur nicht in jeder Situation. In Bezug auf die Komponenten Select und Datalist öffnet sich die dynamische Eingabemöglichkeit nur durch das Input der Datalist. Dies ist der Grund, wieso in den drei oben dargestellten Tabellen keine Tastatur-Interaktionen bei Selects möglich sind. Die Unterschiede bei der Datalist entstehen dadurch, dass nicht jeder mobile Browser die Liste bei Tastatureingaben offen lässt bzw. öffnet. Dadurch erklären sich die unterschiedlichen Verhaltensweisen, welche in den Tabellen ersichtlich sind.

Die Touch-Bedienungen auf der Datalist weisen kaum eine Übereinstimmung auf. Das Scrollen wie auch das Klicken verhalten sich bei den ausgewählten Mobile-Browsern Safari, Firefox und DuckDuckGo unterschiedlich. Das Select zeigt sich in der Interaktion mit dem Finger konsistenter.

3.2.7 Undo/Redo

Die Tastatur-Interaktionen Undo\footnote [12] und Redo [13] verhalten sich in allen Desktop-Browsern gleich. Beim Select – Single als auch Multi – passiert nichts. Im Input-Feld mit der Datalist reagieren die Aktionen auf den geschriebenen Text. Die einzige Ausnahme ist Safari, welcher das Undo/Redo auf Browserebene ausführt. Das bedeutet, die Interaktion betrifft nicht nur das fokussierte Eingabefeld, sondern alle Änderungen im Browser wie das Schliessen von Tabs.

Von den Mobilgeräten unterstützt nur das iOS-System via Schüttel-Bewegung das Undo bzw. Redo. Der iOS-Safari Browser zeigt dieselbe Reaktion wie Safari auf dem Desktop.

3.2.8 Fazit

Die Gegenüberstellungen der existierenden HTML-Elemente zeigen einige Gemeinsamkeiten, aber auch viele Inkonsistenzen. Da die Unterschiede ein Grund für die Entwicklung einer neuen Auswahlkomponente sind, fasst dieser Abschnitt diese nochmals zusammen. Im UI existieren über die vier Browser Edge, Firefox, Chrome und Safari sowie die Systeme OSX und Windows teilweise grosse Inkonsistenzen. Das System-Theme [14] spielt für die Darstellung ebenfalls eine grosse Rolle. Hierbei spielen das betriebssystemspezifische Styling und die individuellen Implementierungen der Browser eine Rolle. Der Fokus dieses Abschnitts liegt auf der Interaktion. Das UI ist bereits im Kapitel UI-Unterschiede genauer beschrieben.

Zwischen Edge und Chrome bestehen keine gravierenden Inkonsistenzen. Dies liegt daran, dass die beiden Browser mit derselben Rendering Engine [15] arbeiten. Zwischen Mac und Windows bestehen nur die systemspezifischen Unterschiede wie die zu drückenden Tasten (z. B. Home vs. fn & ←).

Firefox unterscheidet sich von Chrome in mehreren Interaktionen. Während die offene Datalist auf Firefox mit ← und → zwei unterschiedliche Reaktionen zeigt, reagiert sie im Chrome auf dieselbe Weise. Das Multiselect zeigt in den beiden Browsern ebenfalls inkonsistentes Verhalten. Die Enter-Taste löst auf Firefox im geschlossenen Single-Select nichts aus, während Chrome die Liste öffnet. Dafür reagiert Firefox im Multiselect auf Tab (Input verlassen), wo Chrome kein Verhalten zeigt. Die Interaktionen PageUp/-Down zeigen sich sowohl bei Datalist als auch beim Select unterschiedlich. Der eine Browser verwendet die View-Höhe als Mass zum Überspringen der Elemente und der andere das size-Attribut. Im geschlossenen Zustand des Single-Select überspringt die Selektion ebenfalls eine unterschiedliche Anzahl Elemente. Bei der Interaktion mit der Maus weist das Scrollen auf beiden geöffneten Elementen Inkonsistenzen im Verhalten auf.

Safari zeigt gegenüber den oben angesprochenen Browsern die grösste Abweichung. Einige Aktionen ändern anstelle der Selektion nur das Highlight. Zu den Chromium-basierten Browsern – wie Chrome – ist der Apple-Browser am ähnlichsten. PageUp/-Down zeigt bei den Einzelauswahl-Elementen ein komplett anderes Verhalten. Beim Single-Select ist die Reaktion dieselbe wie beim Drücken von Home/End. Die einzige Interaktion, welche nicht von den anderen Browsern abweicht, ist das Klicken auf ein Element.

Über verschiedene Plattformen hinweg erschweren die inkonsistente Darstellung und Funktionalität dieser Komponenten eine einheitliche Benutzererfahrung. Für eine optimale User-Experience ist die Konsistenzprüfung unabdingbar. Diese Erkenntnisse legen den Grundstein für die Entwicklung einer neuen, optimierten Auswahlkomponente. Diese soll die bestehenden Probleme adressieren. Die bereits erstellte Länderkomponente löst die Inkonsistenzen. Details dazu folgen im nächsten Kapitel.

[12] Ctrl & Z auf Windows; Cmd & Z auf Mac [13] Ctrl & Y auf Windows; Cmd & Shift & Z auf Mac [14] Dark- bzw. Light-Mode; auf Systemebene oder Browserebene einstellbar [15] Mehr dazu steht im Kapitel Browser & HTML-Renderer