Unser erster Dank geht an Prof. Dierk König und Fabian Affolter für die wertvollen Tipps und durchgehende Unterstützung während der Bachelorarbeit 24FS_IMVS17: Generalisierte Auswahlkomponente für das Web UI Toolkit «Kolibri». Ihr Fachwissen und ihre Anleitungen haben entschieden zu unserer Lösung und dem Erfolg beigetragen.

Zudem danken wir allen StudentInnen und FreundInnen, die sich als Testpersonen zur Verfügung gestellt haben. Sie haben uns mit konstruktiver Kritik und hilfreichen Anregungen Fehler und mögliche Erweiterungen aufgezeigt. Das Feedback hat uns inspiriert und Diskussionen mit unseren KommilitonInnen haben uns auf neue Ideen gebracht. Ohne sie hätte diese Arbeit nicht in dieser Form entstehen können.

Weiter sprechen wir unseren Dank an unsere Familien und FreundInnen für ihre ständige Unterstützung und ihr Verständnis aus. Sie haben uns während des Studiums und der Fertigstellung dieser Arbeit motiviert, unser Bestes zu geben. Ihre Geduld und ihre Ermutigungen haben uns geholfen, die Konzentration zu halten und Kraft zu tanken. Sie haben während der ganzen Zeit ein offenes Ohr geboten und durch das Korrekturlesen zum Erfolg der Arbeit beigetragen.

Zum Abschluss gilt unser Dank noch allen Personen, die uns im ganzen Studium und auch bei der Bachelorarbeit unterstützt haben. Ihre wertvollen Inputs, Hilfen und Motivationen beeinflussten den erfolgreichen Abschluss der Arbeit. Wir sind dankbar für diese Erfahrungen und all die Unterstützung und Anleitungen, die wir erhalten haben.

1.1 Problemstellung

Im Web existieren diverse Möglichkeiten zur Erstellung eines Auswahl-Inputs mit vorgegebenen Werten. Die HTML-Elemente bieten über die verschiedenen Browser keine konsistente Darstellung und Interaktion an. Dazu sind sie nicht schön anzusehen und nur geringfügig anpassbar. Die Werte sind begrenzt auf Text und Unicode-Symbole. Die Komponente ist nicht effizient bedienbar – besonders bei einer grossen Menge an Werten.

Als Alternative zu den Basiselementen existieren unzählige Bibliotheken, welche solche Eingabemöglichkeiten unterstützen. Diese besitzen externe Abhängigkeiten, welche das eigene Projekt unnötig aufblasen. Zudem benötigen viele dieser Libraries eine längere Einarbeitungszeit, um die Funktionalitäten verstehen und anwenden zu können.

Das Vorgängerprojekt Länderauswahl-Komponente deckt die Probleme ab, ist aber nur auf die Auswahl eines Landes zugeschnitten. Eine Anwendung dieser Komponente mit anderen Inhalten kann zu unerwünschtem Verhalten führen. Die oben genannten Probleme dienen als Basis für das folgende Kapitel.

1.2 Ziel

Die neue Komponente SelectComponent zielt darauf ab, die Auswahl eines Wertes aus einer begrenzten, vorgegebenen Menge zu ermöglichen. Dazu finden die Generalisierung und der Ausbau der vorangegangenen Länderauswahl statt. Die Eingabe soll weiterhin effizient bleiben und sich konsistent über alle Browser zeigen. Dabei liegt der Fokus auf Browsern von Desktop-Computern bzw. Laptops. Die Komponente soll sich einfach anpassen lassen. Als Werte sind nebst Texten auch Bilder wünschenswert. Die Qualität ist auf dem Kolibri-Standard zu halten und durch Tests zu beweisen. User-Tests mit Programmierern wie auch Endanwendern beweisen die gute Usability. Automatisierte Komponententests stellen die Korrektheit der Implementation sicher. Bei der Umsetzung sollen die Design-Patterns des Kolibri ihre Anwendung finden. Dabei sollen das Design und die Interaktion mit dem Toolkit synchronisiert sein. Hierbei ist zu beachten, die Ziele nicht ausserhalb des Projekts zu definieren.

1.3 Out of Scope

Dieses Projekt bezieht sich auf die Entwicklung einer Auswahlkomponente für Nutzer ohne Seheinschränkungen. Daher spielt die Accessibility nur eine begrenzte Rolle. Screenreader sind nicht zu beachten, da dies zu umfangreich für diese Arbeit ist. Die effiziente Anzeige von übergrossen Datenmengen mit mehr als 10'000 Werten ist nicht verlangt. Die Eingabe eines eigenen Wertes in die neue Auswahlkomponente ist ebenfalls ausserhalb der Anforderungen. Für die generalisierte Komponente reicht es, wenn die Auswahl eines einzelnen Wertes möglich ist. Die Auswahl mehrerer Werte im selben Eingabeelement ist nicht gefordert. Die Komponente ist nicht speziell auf Mobile-Geräte auszurichten. Eine Undo- wie auch eine Redo-Funktion der ausgewählten Werte ist ausserhalb des geforderten Rahmens. Ein Bestandteil dieser Arbeit ist das Erweitern des SimpleInputs um ein Select und eine Datalist. Damit der Fokus des Projekts auf der generalisierten Auswahlkomponente bleibt, sind keine Änderungen ausserhalb der oben genannten Ziele gefordert. Anpassungen der Kern-Codebasis gehören nicht in den Rahmen dieses Projekts. Die Eingrenzung der Anforderungen stellt sicher, dass die Ressourcen auf das Ziel fokussiert bleiben.

1.4 Leitfaden

Dieser Bericht gliedert sich in die Teile Hintergrund, existierende und neue Komponenten sowie die Diskussion. Jedes Kapitel baut auf dem Vorherigen auf und führt den Leser Schritt für Schritt durch die Entwicklung und Optimierung der neuen Auswahlkomponente.

Im Kapitel Hintergrund (2) ist die Ausgangslage (2.1) des Kolibri-Toolkits und des Projekts erläutert. Es folgt eine Erklärung der Master-Detail-View (2.2). Nachfolgend sind die verschiedenen Zustände (2.3), die eine Auswahlkomponente besitzen kann, aufgeführt. Eine Beschreibung der Browser und deren Rendering-Engines (2.4) ist ebenfalls enthalten. Der Rendering-Prozess einer HTML-Seite sowie die wichtigsten Browser-Implementationen sind ebenfalls auf dem Plan.

Das Kapitel existierende Komponenten (3) vergleicht die HTML-Elemente Datalist und Select (3.1). Die Nutzung und Unterschiede der verschiedenen Elemente sind hier ebenfalls beschrieben. Dabei hebt es die Browser-Inkonsistenzen (3.2) hervor. Sie führen zu unterschiedlichen UI-Erfahrungen. Die Länderauswahl-Komponente (3.3) aus der Vorarbeit ist nur auf die Auswahl eines Landes zugeschnitten. Mögliche Anwendungsfälle (3.4) der existierenden Komponenten zeigen die dabei entstehenden Probleme auf.

Eine detaillierte Beschreibung der neuen Komponente findet sich im gleichnamigen Kapitel 4. Das Design (4.1) basiert auf dem Kolibri-Designsystem. Beim Visualisieren und Testen des neuen Designs kommen Figma-Prototypen zum Einsatz. Die Implementation der Zustände optimiert die Benutzerführung für Maus- und Tastaturbenutzer. Prototyping und Benutzerfeedback tragen in einem iterativen Prozess zur Verbesserung bei. Das Implementationsresultat visualisiert und beschreibt die neue Komponente in diversen Beispielen. Im Abschnitt Interaktionen (4.2) sind Regeln für die Maus- und Tastaturinteraktion festgelegt. Für einen stabilen und verständlichen Code sorgt die Einhaltung diverser Prinzipien und Regeln (4.3). Der Einsatz von Patterns (4.4) wie Null-Object, Projector und Decorator strukturiert die Implementation. Die Patterns erhöhen die Wartbarkeit des Codes. Der Dropdown-Container (4.5) lässt sich auf verschiedene Weisen umsetzen. Das Kapitel Performance (4.6) beschreibt Optimierungen zur Verbesserung der Ladezeit sowie des Leistungspotenzials der neuen Auswahlkomponente. Das Testing-Kapitel (4.7) dokumentiert die Durchführung sowie die Auswertung manueller, automatisierter und Usability-Tests. Schliesslich fasst das Fazit der neuen Komponente (4.8) die wichtigsten Erkenntnisse zusammen.

Abschliessend bietet die Diskussion (5) einen Überblick über die Bedeutung der Erkenntnisse für die Entwicklung. Zudem beschreiben die Future Features (5.1) Ideen für eine Weiterentwicklung sowie Verbesserungsvorschläge.

Die vorliegende Dokumentation beschreibt die Entwicklung einer plattformunabhängigen Dropdown-Komponente, die konsistent und benutzerfreundlich gestaltet ist. Die Hauptmotivation für diese Entwicklung ist, eine Komponente zu schaffen, die sowohl ästhetisch ansprechend als auch funktional ist. Sie lässt sich über verschiedene Webbrowser hinweg einheitlich nutzen. Die Komponente ist unabhängig von externen Bibliotheken entwickelt. Dazu basiert sie auf dem Kolibri-Designsystem, das als grundlegende Designrichtlinie dient.

Wöchentliche Meetings und die intensive Zusammenarbeit mit den Betreuern sind Bestandteile der gewählten, agilen Entwicklungsmethode. Diese Vorgehensweise überprüft den Fortschritt und plant das weitere Vorgehen. Die Testergebnisse zeigen, dass der Kolibri-Codestil eine kurze Einarbeitungszeit erfordert. Danach ist jedoch eine einfache Integration in Projekte wie auch eine Anpassung der Komponente möglich.

Ein besonderes Merkmal der neuen Komponente ist die Möglichkeit, mittels mehrspaltiger Filterung eine gezielte Auswahl zu treffen. Die Vorauswahl eines Jahrzehnts ermöglicht die einfache Auswahl eines Geburtsjahres. Die Reduktion der Jahreszahlen minimiert das Scrollen und Suchen. Dieses Prinzip lässt sich analog für andere Anwendungsfälle – wie die Auswahl von Kontinenten & Ländern oder spezifischen Mahlzeiten (z. B. vegetarische Gerichte) – anwenden.

Für die Zukunft bietet die Komponente eine flexible Basis, die leicht zu erweitern ist. Zudem bestehen Potenziale für die Entwicklung ähnlicher Komponenten für weitere Anwendungsbereiche.

4.3 Prinzipien & Regeln

Diverse Prinzipien garantieren einen stabilen und verständlichen Code. Ein Ansatz ist, alle Objekte so immutable als möglich zu halten. Dadurch lassen sich unerwartete Änderungen verhindern. Weiterhin gilt es, die Bestandteile im KISS-Stil umzusetzen. Dazu zählt, dass die einzelnen Objekte und Funktionen möglichst privat zu gestalten sind. Die Bausteine sind kurz und übersichtlich aufzubauen. Zu diesem Zweck soll Separation of Concern zum Einsatz kommen, so dass jede Funktion nur eine Aufgabe zu erfüllen hat. Damit der Code einfach und lesbar bleibt bzw. wird, gilt es, Entscheidungen zu treffen. Zu diesen Entschlüssen zählt das bewusste Weglassen von Funktionalität und somit auch Komplexität.

Beim Implementieren ist darauf zu achten, den Code sauber zu formatieren. Zudem ist es sinnvoll, die Änderungen regelmässig mit dem Code-Analyse-Tool von IntelliJ auf ihre Qualität zu prüfen. Diese Prinzipien und Regeln unterstützen eine ordentliche Entwicklungsumgebung für eine stabile Komponente. Das Kapitel Patterns bietet eine weitere Möglichkeit, den Code strukturiert zu halten.

Generalisierte Auswahlkomponente für das Web UI Toolkit "Kolibri"

Informatik Projekt 6

Lea Burki und Ramona Marti

Die Grundlagen stellen ein gemeinsames Verständnis der Auswahlkomponente her. Dazu zählen die Zustände, welche in diesem Zusammenhang auftreten können. Ausserdem behandelt es eine Basis zu den Themen Browser und Rendering. Dieses Verständnis ermöglicht es, eine neue, konsistente Komponente zu entwickeln.

2.1 Ausgangslage

Studenten wie auch Mitarbeiter der FHNW entwickeln das Toolkit Kolibri laufend weiter. Entwickler können die Open-Source-Werkzeuge einfach importieren und verwenden. Damit das Kolibri-Toolkit schlank bleibt, kommen keine externen Abhängigkeiten zur Verwendung. Mit einer VanillaJS-Codebasis bietet das Tool eine breite Auswahl an, deckt aber noch nicht alle Interaktionen ab.

Der in der Vorarbeit [1] hergestellte Fork dient als Ausgangslage. Ein Merge – des Branches experimental dieses Forks und des Kolibri-16 der originalen Codebasis – stellt die Aktualität sicher. Das SimpleInput ist eines der Tools, welches sich bei der Implementation der neuen Auswahlkomponente als hilfreich erweisen kann.

Die Vorarbeit beinhaltet sowohl einen Recherche- als auch einen Design- und Implementationsbestandteil. Die Recherche legt den Fokus auf das Prototyping und diverse Code- und Implementationsbausteine. Die Anwendung der Informationen aus den Recherchen findet sich im Weg zur Länderauswahl wieder. Mehr zum Resultat dieser Arbeit folgt im Kapitel . Der komplette Bericht ist in der Quelle nachzulesen.

Der Zugriff auf das Tool Figma ermöglicht das Verwenden des existierenden Designsystems und der bereits eingebundenen Elemente. Der Aufbau der Elemente als Komponenten vereinfacht die Wiederverwendung. Das Ergänzen des Icon-Sets ist bei Bedarf erlaubt.

Eine weitere, wichtige Ausgangslage ist ein gemeinsames Verständnis der verwendeten Begriffe. Dies sicherzustellen, ist die Aufgabe der nächsten zwei Kapitel mit der Beschreibung der Master-Detail-View und der Zustände eines Dropdown sowie dessen Elemente. Diese Definitionen gelten im gesamten Bericht.

[1]

2.2 Master-Detail-Ansicht

Eine Auswahlkomponente lässt sich unkonventionell in eine Master-Detail-Ansicht einteilen. Dies ist in Abbildung 2.1 ersichtlich.

Typisch für die Master-Detail-View ist, dass die Detail-Ansicht mehr Daten anzeigt als der Master. Bei der Anwendung des Patterns auf eine Auswahlkomponente ist dies nicht der Fall. Anders als bei der typischen Master-Detail-View beinhaltet die Detail-Ansicht keine weiteren Informationen. Der Master listet alle möglichen Optionen auf. Dieser View-Baustein findet sich im aufklappenden, scrollbaren Container wieder. Die dauerhaft sichtbare Komponente stellt die Detail-View dar. Dieser Container beinhaltet sowohl den aktuell selektierten Wert als auch das Dropdown-Icon. Weiteres zu den möglichen Zuständen ist im nachfolgenden Kapitel zu finden.

2.4 Browser & HTML-Renderer

Die wichtigsten Aspekte von der Theorie über die populären Browser bis hin zum Ablauf des Renderings sind hier aufgeführt. Dabei sind nur die bekanntesten Implementationen von Belang.

Ein Webbrowser dient als Zugang ins Internet und zur Anzeige von Webressourcen wie HTML, CSS und JavaScript. Er besteht aus einer Benutzeroberfläche, einer Browser- und einer Rendering-Engine. Für eine verständliche Darstellung der Inhalte auf dem UI verwendet die Browser-Engine einen sogenannten Renderer – mehr dazu später. Die Benutzeroberfläche dient als Schnittstelle zwischen dem Benutzer und der Datenschicht. Die Rendering-Engine interpretiert die Inhalte anhand des vorgegebenen Inhaltstyps. Einer der Engines ist der HTML-Renderer. Beim UI und der Bedienung zeigen sich die Uneinigkeiten zwischen den Browser-Herstellern. Der Grund liegt darin, dass die Rendering-Engine den Code nicht gleich interpretiert. Anschliessend sind Informationen über den detaillierten Ablauf zur Anzeige eines HTML-Dokuments und die Rolle des Renderings dokumentiert.

2.4.1 Rendering-Prozess

Der Aufruf einer Webseite beginnt mit dem HTTP-Request, auf welchen eine HTTP-Response folgt. Die zuvor genannten Schritte vor der eigentlichen Datenerhebung sind in diesem Bericht nicht weiter von Bedeutung. Der Response liefert letztlich die anzuzeigenden Daten, welche in diesem Fall die tragende Rolle spielen.

Der Browser verarbeitet die erhaltenen Daten im HTML-Format weiter. Mehrere Schritte wandeln die einzelnen HTML-Elemente in sogenannte Nodes um. Aus den resultierenden Nodes entsteht durch Verknüpfungen eine Baumstruktur – der DOM. Das Document Object Model (DOM) (Abbildung 2.4 links oben) beschreibt die Eltern-Kind- und Geschwister-Beziehung der Nodes. Der Prozess des CSS Object Models (CSSOM) gestaltet sich relativ ähnlich, ist aber nicht weiter wichtig.

Der DOM und der CSSOM sind unabhängig voneinander. Der Browser kombiniert die beiden Bäume zu einem gemeinsamen Renderbaum (Abbildung 2.4 rechts). Der resultierende Baum repräsentiert nur sichtbare Elemente, wohingegen der DOM alle Elemente enthält. Der Renderbaum ist browserabhängig.

Dieses Wissen ist wichtig für das spätere Kapitel Performance. Der Grund ist, dass der Browser maximal 60 Mal pro Sekunde rendern kann. Jede Änderung am Browser-DOM [2] startet den kompletten Rendering-Prozess von vorne. Zu viele Änderungen am DOM führen dazu, dass der Nutzer länger warten muss, bis die Webseite geladen ist.

Gründe für ein erneutes Rendern [3]:

• Manipulation der Elemente des DOM

• Änderungen des Inhalts (auch von Formularfeldern)

• Änderungen der CSS-Eigenschaften

• Hinzufügen oder Entfernen der Stylesheets

• Ändern des Attributs class

• Ändern der Grösse des Browserfensters

• Scrollen des Browserfensters oder der Elemente

• Aktivieren der Pseudo-Klassen

2.4.2 Bekannte Implementationen

Die neue Komponente soll in möglichst allen Browsern eine konsistente Erscheinung wie auch Interaktion bieten. Durch die Erklärung aus Kapitel Rendering-Prozess ist klar, dass die Renderer die Unterschiede im UI bewirken. Die Bedienungsabweichungen stammen grösstenteils vom zugrunde liegenden Betriebssystem. Diese Erkenntnisse führen dazu, dass die neue Komponente auf Mac und Windows mit den geläufigsten Renderern zu testen ist. Zu den ausgewählten Webbrowsern zählen Google Chrome, Firefox (Mac und Windows), Safari (nur Mac) und Edge (nur Windows). Die Erläuterung dazu folgt im nächsten Abschnitt.

Die populärsten Browser mit 65% Marktabdeckung basieren auf der Chromium-Basis und verwenden alle den HTML-Renderer Blink [4]. Die Entwickler dieser Rendering-Engine sind die Open-Source-Community Chromium, Google, Intel und Samsung. Zu den Browsern [5], die Blink als Rendering-Engine nutzen, gehören unter anderem Google Chrome, Brave, Microsoft Edge, Opera und Vivaldi. WebKit [6] – der Vorgänger des geläufigsten Renderers Blink – findet sich im OSX-Webbrowser Safari wieder. Diese von Apple, Google, KDE und Nokia entwickelte Rendering-Engine deckt 15% ab. Firefox und weitere auf Mozilla basierende Browser [7], die Webseiten mit Gecko rendern, sind die bekanntesten Vertreter der verbleibenden Browser. Es existieren noch weitaus mehr Renderer, welche aber eine sehr geringe Verbreitung aufweisen. Deswegen sind diese nicht weiter von Belang.

[2] Im Renderbaum verwendeter und im Browser angezeigter DOM [3] (Dev, 2020) [4] (Wikipedia, 2024a) [5] (Ola und Markus, 2024a) [6] (Wikipedia, 2024b) [7] (Ola und Markus, 2024b)

2.3 Zustände in einer Auswahlkomponente

Dieser Abschnitt erklärt die Zustände, welche in einer Auswahlkomponente auftreten können. Als Ausgangslage dient eine Eingabemöglichkeit, die eine Master-Detail-Ansicht aufweist. Zudem sind keine speziellen Voreinstellungen getroffen.

Je nach Darstellung der Komponente kann diese offen oder geschlossen sein. Im geschlossenen Status (Abbildung 2.2) zeigt das Erscheinungsbild nur die Detail-Ansicht an. Diese zeigt mindestens den selektierten Wert an. Eine offene Auswahlkomponente wie in Abbildung 2.3 stellt beide Elemente der Master-Detail-View dar. Die Master-Ansicht zeigt alle Optionen in einer Liste an.

Bei dem normalen bzw. nicht fokussierten Status ist die Komponente nicht an- oder ausgewählt. Wenn eine Webseite diese Komponente enthält, ist dies die standardmässige Darstellung. Das neue Element zeigt keine Reaktion auf Interaktionen, welche in diesem Zustand geschehen. Als einzige Ausnahme gilt Tab, welche den Fokus auf die Komponente legen kann. In den meisten Erscheinungen ist nur die Detail-Ansicht sichtbar und der Master-Container ist ausgeblendet. Wählt der Nutzer die Komponente mit der Maus oder der Tastatur an, steht sie im Fokus bzw. ist sie fokussiert. Bedienungen über das Keyboard beziehen sich hierbei auf den Baustein. In den meisten Fällen ändert sich die Darstellung des Eingabefeldes – z. B. durch einen gelben Rahmen.

Ist ein Wert in der Master-Ansicht ausgewählt und erscheint in der Detail-View, ist dieser selektiert. Das Formular enthält beim Versenden das Value der Selektion. Eine Selektion in einer Kategorie-Spalte findet in den Formulardaten keine Berücksichtigung. Stattdessen filtert die Kategorie-Selektion die Wert-Spalte. Durch das Hervorheben zeigt sich in der Liste aller Werte eine getätigte Auswahl an. In gewissen Situationen existiert noch der Zustand, dass in der Master-View ein Wert im Highlight steht. Bestätigt der Nutzer das Highlight mit der Maus, wechselt der Status auf selektiert. Das Hovern kann den Highlight-Wert ändern. Geschieht die Navigation durch die Werte mit der Tastatur, erhält genau ein einzelner Wert die Cursor-Position. Durch das Betätigen gewisser vordefinierter Tasten ändert sich die Cursor-Position. Bei einer Bestätigung mit der Tastatur ändert sich der Wert der Cursor-Position auf selektiert. Die letzten zwei Zustandswerte haben keinen Einfluss auf das versendete Formular. Sie sind nur im Master zu finden. Nachfolgend sind noch die Details zum Thema Browser erklärt.

Hier sind die Gegenüberstellungen der bereits vorhandenen Möglichkeiten zur Darstellung einer Optionsauswahl aufgelistet. Eine Gegenüberstellung der möglichen Funktionalitäten zeigt die Grenzen dieser Elemente auf. Dabei spielen die UI- sowie die Interaktionsunterschiede dieser Komponenten in verschiedenen Browsern eine tragende Rolle.

Als Basis dieser Arbeit dient das Country Select. Unter dem Country Select ist das Resultat der Vorarbeit zu verstehen. Weiter existieren bereits die Elemente Buttons bzw. Links, select und datalist. Die folgende Tabelle 3.1 zeigt einen Vergleich der genannten Möglichkeiten.

Tabelle 3.1: Vergleich der Auswahlmöglichkeiten

[1] Filter: Liste verändern je nach Anzahl passender Werte [2] Suche: Liste unverändert; Erster zu der Eingabe passender Wert aus der Liste

Nebst den in der Tabelle aufgeführten Möglichkeiten existieren diverse Libraries und Frameworks. Viele dieser Lösungen für Auswahlkomponenten besitzen Abhängigkeiten zu weiteren Bibliothekskomponenten. Durch das Einbinden der Frameworks bläst sich der eigene Code extrem auf. Diese Auswahlkomponenten bieten eine Menge an Funktionen an, welche jedoch die Anwendung sehr komplex machen. Die Einarbeitung dauert lange. Da das Ziel dieses Projekts eine schlanke und einfach verwendbare Komponente ist, sind die existierenden Frameworks keine Lösung. Dieser Bericht legt keinen weiteren Fokus auf externe Bibliotheken.

3.4 Anwendungsfälle

Die Standard-HTML-Elemente finden in vielen Webapplikationen ihre Anwendung. Das bekannteste Beispiel eines Selects ist die Auswahl des Geschlechts. Diese Verwendung ist abgesehen vom Design unproblematisch. Ein anderer Anwendungsfall ist die Auswahl eines Jahres oder eines Geburtstags mit drei Selects. Das Ausfüllen dieser Situation gestaltet sich schon unangenehmer. Dies liegt daran, dass die Suche nach dem gewünschten Wert besonders beim Jahr eher lange dauern kann. Besonders mühsam gestaltet sich für Nutzer die Suche nach dem Herkunfts- bzw. Zielland aus einer Liste von ca. 250 weltweit. Aber auch den Wohn- oder Destinationsort aus mehreren 100 bis 1'000 (je nach Anwendungsgebiet) auswählen zu müssen, ist sehr zeitaufwendig. Die Datalist mit der eingebauten Filterfunktion bietet auf den ersten Blick eine angenehmere Anwendung. Das Problem ist jedoch, dass in den meisten Fällen eigene Eingaben unerwünscht sind. Als ebenfalls schlechte Alternative bietet sich das Select als Auswahlkomponente an. Damit zieht sich die Suche nach einem bestimmten Wert in die Länge – speziell wenn die Optionen nicht in alphabetischer Reihenfolge vorliegen. Selbst die Zuhilfenahme der Select-Suche [19] ist nicht in jeder Situation hilfreich. Ein weiteres Anwendungsgebiet findet sich in gewissen Webshops bei den Filter- und Sortierfunktionen wieder. Die Komponente zeigt sich unter anderem bei der Auswahl einer Grösse, Farbe oder Kategorie. In diesem Beispiel können viele Optionen bzw. Werte ohne klare Reihenfolge in einer Liste auftauchen. Dies führt dazu, dass das Auffinden des gewünschten Werts eher schwerfällt. All die oben genannten und noch weitere Fälle zeigen verschiedene Probleme auf. Die neue Komponente ermöglicht es, die unangenehmen Situationen aufzulösen. Mehr Informationen dazu sind im nachfolgenden Kapitel zu lesen.

[19] Durch das Drücken der Anfangsbuchstaben des gesuchten Wertes springt die Selektion zur passenden Option

3.1 HTML Datalist vs. Select

Die folgenden Unterkapitel zeigen die Möglichkeiten, welche die HTML-Elemente input, option, datalist und select bieten. Zudem zeigen tabellarische Gegenüberstellungen die Unterschiede und Inkonsistenzen dieser in verschiedenen Browsern und Betriebssystemen auf. Hierbei liegt der Fokus mehr auf der Interaktion mit den Komponenten als auf der Darstellung.

3.1.1 Option

Die beiden Auswahlkomponenten – datalist und select – verwenden option-Elemente. Die einzelnen Optionen wie in Code 3.1 Zeile 1 besitzen ein value-Attribut und einen Inhalt – das Label. Alternativ ist das label-Attribut (Zeile 2 ohne das selected) zu nutzen. An die Stelle des Inhalts ist das Value zu platzieren. Firefox unterstützt diese Variante jedoch nicht. Das Weglassen von value und label führt dazu, dass beide den Wert innerhalb des öffnenden und schliessenden Tags erhalten. Diese Variante ist in Zeile 3 (ohne das disabled) verwendet.

Das HTML-Element kann das Attribut disabled oder selected erhalten. Code 3.1 Zeile 2 definiert durch eine selected Option den initial ausgefüllten Wert. Dieses Attribut funktioniert nur im Zusammenhang mit dem select-Container. Bei einem disabled Element – wie in Code 3.1 Zeile 3 – erscheint das UI ausgegraut. Dieser Eintrag lässt keine Interaktion zu.

Das Designen von options [1] beschränkt sich auf die Text-/Hintergrundfarbe, welche jedoch nur in Firefox funktionieren. Die anderen Browser lassen kein Styling der Auswahl-Elemente zu bzw. zeigen dieses nicht an. Es ist nur ein skalarer Text als Inhalt erlaubt. Das bedeutet, keine weiteren Verschachtelung von Elementen ist möglich. Als Eltern-Elemente sind select, optgroup und datalist erlaubt. Alle gängigen Browser unterstützen das option-Element.

3.1.2 Select

Das select-Element speichert Werte durch die einzelnen option-Kinder. Eine mögliche Anwendung ist in Code 3.2 ersichtlich.

Abgesehen von der Grösse ist die Umgestaltung des Elements browserunabhängig kaum möglich. Es gibt jedoch aufwendige Wege, den Inhalt zu klonen und durch Wrapper neu zu stylen. In diesem Fall ist es notwendig, die Logik und die Interaktionen für die Accessibility neu zu implementieren. Gewisse Stylings lassen sich anwenden, wobei aber nicht alle Browser diese in derselben Weise übernehmen. Durch die komplexe Struktur des Selects ist eine eigene Darstellung schwierig zu kontrollieren.

Der Inhalt [2] des Elements können options oder optgroups sein. Mehr zur optgroup kommt im nachfolgenden Unterkapitel. Die ARIA-Rolle gibt der Komponente die Funktion einer Combobox (ohne size & multiple) oder Listbox.

Die mehrfache Auswahl rein per Tastatur bietet in der Interaktion geringere Möglichkeiten als mit der Maus. Die Maus kann mit gedrückter Cmd- (Mac) bzw. Ctrl-Taste (Windows) weitere Elemente dazu selektieren. Mit dem Drücken der Shift-Taste lassen sich alle Elemente zwischen der ersten und der letzten Option markieren. Damit die zuvor markierte Auswahl erhalten bleibt, ist beim Anwenden beider Techniken der Bereich mit Shift zuerst auszuwählen. Für das Markieren mehrerer Werte mittels Tastatur ist es unabdingbar, zuerst zum ersten Element zu navigieren. Mit Shift und den Pfeiltasten ↑ und ↓ ist ein Bereich wählbar. Firefox unterstützt noch die einzelne Mehrfachauswahl über die Tastatur. Auf dem Mac sind die Tastenkombinationen Systembefehle. Daher gibt es keine Alternative, als sie zuvor auszuschalten bzw. umzustellen.

3.1.2.1 Optgroup

Die optgroup dient als Zusatzelement. Das Element gruppiert die Optionen in einem select und versieht die enthaltenen options mit einem Zwischentitel. Der Titel lässt sich durch das label-Attribut – wie in Code 3.3 Zeile 2 – setzen, ist aber nicht selektierbar.

Das disabled ermöglicht das Ausgrauen eines ganzen Blocks von Auswahloptionen. In Code 3.3 ist dies auf Zeile 6 zu sehen. Die Optionen, welche in diesem Element enthalten sind, erben das Attribut. Als Inhalt dienen option-Elemente und selbst besitzt es als Eltern-Element ein select. Die optgroup besitzt die ARIA-Rolle einer Gruppe. Alle Browser unterstützen dieses Element.

3.1.3 Datalist

Das Stylen der datalist [3] ist sehr begrenzt bzw. nicht möglich. Der Datencontainer reagiert nicht auf den Zoom des Browsers. Gewisse Screenreader ignorieren die Vorschlagsliste und lesen diese dadurch auch nicht vor. Das Element erhält die ARIA-Rolle einer Listbox.

Die options einer datalist besitzen normalerweise nur ein value-Attribut und kein Label. Bei einer zusätzlichen Label-Definition kann das je nach Browser zu abweichenden Darstellungen kommen. Während Firefox nur das Label in der Liste anzeigt, visualisieren die anderen Browser das Label und das Value gemeinsam. Die Browser, welche Label und Value anzeigen, heben den Wert ein wenig hervor.

Die Darstellung kann zu Missverständnissen führen, da das Eingabefeld bei einer Auswahl nur das Value anzeigt. Die options-Werte können sich dem Typ des Inputs anpassen. Generell unterstützen alle Browser die datalist, aber Firefox nur begrenzt.

Nicht alle Browser unterstützen die Datenliste für jeden Eingabe-Typ [4]. Der textuelle Typ funktioniert in allen Browsern und die Liste öffnet sich nach einem Klick bzw. Doppelklick auf das Feld. Vordefinierte Datum- und Zeittypen funktionieren nur in den Chromium-basierten Browsern. Firefox und Safari zeigen den normalen Eingabe-Container, als ob die Liste nicht verknüpft ist. Bei der Verwendung einer Liste mit einer Range zeigen alle Browser die Optionen durch Markierungen auf dem Slider an. Die Kombination einer datalist mit einer Farbpalette zeigt eine breite, aber unterschiedliche Unterstützung. Unter den gängigen Browsern ist Firefox auf OSX der einzige, welcher die Liste nicht darstellt. Zusammengefasst bieten Chromium-basierte Browser für Listen mit den unterschliedlichsten Typen die beste Unterstützung.

3.1.3.1 Input

Dieser Abschnitt behandelt nur den Teil, welcher in Bezug auf die datalist von Belang ist. Das list-Attribut verknüpft das Input – in Code 3.4 auf Zeile 1 und 2 – mit den Auswahloptionen der Liste. Bei der Verwendung zusammen mit der datalist ist dieses Attribut Pflicht. Dadurch erscheinen die Auswahloptionen während der Bedienung des Input-Feldes.

Das Input besteht aus einem selbstschliessenden Tag. Die ARIA-Rolle ist vom Typ abhängig und ist einer Textbox, Combobox, Spinbutton, Slider, Searchbox, Telbox oder keiner speziellen Rolle zuzuordnen. In den hier erwähnten Möglichkeiten der Komponente existiert eine grossflächige Browserunterstützung. Die einzigen Ausnahmen beziehen sich auf die Typen week und month, welche im Firefox und Safari nicht funktionieren.

Input-Typen mit Datalist-Unterstützung

Bei den textuellen Typen [7] existieren text, search, number, email, url und tel. Diese Typen erscheinen mehr oder weniger als normales, einzeiliges Texteingabefeld. Die Ersten zwei der Auflistung verwalten einen Text ohne spezielle Anforderungen. Der Typ number dient zum Speichern der Werte als Zahlen und zeigt dies durch die Ergänzung zweier Buttons im UI-Feld. Die letzten drei Typen sind Textfelder, welche bereits ein passendes Pattern für E-Mail, URL oder Telefonnummer hinterlegt haben. Zudem zeigen diese Felder bei dynamischen Tastaturen ein der Situation angepasstes Layout [8]. Typen in der Kategorie Date-Time sind month, week, date, time und datetime-local.

Bei einer ungefähren Eingabe einer Zahl auf einem Intervall bietet sich range an. Im UI zeigt sich diese Komponente als Slider, wobei sich der Standardwert in der Mitte findet. Zur Festlegung der Limiten dienen min und max. Für eine Farbauswahl kann der Typ color zur Anwendung kommen. Die gängigen Browser zeigen nach dem Aufklappen Farbpaletten, welche sich aber in der Darstellung unterscheiden. Firefox beispielsweise greift auf die vom System gestellte Farbpalette zurück, wo Chromium-basierte Browser eine eigene bieten.

CSS für Input-Felder

Bei einem Input [9] bestehen mehrere Möglichkeiten, dieses umzugestalten. Es existieren eigene CSS-Pseudo-Klassen, wobei die folgende Aufzählung nur einen Ausschnitt aufzeigt.

• :enabled bzw. :disabled – reagiert auf das disabled-Attribut

• :read-write bzw. :read-only – reagiert auf das readonly-Attribut

• :valid bzw. :invalid – reagiert beim Abschicken des Formulars auf die Client-Side-Validität [10] des Felds

• :user-invalid – reagiert beim Verlassen des Inputs auf die Client-Side-Validität des Felds

• :in-range bzw. :out-of-range – reagiert auf das min- und max-Attribut

• :optional bzw. :required – reagiert auf das required-Attribut

• :blank – reagiert, wenn ein Feld leer ist

Weiterhin gibt es noch das Pseudo-Element ::placeholder, welches das Stylen des Platzhalters erlaubt. Das CSS-Property caret-color färbt den Cursor [11] in Inputs um. Im Gegensatz zur datalist und dem select lässt sich das normale Eingabefeld relativ gut designen.

Dieses Kapitel beschreibt die Bausteine der neuen Komponente auf verschiedenen Ebenen. Als erstes zeigt das Design die visuellen Darstellungsmöglichkeiten über die getroffene Auswahl bis hin zu den Prototypen. Dazu gesellen sich sowohl die Implementation der Zustände als auch die Umsetzung des Designs. Darauffolgend findet sich die Definition der Interaktion mit der Maus wie auch der Tastatur. Die für einen stabilen Code wichtigen Regeln und Prinzipien sind ebenfalls festgelegt. Die Anwendung diverser Patterns führt zu einer klaren Struktur und hoher Wiederverwendbarkeit. Als spezielles Element in der View zählt der Dropdown-Container. Dieser lässt sich unterschiedlich implementieren. Für ein angenehmes Nutzerfeeling spielt eine gute Performance eine tragende Rolle. Dies zeigen auch die ausgeführten User-Tests mit Endanwendern wie auch Programmierern. Automatisierte Tests für jede Komponente beweisen eine gute Codequalität.

4.2 Interaktionen

Damit ein gemeinsames Verständnis entsteht, gilt es für die Bedienung der Komponente Regeln festzulegen. Wie in den Grundlagen bereits beschrieben kann sich ein Wert aus dem Options-Container in verschiedenen Zuständen befinden. In diesem Absatz spielen Selektion, Highlight und Cursor-Position eine Rolle. Zur Auffrischung:

• Selektion: Ausgewählter Wert der Spalte

• Highlight: Element unterhalb des Mauszeigers

• Cursor-Position: Position (Element) der Tastatur

Bei der Festlegung der Maus-Interaktion fällt die Entscheidung auf Folgendes:

• mouseover: visuelles Highlighting des Elements ohne Selektionsänderung

• click: Änderung der Cursor-Position & der Selektion

Die Tastatursteuerung mit den Pfeiltasten hingegen hält sich an diese Bedienungen:

• Änderung der Cursor-Position

• keine Selektionsänderung

Als Basis für den ersten Projektor der neuen Komponente ergeben sich aus den oben genannten Regeln folgende Interaktionen (Tabelle 4.1).

Tabelle 4.1: Aktionen bei der ersten Version der neuen Komponente

[*] Änderung der Selektion bewirkt Änderung der Cursor Position auf den selben Wert

[1] Suche: Erster mit dem eingegebenen Symbol passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ nächster nachfolgender Wert; Liste unverändert; nach jedem Symbol ⇒ neue Suche

Das Undo und das Redo auf der Komponente erhalten im ersten Projektor keine spezielle Definition. Gewisse Verhaltensweisen finden sich sowohl im geschlossenen als auch offenen Zustand der Komponente wieder. Anders als bei den existierenden Komponenten, ist bei der Neuen die Leertaste neu belegt. Ist die Liste bereits offen, selektiert diese Interaktion den aktuell unter der Cursor-Position befindlichen Wert. Andere Projektoren können eigene Interaktionen definieren.

4.5 Dropdown-Container

Für die Darstellung aller Optionen (zu gegebener Zeit) stehen verschiedene Varianten zur Auswahl. Eine Möglichkeit ist, den Container als HTML-Dialog zu gestalten. Die vorhandenen Funktionen sind jedoch nicht für diese Komponente geeignet. Für den gewünschten Zweck erfordert das Dialog-Element noch einiges an benutzerdefinierter Anpassung.

Eine weitere Variante ist, ein normales div als Options-Container zu verwenden. Dies erfordert ebenfalls einen enormen Implementationsaufwand. Eine Anwendung dieses Ansatzes findet sich in der ersten Version der Komponente. Hierbei eröffnet sich das Problem der Inkonsistenz zwischen UI und Controller. Zudem ist es möglich, dass unerwünscht mehrere Dropdown-Container gleichzeitig offen sind.

Als dritte Möglichkeit bietet sich die Popover-API an. Seit 2024 unterstützen alle gängigen Browser diese Schnittstelle. Durch das Refactoring der Variante mit dem normalen Div-Container resultiert eine Version mit der Anwendung dieser API. Im Gegensatz zu den beiden oben erwähnten Container-Implementationen reduziert sich durch diese Schnittstelle der Zusatzaufwand. Der Grundaufbau des Popover-Containers ist im folgenden Code 4.8 dargestellt.

<div popover="auto"
     id="select-component-0-options" 
     class="options-component" 
> <!-- content --> </div>

Bei diesem Codeausschnitt (4.8) ist wichtig, dass das Attribut popover den Wert auto erhält. Dies bewirkt, dass sich die Popover automatisch schliessen, wenn ein Klick ausserhalb des Containers passiert. Das Öffnen und Schliessen des Dropdown-Elements lässt sich über das popovertarget-Attribut auf der Bedienkomponente steuern. Dieses Target enthält die id des Div-Containers mit dem Attribut popover. Als Alternative dazu besteht die Möglichkeit, das Popover über JavaScript zu steuern. Hierbei besteht die Möglichkeit, auf den Status und das Event des Togglens zuzugreifen. Diese Funktionalitäten erlauben dem Controller, sich konsistent zum UI zu halten.

Obwohl nur die Unterstützung der aktuellen Browser verlangt ist, soll die Komponente ältere Browser-Versionen nicht komplett ignorieren. Erst seit April 2024 unterstützen alle Browser die Popover-API. Ein Test auf einem veralteten Firefox zeigt, dass die Komponente wegen der Popover-Funktionalität einen Fehler in die Console wirft. Dadurch visualisiert der Browser die Komponente nicht. Der folgende Code 4.9 fängt die Fehlermeldung ab.

try {
    /* code block with 
        `popoverContainer.showPopover();`
    or  `popoverContainer.hidePopover();`
    */
} catch (e) {
    /* inform user about unsupported popover 
       the first time an alert popup appears */
}

Ein Alert-Popup informiert den Nutzer über Einschränkungen(Abbildung B.19 im Anhang B). Einige zusätzliche CSS-Definitionen garantieren eine halbwegs ansehnliche Darstellung. Veraltete Browser, welche das nested CSS [5] und das CSS-:has() nicht unterstützen, zeigen die neue Komponenten inkonsistent an.

[5] Verschachtelter CSS-Code mit Verwendung der &-Funktionalität

4.8 Fazit der neuen Komponente

Das Design der Komponente – inspiriert durch das Kolibri-Designsystem – stellt sicher, dass die visuelle Konsistenz und Benutzerfreundlichkeit erhalten bleiben. Die spezifischen Designoptionen wie Farbpalette und Layout sind sorgfältig ausgewählt und implementiert. Dadurch sind eine optimale Lesbarkeit und Bedienbarkeit gewährleistet. Diese Punkte sind durch die durchgeführten Tests bewiesen.

Der Einsatz von Figma-Prototypen ist entscheidend. Daraus erfolgen eine realitätsnahe Vorschau und Benutzerfeedback. Aus diesen Gründen verbessert sich die Benutzerfreundlichkeit kontinuierlich. Die Kombination von durchdachten CSS-Anpassungen stellt sicher, dass die Komponente intuitiv bedienbar ist. Eine klare Interaktions-Definition garantiert sowohl für Maus- als auch für Tastaturbenutzer eine gute Zugänglichkeit.

Die Integration von Prinzipien und Patterns führt zu einem stabilen und wartbaren Code. Mit KISS und Separation of Concern bleibt der Code einfach und gut lesbar. Die Umsetzung vom Null-Object und Projector Pattern garantiert die Wiederverwendbarkeit. Diese Patterns halten sich an das Separation of Concern-Prinzip. Ein wichtiger Baustein der SelectComponent ist der Container mit allen Werten. Die Wahl der Popover-API vereinfacht die Implementation enorm, da weniger zusätzliche Funktionalität notwendig ist.

Stetig durchgeführte, manuelle Tests ermöglichen eine Überwachung und einen Vergleich der Performance. Optimierungen im Code führen zu einer schnelleren Performance und einer angenehmen Benutzererfahrung. Automatische Tests gewährleisten eine hohe Codequalität und die Korrektheit der Funktionalitäten. Die durchgeführten User-Tests bestätigten die hohe Usability der Komponente. Ein agiles Entwicklungsverfahren ermöglicht während der Entstehung der neuen, effizienten Auswahlkomponente eine stetige Optimierung. Die SelectComponent bildet eine solide Grundlage für zukünftige Erweiterungen und Anpassungen.

4.1 Design

Das Ziel ist, eine konsistente und ansprechende Benutzererfahrung zu schaffen, die sich über alle modernen Browser hinweg hält. Das Design der neuen Auswahlkomponente ist stark vom Kolibri-Designsystem inspiriert. Das Designsystem bietet bereits ein umfassendes Set von Richtlinien und Komponenten. Diese ermöglichen eine einheitliche und benutzerfreundliche Gestaltung von Anwendungen. Das neue Design enthält jedoch einige Anpassungen, um die Lesbarkeit zu optimieren. Dazu benötigt es eine Analyse der Möglichkeiten, welche im nachfolgenden Kapitel beschrieben sind.

4.1.1 Mögliche Designoptionen eines Elements & deren Wahl

Elemente lassen sich durch diverse Eigenschaften stylen. Die Anpassung der Hintergrundfarbe fällt am schnellsten ins Auge. Diese ist hell zu gestalten, damit der Kontrast zur dunklen Standard-Schriftfarbe erhalten bleibt. Der Rahmen bietet eine weitere Designmöglichkeit. Seine Farbe, Dicke oder Struktur können variieren. Eine andere Alternative ist, nur eine Seite des Rahmens zu verwenden. Als Beispiel dafür gilt der sogenannte Spiegelstrich, welcher auf der linken Seite platziert ist. Für eine gute Erkennbarkeit sollte die Färbung rund um den Rahmen in einer eher dunklen Schattierung Anwendung finden. Als weitere Style-Eigenschaften bieten sich Änderungen der Schrift an. Bei der Farbe ist der Kontrast zu beachten, weswegen eine eher dunkle zu wählen ist. Alternativ lassen sich die Dicke, Schriftart, Neigung, Grösse oder Dekoration ändern. All diese Style-Anpassungen lassen sich auf unterschiedliche Art und Weise kombinieren.

Bei den Farben existiert eine grosse Bandbreite. Da Kolibri bereits ein Designsystem besitzt, schränkt sich die Menge ein. Unter den vorhandenen Farbwerten bieten sich die Folgenden am besten an:

• Kolibri-Light/Yellow/100 → helles Weiss-Gelb

• Kolibri-Light/Yellow/300 (--kb-color-select) → helles Gelb

• Kolibri-Light/Warning/--kb-warning-dark → dunkles Gelb

• Kolibri-Light/Danger/--kb-danger-accent (--kolibri-color-accent) → mittleres Rasa

• Kolibri-Light/Success/--kb-success-accent → mittleres Grün

• Kolibri-Light/Success/--kb-success-light → helles Grün

• Kolibri-Light/Primary/--kb-primary-accent → mittleres Violett

• Kolibri-Light/Primary/--kb-primary-light → helles Violett

• Kolibri-Light/Secondary/--kb-secondary-accent → mittleres Blau

• Kolibri-Light/Secondary/--kb-secondary-light → helles Blau

• Kolibri-Light/Monochrome/--kb-color-body → mittleres Grau

• Kolibri-Light/Monochrome/--kb-color-line → helles Grau

Da die Elemente drei verschiedene Zustände gleichzeitig erhalten können, müssen die Styles kombinierbar sein. Nicht jede der erwähnten Eigenschaften und Farben eignet sich in gleichem Masse. Yellow-100 fällt schnell wieder weg, da je nach Display der Kontrast zu gering ist. Unter den restlichen hellen Schattierungen passt Yellow-300 am besten. Diese Farbe ist bereits als Selektionsfarbe im Code hinterlegt. Das vordefinierte --kb-color-select eignet sich am ehesten als Hintergrundfarbe. Dadurch ist klar, dass die anderen beiden Zustände eine eher kräftige bzw. dunkle Färbung benötigen. Der Blick auf die Namen im Designsystem zeigt eine weitere Farbe zur Hervorhebung eines Elements. Die Benennung des mittleren Rosas mit Accent (--kolibri-color-accent) bietet einen guten Kontrast zur Selektion. Diese Farbe ist ebenfalls im Code vordefiniert. Da die dritte Farbe nicht zu viel Unruhe in das Design bringen soll, schränkt sich die Farbauswahl weiter ein. Mit einem gut erkennbaren Kontrast zur Selektion bietet sich das dunkle Gelb --kb-warning-dark an.

Wie erwähnt ist die Eigenschaft Hintergrundfarbe durch die Wahl der Farbe bereits festgelegt. Die Änderung der Schrift sollte maximal die Farbe betreffen. Die anderen Font-Stylings sind schwer erkennbar oder zerstören das Bild. Der komplette Rahmen passt nicht in das Design und fällt somit ebenfalls weg. Da nicht beide Zustände auf die Schriftfarbe zugreifen können, bietet sich der oben genannte Spiegelstrich an. Das Rosa mit einem guten Kontrast zum Gelb findet sich im linksseitigen Rahmen wieder. Das dunkle Gelb färbt – nebst dem linksseitigen Strich – die Schrift. Die Zuordnung der Designwahl zu den fehlenden Zuständen steht im Kapitel Farbpalette.

4.1.2 Figma-Prototypen

Zur Visualisierung und zum interaktiven Testing des Designs kommt Figma zum Einsatz. Figma ist ein webbasiertes Tool zur Erstellung von UI/UX-Designs, das Echtzeit-Kollaboration ermöglicht. Das Sammeln der Feedbacks von Stakeholdern und Nutzern unterstützt eine effiziente Entwicklung. Dafür ist es unabdingbar, im Vorfeld mit Figma schnell Prototypen zu erstellen und mit den Probanden zu teilen. Das Arbeiten mit Figma-Komponenten erleichtert das Entwickeln enorm. Dies ermöglicht das Erstellen von Varianten ohne viel Aufwand. Die folgenden Screenshots 4.1 bis 4.3 zeigen die Prototypen der neuen Dropdown-Komponente.

Die ersten beiden Grafiken bilden die Komponente in verschiedenen Anwendungsgebieten ab. Die Abbildung 4.3 zeigt ein mögliches Design für einen Dark-Mode. Dabei sind die Farben so weit angepasst, dass der Kontrast weiterhin gegeben ist.

4.1.3 Farbpalette

Das Kolibri-Designsystem bietet eine Vielzahl von Farben. Der Figma-Prototyp enthält spezifische Anpassungen, so dass die Dropdown-Komponente gut lesbar ist. Für den Erhalt einer besseren Nutzerfreundlichkeit gestaltet sich die Farbauswahl aus Abbildung 4.4.

Diese bietet hohen Kontrast und verbessert somit die Barrierefreiheit der Anwendung. Die Gründe der Auswahl befinden sich im früheren Kapitel Mögliche Designoptionen eines Elements & deren Wahl. Die Zustände verbinden sich wie folgt mit der getroffenen Wahl der Farben.

• Original → Neu

• Kolibri-Light/Yellow/300 bzw. --kb-color-select → selected

• Kolibri-Light/Danger/--kb-danger-accent → highlighted

• Kolibri-Light/Warning/--kb-warning-dark → cursor position

Bei der Verwendung dieser Farben in der neuen Komponente sind einige CSS-Dateien notwendig. Diese dienen als Grundlage für das weitere Design. Der Code 4.1 zeigt die importierten CSS-Files.

@import "../../../css/kolibri-base.css";
@import "../../../css/kolibri-light-colors.css";

Die erste Zeile enthält die grundlegenden Kolibri Designs. Dazu gehören einige vordefinierte Farben wie eine Selektion oder ein Highlight. Weiterhin sind die Schriften und die Invalidität von Inputs festgelegt. Die zweite Datei ist für die breite Palette an Farben im Light-Mode zuständig.

4.1.4 Layout und Animation

Die Dropdown-Komponente besteht aus der Detail- und der Master-Ansicht. Dieser Aufbau ist im Kapitel Master-Detail-Ansicht genauer beschrieben. Das Layout innerhalb des Option-Popovers liegt in Spalten vor. Die einzelnen Optionen listen sich zeilenweise in den Spalten auf. Der Listencontainer öffnet sich mit einer Animation. Nachfolgender Codeausschnitt 4.2 zeigt die dafür relevanten Zeilen.

/* animation */
@keyframes open { 
    0%   { transform: scaleY(0); } 
    100% { transform: scaleY(1); } 
} 
/* popover closed */
[popover] {
    display: none;
    animation: open 300ms ease-in-out; 
    transform-origin: top center;
}
@starting-style {
    [popover]:popover-open { 
        height: 0;
    } 
}
/* popover opened */
[popover]:popover-open {
    display: flex; 
    height: fit-content;
}

Die grundlegenden Styling-Properties des Popover-Containers sind nicht aufgeführt. Die CSS-Regeln aus Code 4.2 definieren die öffnende Animation des Popovers. Das @keyframes regelt die Transformation bzw. Animation, welche das Ausfahren des Containers festlegt. Das [popover] steuert das Erscheinungsbild des geschlossenen Popovers. Die Animation ist mit Zeile 9 an den Popover-Container gebunden. Die Zeilen 12 bis 16 definieren die CSS-Regeln, welche zum Start des Öffnens gelten. Der Selektor :popover-open legt die Darstellung des offenen Zustands fest.

Das Togglen des Popover erhält zusätzlichen Code, damit der Controller aktuell bleibt. Das entsprechende Event aus Codeausschnitt 4.3 führt ein Update auf dem Controller aus.

optionsContainer.addEventListener("toggle", (event) => {
    if (event.newState === "open") {
        optionsContainer.classList.toggle("opened", true);
        selectController.setOptionsVisibility(true);
    } else {
        optionsContainer.classList.toggle("opened", false);
        selectController.setOptionsVisibility(false);
    }
    // more code to update scrollbars in columns
});

Dieser Code (4.3) prüft beim Togglen den neuen Status des Events. Anhand des Status erhält das Popover ein Update bei den Klassen. Die weiteren Zustände sind im nachfolgenden Kapitel genauer beschrieben.

4.1.5 Implementation der Zustände

Die Auswahlkomponente ist so gestaltet, dass sie sowohl für Maus- als auch Tastaturbenutzer optimal funktioniert. Das Design der Interaktionen bietet eine intuitive und leicht zugängliche Bedienung der Komponente. Spezifische CSS-Klassen erleichtern die Benutzerführung. Sie definieren die Styles der hervorgehobenen (highlighted) bzw. ausgewählten (selected) Optionen. Die Cursor-Position für die Tastatur erhält ebenfalls eine eigene CSS-Klasse. Dieser Zusand wie auch das Highlight sind unter anderem durch einen Spiegelstrich dargestellt. Der CSS-Code 4.4 zeigt einen Style-Ausschnitt auf ein Cursor-Position-Element.

.cursor-position::before {
    content:       '';
    position:      absolute;
    left:          7px;
    top:           0.5em;
    bottom:        0.4em;
    transform:     translateX(-50%);
    
    background:    var(--kb-hsla-warning-dark);
    border-radius: 1px;
    width:         2px;
}

Der Selektor .cursor-position befindet sich immer nur auf einem Element – der Cursor-Position. Die Zeilen 2 bis 6 in Code 4.4 definieren die Position des Spiegelstrichs. Das Erscheinungsbild ist durch die Zeilen 8 bis 10 beschrieben. Eine dunkle Farbe und eine linksseitige Markierung betonen das Element der Cursor-Position. Das Highlight verwendet einen sehr ähnlichen Code. Die Farbe wie auch die Position sind jedoch angepasst. Zudem hält sich das Highlight nicht an eine Klasse, sondern nutzt die Pseudo-Klasse :hover.

Für ein konsistent gehaltenes UI sind diverse Event-Handler und UI-Update-Funktionen notwendig. Im columnOptionsProjector.js existiert beispielsweise ein Event-Handler. Er steuert das Setzen und Entfernen der Selektionsklasse. Dieser ist im nachfolgenden Code 4.5 ersichtlich.

const selectOptionItem = (root) => (newOption, oldOption) => {
    const oldItem = getHtmlElementByOption(oldOption, root);
    if (oldItem) {
        oldItem.classList.remove("selected");
    }

    const newItem = getHtmlElementByOption(newOption, root);
    if (newItem) {
        newItem.classList.add("selected");
    }
}; 

Die Funktion selectOptionItem verschiebt die Klasse selected vom Alten auf das neue Element. Dadurch passt sich das UI automatisch an. Damit sich die Änderung nur auf die Selektion der aktuellen Spalte auswirkt, verlangt die Funktion ein Elternelement. Das hier versendete getHtmlElementByOption sucht nur im mitgebenen Teilbaum des DOMs das HTML-Element zur mitgegebenen Option.

4.1.6 Prototyping

Der Einsatz von interaktiven Figma-Prototypen ist hilfreich beim Evaluieren der Benutzerfreundlichkeit und intuitiven Bedienung. Die Prototypen der neuen Auswahlkomponente bauen auf dem Resultat der Vorarbeit auf. Daher sind keine Low-Fi-Gestaltungen notwendig. Die Einbindung der in der Vorarbeit erhaltenen Feedbacks der Länderkomponente findet in den neuen Hi-Fi-Prototypen ihre Anwendung. Beispiele für die Designs sind in der Grafik 4.1 ersichtlich. Im oberen Bereich des Bildes befinden sich die Zustände der Optionen. Benutzertests decken die Mängel und Wünsche der Probanden auf. Mit der Integration der Rückmeldungen von Benutzerinteraktionen in das Design verbessert sich die Usability. Mehr zu den Nutzerfeedbacks folgt im Kapitel User-Tests. Das Resultat des umgesetzen Prototypen ist im nachfolgenden Kapitel genauer beschrieben.

4.1.7 Implementationsresultat

Die diversen oben beschriebenen Design-Schritte resultieren in den Abbildungen 4.5 bis 4.10. Weitere Bilder befinden sich im Anhang B.

Im geschlossenen Zustand (Abbildung 4.5) zeigt der Pfeil auf der rechten Seite nach unten. Das Icon ändert beim Öffnen der neuen Komponente die Richtung und zeigt nach oben (Abbildung 4.7). Die selektierte Option kann wie in der Grafik 4.6 ein Bild enthalten. Der Fokus auf der SelectComponent ist durch einen gelben Rahmen um die Detail-Ansicht visualisiert. Dies ist in Abbildung 4.8 im oberen Bereich ersichtlich. Ist das Feld required, erhält der Rahmen einen rosafarbenen Rahmen. Dabei ist der Fokus aber nicht überdeckt. Die disabled SelectComponent zeigt sich wie die anderen Eingabefelder ebenfalls ausgegraut.

Die offene Komponente stellt den Options-Container in jedem Fall unterhalb dar. Die Abbildung 4.7 enthält – nebst Normal – die drei möglichen Zustände der einzelnen Optionen. Der Wert Macedonia visualisiert die Selektion, welche sich ebenfalls im oberhalb befindlichen Detail-Container wiederfindet. Moldova zeigt die Optionen mit der Cursor-Position und somit die Stelle, an welcher sich die Tastatur befindet. Das Highlight enthält den Wert Montenegro. Die Cursor-Position und das Highlight können auf der gemeinsamen Option liegen. Dabei sind beide Zustände sichtbar. Die Abbildungen 4.8 bis 4.10 zeigen, dass die SelectComponent mehrere Spalten besitzen kann.

In diesen Beispielen befindet sich die Value-Option [1] jeweils in der rechten Spalte. Die anderen Spalten dienen zur Filterung der Werte. Die Grafik 4.8 mit der Selektion 2000’s begrenzt die Jahreszahlen von ursprünglich 70 auf noch 10 Werte. Nebst der selektierten Option kann jedes andere Element ebenfalls ein Bild enthalten (Abbildung 4.9). Wenn mehrere Kategorien existieren, bewirkt eine Selektion ganz links eine Reduktion aller Optionen, die auf der rechten Seite liegen. In der Abbildung 4.10 bewirkt die Wahl von North America die Reduktion der Länder und der Städte.

[1] Formular-Wert, wenn einer selektiert is

Resultate

Siehst du irgendwo Verbesserungspotenzial?

- Detail: numberOfColumns ist etwas "verbose" - Doku: In der Code Doku von SelectComponent dürfte der Return Value besser beschrieben werden (welches Array Element ist was). Das wird erst in den Anwendungsbeispielen klar.

Keyboard navigation. Using keyboard to narrow down possible categories/values (maybe fuzzy searching), otherwise it takes me longer to find something than compared to a standard dropdown, even if the list there is bigger.

ich finde es etwas unintuitiv beim SelectComponent neben den offensichtlich verständli- chen selectAttriutes (labl, name, numberOfColumns) noch ein Callback mitzugeben. ich hätte mir mehr beschreibung gewünscht wie ich die komponente verwenden muss. (ich musste eher dannach suchen.)

Bessere Dokumentation war verwirrend (Code).

Automatisches Schliessen der Komponente nach der Auswahl würde ich praktisch finden.

Es würde helfen, wenn die Types im JSDOC spezifiziert wären und wenn die Library eingebunden wäre. Dann wäre die Dokumentation leichter auffindbar.

War mir am Anfang nicht klar dass was SelectComponent() zurückgibt und ob das Input- element sowie dass label-element selbst erstellt werden soll. Danach war es intuitiv anzuwen- den.

Bemerkung

ich persönlich hatte zu beginn schwierigkeiten zu verstehen wie das framework funktio- niert. die beschreibung für die tasks (ab task2) sind zum teil etwas unklar => The value data is provided by the function ‘Service.getRegionsByCountry()‘, the cate- gories are provided by the function ‘Service.getCountries()‘ => RegionsByCountry muss man noch das Country mitgeben. Hätte in der beschreibung drinstehen können.

Nitpicking: while I see why the component is imported from a URL for the user tests, it makes it hard to use on a spotty network.

Isch s selectAttributes ‘numberOfColumns‘ wörklich nötig? Vo mir uus gseh, chönt mer ‘numberOfColumns‘ vo ‘serviceCallbacks.length‘ ableite...? Ehr hend nah recht es performance Problem wenn d liste lang isch... Dur s implementiere vo Task 2.2 brucht d websiite ca. 5 sekunde zum lade (rein Javascript execution). Das liht ned ahm Javascript, sondern am HTML rendering sowiit ih gseh ha. Ha suscht nah e Performance Trace gmacht wo mer in Chrome chan drii lade ahhghänkt. Isch betz speziell, dass ‘serviceCallbacks‘ array in vercherter reihefolg muen drii geh werde wies denne ahhzeigt wird... Wenn mer 2 Kollone het, aber rechts ke uuswahl, de chan mer au nüt uuswähle... Ja isch z erwarte aber isch au ih de Demo vorhande För mich isch ned immer klaar gsii, wenns nah meh optione unde oder obedraa het.

3.3 Länderauswahl-Komponente

Alternativ zu den bekannten HTML-Elementen datalist und select existiert eine weitere, spezielle Auswahlkomponente. Die Länderauswahl [16] ist das Resultat des vorausgegangenen Projekts. Diese vereinfacht die Selektion eines Landes in einer vorgegebenen Liste. Die Komponente ist jedoch nur auf den spezifischen Anwendungsfall – die Wahl eines Landes – getestet. Das Design, die Funktionen und die Anwendung unterscheiden sich aber von den oben genannten HTML-Elementen.

3.3.1 Design

Die Länderauswahl erscheint moderner als die alten HTML-Elemente. Die Komponente ist in geschlossenem Zustand durch einen immer sichtbaren Container (Abbildung 3.10) visualisiert. Darin befindet sich das gewählte Land. Ist die Länderauswahl geöffnet, erscheint ergänzend ein Listencontainer mit allen Ländern (Abbildung 3.11). Der Aufbau zeigt sich in einem Spaltendesign – Kontinente links und Länder rechts.

Das Design lässt sich einfacher und vielfältiger als bei den Standard-HTML-Elementen anpassen. Die einzelnen Subkomponenten besitzen Klassen, welche ein einfaches Umstyling ermöglichen. Funktionell zeigen sich sowohl Übereinstimmungen als auch Unterschiede.

3.3.2 Funktionen & Interaktionen

Ein grosser Unterschied findet sich in der Funktion des Kontinents. Durch die Selektion eines Kontinents reduzieren sich die zur Auswahl stehenden Länder. Ist kein spezifischer Kontinent ausgewählt, fällt die Selektion auf All. Die Komponente besitzt kein integriertes Formularfeld und benötigt deswegen in dieser Anwendung zusätzlichen Aufwand.

Die Länderauswahl bietet viele Interaktionen, welche sich bei den HTML-Elementen wiederfinden. Die folgende Tabelle 3.9 zeigt die Interaktionen, welche auf der Komponente implementiert sind.

Tabelle 3.9: Aktionen bei der Länderauswahl-Komponente

[*] Änderung der Selektion bewirkt Änderung des Highlights auf den selben Wert [*] Highlight und Cursor-Position besitzen selben Wert; kein Unterschied

[1] Suche: Erster mit dem eingegebenen Symbol passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ keine Aktion; Liste unverändert; nach Pause / Debounce-Ablauf ⇒ neue Suche

In der Bedienung existieren keine Browser-Inkonsistenzen. Die Interaktionen lehnen mehr an denen des Selects als denen der Datalist an. Zudem betreffen die Änderungen in der Länder-Spalte nur das Highlight [17] und nicht die Selektion. Die Selektion benötigt eine Bestätigung mit Enter oder Space.

3.3.3 Anwendung

Diese Komponente benötigt in der Anwendung kein HTML. Die Einbindung findet via JavaScript statt. Der folgende Code 3.5 zeigt einen möglichen Anwendungsfall.

const container = document.querySelector("#inputContainer");
if (null != container) {
    const countryList = [
        {
            country  : "Austria",
            continent: "Europe",
        },
        /* more country objects */
    ];
    const structureDetail = {
        value      : "",
        placeholder: "Choose a country",
        label      : "Country",
        name       : "country",
    };
    const structureMaster = {
        elementList   : countryList,
        sectionElement: { continent: "All" },
        focusObject   : {},
    };
    const detailController = ChoiceDetailController(structureDetail);
    const masterController = ChoiceMasterController("continent", "country")(structureMaster);
    const view = projectChoiceInput(detailController, masterController, "countryInput");
    container.append(...view);
}

Wie im Code 3.5 ersichtlich, sind mehrere Zeilen für die Erstellung der Komponente notwendig. Zudem befindet sich die Länderauswahl noch im experimentellen Status. Wie das Unterkapitel Future Features aus dem Bericht [18] der Vorarbeit beschreibt, gibt es noch Verbesserungspotenzial in der Implementation. Da diese Komponente noch nicht lange existiert, ist sie noch in keinem realen Anwendungsfall im Einsatz.

[16] (Marti und Burki, 2024) [17] Die Länderauswahl unterscheidet nicht zwischen Highlight und Cursor-Position. [18] (Marti und Burki, 2024)

4.6 Performance

Mit der Kenntnis des Rendering-Prozesses einer Webseite lässt sich eine gute Performance umsetzen. Dieser Ablauf ist im Kapitel Hintergrund unter Rendering-Prozess genau beschrieben. Die folgende Abbildung 4.14 zeigt die Kernelemente des Prozesses nochmals im Überblick.

Zur Auffrischung die wichtigsten Punkte nochmals: Der Browser kann die Webseite maximal 60 Mal pro Sekunde neu zeichnen. Änderungen am DOM und am CSSOM (Abbildung 4.14) lösen das Rendern aus.

Deswegen müssen viele kleine Änderungen ausserhalb des Browser-DOMs [6] (Abbildung 4.14 rechts) – am besten in einem sogenannten Shadow-DOM – geschehen. Ein Shadow-DOM ist ein Teilbaum, welcher nicht am Browser-DOM angehängt ist. Für einen reibungslosen Ablauf ist es sinnvoll, die Änderungen nach dem Abhängen des Elternknotens zu vollziehen. Nach den Änderungen ist der Teilbaum wieder an den gewünschten Ort einzuhängen.

const addAllOptions = (options) => {
    const placeHolder = createHolder();
    columnView.replaceWith(placeHolder);
    if (options.length > 50) {
        // same work as else but async
    } else {
        options.forEach((option) => {
            optionsController.addOption(option);
        });
        updateScrollbar(columnView);
        placeHolder.replaceWith(columnView);
    }
};

Code 4.10 ist eine Stelle, die diese Technik verwendet. Das Anzeigen eines Platzhalters mit einem Lade-Indikator an der Ursprungsstelle bewirkt, dass der Nutzer ein Feedback erhält. Sobald der Spalten-Container abgekoppelt ist, lädt die Funktion die Optionen in den Shadow-DOM. Nach Abschluss ersetzt sich der Lade-Indikator der originalen Stelle im Renderbaum durch den Container mit den neuen Elementen.

Weiterhin ist darauf zu achten, dass CSS-Klassen [7] an Stelle von Inline-Styles [8] ihre Verwendung finden. Die Selektoren sollten hierarchisch möglichst flach und nicht verschachtelt sein. Wenn es die Situation erlaubt, ist es besser, nicht mit innerHTML zu arbeiten. In diesem Projekt ist es für die Anzeige der Label jedoch nötig, innerHTML zu nutzen. Dies liegt daran, dass ein Label auch ein Bild enthalten kann. Generell verwendet die neue Auswahlkomponente keine Inline-Styles. Die einzige Ausnahme betrifft das verborgene Eingabefeld. Durch den Code 4.11 sind die Properties vor dem einfachen Überschreiben [9] geschützt.

inputElement.setAttribute(
    "style", "all:            unset       !important; " +
             "z-index:        -1          !important; " +
             "position:       absolute    !important; " +
             "inset:          5px         !important; " +
             "color:          transparent !important; " +
             "pointer-events: none        !important; "
);

Die Regeln in Code4.11 sorgen dafür, dass das Input-Feld sowohl transparent als auch resettet ist. Zudem befindet es sich im Hintergrund und besitzt dieselbe Grösse wie der Container mit dem ausgewählten Wert.

4.6.1 Performance-Vergleich

Durch die Anpassungen der Performance-Optimierung verschnellert sich die Ladezeit bei grossen Datenmengen enorm. Die Testseite enthält vier existierende und vier neue Auswahlkomponenten mit denselben Inhalten wie je eine der existierenden. Je eine der Selects enthält eine grosse Datenmenge von über 4'000 Werten. Die folgenden zwei Bilder 4.15 und 4.16 zeigen die Messung während des Seitenaufbaus.

Die Grafik 4.15 zeigt die mit über 5 Sekunden (rechts unten in Blau) lange Ladedauer der früheren Version. Die Implementation führte sehr viele Aktionen auf dem Renderbaum aus. Die lange Wartezeit bestätigten mehrere Feedbacks der Nutzer – mehr dazu im Kapitel User-Tests.

Ein Refactoring der früheren Implementation führt zur Auslagerung der aufwendigen Arbeiten auf den Shadow-DOM. Dadurch verkürzt sich der Ladevorgang um vier bis fünf Sekunden auf knapp 0.4 Sekunden (Abbildung 4.16 rechts unten in Blau). Der Vergleich zwischen Abbildung 4.15 und 4.16 zeigt, dass die Seite um Faktor 13 schneller lädt. Feedbacks zu den durchgeführten User-Tests mit Programmierern wie auch Endnutzern sowie manuelle Tests sind im nachfolgenden Kapitel aufgeführt.

[6] Im Renderbaum verwendeter und im Browser angezeigter DOM [7] (Ofoegbu, 2023) [8] Offizieller Begriff: Element attached style ⇒ Styles direkt im HTML-Element mit Attribut style definiert [9] !important nicht verwenden

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

Aktuelle Browser: Edge: Version 127 (Windows) Chrome: Version 127 (Windows / Mac) Firefox: Version 128 (Windows / Mac) Safari: Version 17.5 (Mac)

ARIA-Rolle: Accessible Rich Internet Applications Role. Sie definiert die Bezeichnung oder Funktion eines HTML-Elements. Sie dient als Markierung für Struktur und erweitert die Bedienbarkeit für u. a. Screenreader.

Ausgrauen: Das Element erscheint in Grautönen mit eher schwachem Kontrast.

Client-Side: Direkt im Browser. Die Aktionen sehen den Server nie und bleiben im Browser. Der Code ist direkt auf der HTML-Seite eingebunden. In Zusam- menhang mit Formularen erfährt der Server nichts von der Client-Side-Validierung.

Cursor-Position: In beschrieben.

Detail-View: In beschrieben.

Digital Native: Personen, die in der digitalen Welt aufgewachsen sind. Sie haben bereit in jungen Jahren Kontakt mit Computern und dem Internet.

Do-Nothing-Implementation: Implementation, welche als Stellvertreter – z. B. beim Null-Object-Pattern – dient. Eine Funktion mit einer solchen Implementation führt nichts aus und hat keine Seiteneffekte.

Dropdown-Komponente: Synonym für Auswahlkomponente.

Endanwender: Ein Nutzer, der die neue Komponente in einer Webanwendung ausfüllt.

Fokus: In beschrieben.

Highlight: In beschrieben.

Hovern: Mit der Maus über ein Element fahren.

Immutable: Unveränderbar. Objekte sind nicht überschreibbar.

Kategorie: Gruppierung der Optionen. Das Selektieren einer Kategorie in einer SelectComponent reduziert die Anzahl der Optionen. Die Komponente zeigt nur noch Optionen an, welche der Kategorie / Gruppe zugewiesen sind.

KISS: Keep it Simple, Stupid! Ein Prinzip der Programmierung, in welcher alles möglichst einfach zu halten ist. Einfache und kurze Codestücke minimieren das Risiko von Fehlern und Unverständlichkeiten.

Master-Detail-View: In beschrieben.

Multiselect: Auswahlkomponente (HTML select Element), bei welcher mehrere Werte selektierbar sind. Bei der Selektion einer zweiten Option hebt sich die vorherige Auswahl nicht auf. Auf Desktop-Browsern muss jedoch die passende Taste bei der Auswahl gedrückt sein, damit sich die Selektion erweitert.

Regex Regular: Expression. Beschreibt eine Zeichenkette. Syntaktische Regeln helfen bei der Verarbeitung von Texten.

Separation of Concern: Ein Prinzip, welches in der Programmierung beim Aufteilen eines Pro- grammes zur Anwendung kommt. Jede Komponente besitzt nur eine Aufgabe. Dadurch entsteht ein modularer Aufbau.

Single-Select: Auswahlkomponente (HTML select-Element), bei welchem nur ein Wert selektierbar ist. Bei der Selektion einer zweiten Option hebt sich die vorherige Auswahl auf.

Spiegelstrich: Ein Strich, welcher sich auf der linken Seite eines Elements bzw. einer Option befindet. Der Strich ist vertikal und dient zum Hervorheben des Elements.

Togglen: Auf- bzw. zuklappen des Popovers bzw. des Listencontainers.

Triggern: Auslösen eines Events.

UI/UX-Design: Design der Benutzeroberfläche und der Benutzererfahrung.

Workaround: Alternativer Code, wenn der Ursprüngliche nicht funktioniert. Eine Möglichkeit, ein Problem zu umgehen.

* Tabellen-Fussnote: Bemerkung gilt für die ganze Tabelle.

[x]: Fussnote kommt jeweils nach Tabelle oder Ende Seite.

Dev, F. (2020). Webpage Rendering: How It Works + Tips on Optimization [, Gesehen 19/07/2024].

contributors, M. (2023). option: The HTML Option element [, Gesehen 09/04/2024].

Ofoegbu, J. (2023). Best Practices for Efficient DOM Manipulation in JavaScript [, Gesehen 03/07/2024].

contributors, M. (2024a). datalist: The HTML Data List element [, Gesehen 09/04/2024].

contributors, M. (2024b). input: The Input (Form Input) element [, Gesehen 09/04/2024].

contributors, M. (2024c). select: The HTML Select element [, Gesehen 09/04/2024].

GeeksforGeeks. (2024). Null Object Design Pattern [, Gesehen 09/06/2024].

König, P. D. (2024). Projector Pattern [, Gesehen 09/06/2024].

Kumar, S. (2024). Decorator Design Pattern [, Gesehen 09/06/2024].

Marti, R., & Burki, L. (2024). Auswahlkomponente für das WebUI Toolkit Kolibri [, Gesehen 19/07/2024].

Ola & Markus. (2024a). Chromium-based Browsers [, Gesehen 21/04/2024].

Ola & Markus. (2024b). Firefox-based Browsers [, Gesehen 21/04/2024].

Wikipedia. (2024a). Blink (browser engine) [, Gesehen 28/04/2024].

Wikipedia. (2024b). WebKit [, Gesehen 30/06/2024].

Die in Kapitel beschriebenen Komponenten Select und Datalist kommen auf vielen Webseiten zur Anwendung. Das Auswählen eines Wertes aus einer vorgegebenen Menge ist mit diesen Elementen ineffizient und unästhetisch. Die in der Vorarbeit erstellte Länderauswahl löst das Problem nur für diesen einen spezifischen Anwendungsfall. Die neue SelectComponent baut auf der Länderauswahl auf, ist jedoch generalisiert. Sie lässt sich mit unterschiedlichsten Werten und Inhalten anwenden. Zudem ist der Code strukturiert aufgebaut. Dabei spielt es keine Rolle, welcher Konstruktor bzw. welche Art der Datenübergabe zur Anwendung kommt.

Die Datalist und das Select zeigen sowohl im UI als auch in der Interaktion einige Inkonsistenzen auf. Die Darstellung lässt sich mit den wenigen Stylingmöglichkeiten der HTML-Elemente teilweise beheben. Richtig unangenehm gestaltet sich die Anwendung dieser Auswahlkomponenten bei einer grossen, aber doch begrenzten Menge von Optionen. Eine saubere Integration in eine konsistent designte Webseite ist jedoch nicht möglich. Der Container mit den Werten lässt sich bei beiden Elementen nicht umgestalten und zerstört das Bild des abgestimmten Designs. Die Lösungen von Frameworks und Libraries blasen eine ansonsten schlanke Codebasis unnötig auf. Zudem bieten diese Komponenten häufig zu viele Funktionen an, welche die Anwendung verkomplizieren.

An diesem Punkt bietet Kolibri mit der SelectComponent eine konsistente und anpassbare Auswahlkomponente – ohne externe Abhängigkeiten – an. Das Konsistenzproblem ist durch ein klar gestaltetes Design gelöst. Die Implementation ist auf den gängisten Browsern Edge (127), Chrome (127), Firefox (128) und Safari (17.5) auf Desktop getestet. User-Tests mit Endnutzern zeigen, dass die Komponente dessen Bedürfnisse abdeckt und die Auswahl vereinfacht. Der modulare Aufbau ermöglicht eine hohe Wiederverwendbarkeit. Die Subkomponente ColumnOptionsComponent kann für ein Einsatzgebiet ausserhalb der Auswahlkomponente zur Anwendung kommen. Eine mögliche Verwendung kann bei einer Tabellenansicht sein. Ein weiterer Vorteil der einzelnen Komponenten ist, dass andere Projektoren zur Visualisierung zum Einsatz kommen können.

Diese Arbeit ist zeitlich und personell begrenzt. Deswegen bietet die Komponente nur einen Projektor für die Auswahlkomponente. Die spät durchgeführten User-Tests mit Programmierern führen dazu, dass sich nach den Verbesserungen keine zusätzliche Prüfung mehr durchführen lässt. Diese ist als erstes Future Feature im nachfolgenden Kapitel genauer beschrieben.

5.1 Future Features

Die Zukunft der zwei entstandenen SelectComponents zeigt sich sehr vielfältig. Durch die modulare Struktur vereinfacht sich die Erweiterung, indem einzelne Komponenten wie Projektoren austauschbar sind. Nachfolgend sind mögliche Verbesserungen und Features aufgelistet.

5.1.1 Weitergehende User Tests und Nutzerbefragungen

Die aus den Feedbacks der Programmierer entstandene SelectComponent sollte sich weiteren Tests mit Entwicklern stellen. Dies garantiert eine gut verständliche Dokumentation und effiziente Einbindung in den Code. Allenfalls lassen sich weitere Bugs aufdecken. Die weiteren Tests bieten die Möglichkeit, einen Vergleich zu den bereits durchgeführten Tests zu ziehen. Spezifische Fragen können die Vereinfachung der Anwendung beweisen oder widerlegen.

Die Anzahl der Personen der Testgruppe massiv zu erhöhen, führt zu mehr Feedback. Gewisse Interaktionen der Nutzer können möglicherweise auf bisher unentdeckte Probleme hinweisen. Diese lassen sich in einem weiteren Schritt beheben.

Eine Umfrage bei den Endanwendern weist auf bisher unbekannte Wünsche hin. Durch eine grosse Diversität beim Hintergrundwissen der Befragten entstehen neue Designansätze. Aus den Feedbacks lassen sich neue Projektoren – ob UI oder Interaktion – designen und umsetzen.

5.1.2 Weitere UI-Projektoren

Die während des Design-Prozesses entstandenen Prototypen bieten sich als Grundlage für neue UI-Projektoren [1] an. Aus diesen Designskizzen lassen sich in Figma ausgearbeitete Prototypen erstellen. Diese finden sich in der späteren Implementation zu einzelnen Projektoren wieder.

Weitere Projektoren könnten den gleichen Aufbau besitzen, aber mit alternativen Design-Implementationen ausgestattet sein. Dabei zeigen sich die Unterschiede beispielsweise in der Visualisierung des Highlights, der Cursor-Position oder der Selektion. Das Design kann jedoch wie beim Darkmode die komplette Komponente betreffen.

Statt einer Spalten-Darstellung visualisiert sich eine Idee als Zeilen-Darstellung (Abbildung 5.1). Die Kategorien zeigen initial nur die ausgewählte Option in einer Zeile an. Die ValueOption stellt die Werte in einer normalen Spalte dar. Beim Eintreten [2] in eine Kategorie ändert die Darstellung der aktiven Zeile in ein Rad (Mitte Abbildung 5.1). Sobald das Highlight bzw. die Cursor Position die Kategorie-Zeile verlässt, minimiert sich die Visualisierung zurück auf den selektierten Wert. Nach dem Erstellen eines Figma-Prototypen findet sich in dieser Idee ein neuer UI-Projektor wieder.

Die entstandenen wie auch zukünftige UI-Projektoren lassen sich mit unterschiedlichen Interaktionen verbinden. Dabei ist es hilfreich, verschiedene Interaktions-Projektoren [3] zu bieten.

5.1.3 Weitere Interaktionsprojektoren

Neue UI-Projektoren lassen sich nicht ausnahmslos mit den bestehenden Tastatur-Interaktionen kombinieren. Zudem ist nicht in jeder Situation erwünscht, dass die Cursor-Position die Selektion beeinflusst. Weitere Projektoren können eventuell neue UI-Projektor-spezifische Interaktionen bieten.

Ein Interaktionsprojektor kann das Auswahlkomponentebezogene Undo und Redo enthalten. Diese Funktion bietet an, eine geänderte Auswahl rückgängig zu machen oder zu wiederholen.

5.1.4 Spezifische Auswahlkomponenten und Erweiterungen

Zukünftig besteht die Möglichkeit, Auswahlkomponenten für spezielle Anwendungsfälle zu erstellen. Ein altbekanntes Beispiel ist die Auswahl eines Datums mit Tag, Monat und Jahr. Dabei kann weitere Logik zur Kontrolle der möglichen Werte zum Einsatz kommen.

Das Erweitern der Multiselect-Funktionalität führt die Anpassung mehrerer Subkomponenten mit sich. Es betrifft die Implementation von der SelectComponent bis hin zu der ColumnOptionsComponent. Eine mögliche neue Single-Select-Komponente bietet die Funktionalität, mehrere Kategorien auswählen zu können. Hierbei ist zu unterscheiden, ob die ausgewählten Kategorien als AND- oder OR-Verknüpfung zu verstehen sind.

5.1.5 Performance verbessern und Datenmenge erhöhen

Die SelectComponent garantiert bis 5'000 Werte eine annehmbare [4] Ladezeit. Diese Performance lässt sich weiter optimieren. Zudem führen diese Verbesserungen dazu, dass sich eine noch höhere Anzahl Optionen anwenden lässt. Eine Kombination der Auswahlkomponente mit der Lazy Table des Kolibri ermöglicht eine optimierte Performance. Denn die Lazy Table kann eine Datenmenge von über 100'000 Werten verwalten.

5.1.6 Accessability verbessern

Die entstandene Auswahlkomponente ist nur für nicht beeinträchtigte Menschen optimiert. Zukünftig ist die Komponente noch für Screenreader und somit für Blinde zu ergänzen. Die getroffenen Styles benötigen ein Testing mit Sehbeeinträchtigten, um die Accessability garantieren zu können. Dazu zählt zum Beispiel die bekannte Rot-Grün-Schwäche.

5.1.7 Abschliessende Bemerkungen

All diese Erweiterungen und Verbesserungen zielen darauf ab, die Auswahlkomponente für alle Endnutzer zugänglich zu machen. Sie ermöglichen eine angenehme Benutzung. Zudem soll die SelectComponent einfach in jeden bestehenden JavaScript-Code einzubinden sein. Anschliessend an diese Arbeit steht die Integration in das Toolkit Kolibri an.

[1] Projektoren, die nur die View generieren (ohne Tastatur-Interaktion) [2] Wechsel der Cursor-Position in die Kategorie oder ein Klick auf die Kategorie [3] Projektoren, die nur die Tastatur-Interaktion definieren [4] Ladezeit < 500 ms, bis die Webseite fertig geladen is

4.7 Testing

Verschiedene Arten von Tests garantieren die Korrektheit der einzelnen Funktionen und Komponenten. In manuellen Tests findet die Kontrolle der Konsistenz im UI und der Interaktion statt. Die automatisierten Code-Tests stellen sicher, dass das Aufrufen der gebotenen Funktionalität die gewünschten Änderungen ausführt. Komponenten, welche für die Erstellung des UI zuständig sind, prüfen sowohl die Existenz von Elementen als auch das Triggern der Events. Die User-Tests mit unterschiedlichen Personen gewährleisten eine gute Nutzerzufriedenheit sowie die intuitive Anwendung durch Programmierer. Die Auswahl der Nutzer fällt auf eine grosse Vielfalt, damit die Resultate unterschiedliche Sichtweisen einbeziehen.

4.7.1 Manuelle Tests

Manuell durchgeführte Tests – in den vier aktuellen Browsern Edge, Chrome, Firefox und Safari – beweisen die Konsistenz der neuen Komponente. Als Beispiel dient die SelectComponent mit drei Spalten (Abbildung 4.17).

Diese Komponente unterzieht sich sowohl einer Prüfung auf Mac als auch Windows. In den Einstellungen sind in einem ersten Durchgang der Light-Mode und in einem Zweiten das Dark-Theme gespeichert. Die genaue Kombination zwischen Browsern und Betriebssystemen ist wie folgt:

• Mac bzw. OSX: Chrome (127), Firefox (128), Safari (17.5)

• Windows (10/11): Chrome (127), Firefox (128), Edge (127)

Die SelectComponent aus Abbildung 4.17 zeigt sich in den aufgezählten Kombinationen grundlegend konsistent. Es existiert nur eine kleine Abweichung. Die Scrollbars auf Windows (Abbildung 4.18) besitzen auf der rechten Seite einen grösseren Abstand als auf Mac (Abbildung 4.17).

Dabei spielt der Browser keine Rolle. Bei den Interaktionen verhält sich die Komponente ebenfalls konsistent über alle Browser. Die einzige Abweichung findet sich beim Ausführen von Aktionen. Auf Windows-PCs mit Nummernpad funktionieren die PageUp-, PageDown-, Home- und End-Keys [10] auf der Tastatur. Auf OSX verlangen die oben genannten Tasten und Delete eine Tastenkombination mit der fn-Taste.

Zusätzlich zu den im Vorfeld vereinbarten Systemen und Browsern finden noch folgende weitere Prüfungen statt:

• Linux (24 LTS): Firefox (125), Chromium (127)

• iOS (Simulator): Safari (17.2)

• Android (Pixel Simulator): Chrome (124)

Diese Tests beweisen, dass die Komponente über die geforderten Umgebungen hinaus funktioniert. Firefox zeigt die SelectComponent auf Linux wie auf OSX an. Speziell die Scrollbar in den Spalten ist rechts anliegend. In Chromium besteht ein Abstand von der Scrollbar zum rechten Rand. Ansonsten ist die Komponente konsistent im UI und der Interaktion.

Die mobilen Geräte öffnen keine virtuelle Tastatur. Deswegen sind nur Touch-Interaktionen möglich. Zu diesen Bedienungsmöglichkeiten gehören das Scrollen und das Klicken. Auf iOS und auf Android stellen die Browser das UI meist konsistent – wie auf dem Desktop Safari – dar. Die Scrollbar ist anliegend an der rechten Seite. Das Highlight und die Cursor-Position haben keinen weiteren Nutzen. Die beiden Zustände bewegen sich mit der Selektion mit. Das Highlight verschwindet, wenn das Touch ausserhalb einer Option erfolgt. Die einzige Inkonsistenz auf iOS zeigt sich beim Klick ausserhalb der SelectComponent. Anders als Safari auf Desktop schliesst diese Interaktion den Container nicht. Wenn der Klick auf der X einen bereits selektierten Wert löscht, bleibt der Container ebenfalls offen. Auf dem Pixel Chrome reagiert der Klick auf die Detail-Ansicht abweichend. Ist das Popover bereits geöffnet, schliesst die Interaktion dieses und öffnet es gleich wieder. Trifft die Touch-Geste das X bei einer bereits getroffenen Selektion, passiert dieser Fehler nicht.

Folgende veraltete Browser finden sich in oberflächlichen Tests wieder:

• Mac: Firefox Version 123 ⇒ vor Popover-API

• iOS: Safari Version 16.7 ⇒ vor Popover-API

In veralteten Browsern ist die SelectComponent mit leichten Einbussen nutzbar. Der aufgelistete Firefox und auch Safari öffnen die neue Komponente normal. Im offenen Zustand ist das Toggle-Icon dasselbe wie im geschlossenen. Ein Klick ausserhalb der Komponente schliesst den Listencontainer nicht. Daher existiert die Inkonsistenz, dass mehrere Auswahlkomponenten parallel geöffnet sein können. Dies ermöglicht eine unerwünschte Darstellung von überschneidenden Listencontainer. Das restliche UI zeigt kaum Abweichungen. Die Interaktionen funktionieren alle wie in den aktuellen Browserversionen. Gewisse Zustände sind im Controller nicht konsistent mitgeführt. Ohne das Popover reagiert das Toggle-Event nicht.

Die breite Abdeckung der manuellen Tests beweist bei den anfangs genannten Browsern eine konsistente Darstellung und Interaktion. Zudem sind Nutzer mit leicht veralteten Browsern nur leicht beeinträchtigt. Eine gewisse Bedienbarkeit ist möglich.

4.7.2 Automatisierte Tests

Tests für Komponenten der SelectComponent beweisen die Stabilität des Codes. Generell befinden sich die einzelnen Komponenten nach Separation of Concern je in einer eigenen Testeinheit. Dies garantiert das schnelle Auffinden von Bugs und unerwünschtem Verhalten direkt in einer Komponente. Auf der Abbildung 4.19 ist zu sehen, dass eine breite Palette an Kontrollen stattfindet und sauber durchläuft.

Die oberen vier Zeilen auf Abbildung 4.19 zeigen Tests zu den Bausteinen aus Abbildung 4.12. Diese decken den Level der Options bis zur Column ab. Die ersten zwei Testsuites kümmern sich genauer um die Korrektheit der Models und Controller. Dabei besteht das erste File aus den Tests der Typen ValueOption und CategoryOption. Dazu gesellen sich Prüfungen der Komponenten OptionsModel und SelectedOptionModel. Der OptionsController und der SelectedOptionController finden sich in einer gemeinsamen Test-Datei wieder. Der projectColumnOptionsView-Test deckt die Kontrolle der Bindings und die Existenz der View-Elemente ab. Die Korrektheit des Zusammenspiels zwischen Projektor und Controller findet sich im ColumnOptionsComponent-Testing wieder.

Die restlichen Testbibliotheken decken die Korrektheit der auf Abbildung 4.13 sichtbaren Bausteine ab. Diese drei Dateien prüfen das Zusammenspiel der Columns sowie der allgemeinen Komponentenfunktionalitäten. In einzelnen Units prüft die SelectController-Test-Suite verschiedene Varianten der Anwendung. Im projectSelectViews-Test befinden sich – wie bereits bei der Column – die Prüfungen der Korrektheit der View-Elemente und Bindings. Die letzte Datei kümmert sich um die Kontrolle der SelectComponentByCallbacks und SelectComponentByTableValues. Die breite Abdeckung der Einzelteile garantiert die korrekte Funktion der neuen Komponente. Die Tests im nachfolgenden Kapitel sind sowohl für eine gute Anwendbarkeit im Code als auch für eine angenehme Benutzung der Auswahlkomponente im Browser notwendig.

4.7.3 User-Tests

4.7.3.1 Tests Programmierer

Die Probanden dieser User-Tests sind alle Studenten der FHNW. Deswegen haben die Testpersonen ein ähnliches Hintergrundwissen wie Estrid. Die Vorlieben der Probanden sind unterschiedlich und decken dadurch die Vorgaben durch die Persona ab.

Im Rahmen der Evaluierung der neuen Dropdown-Komponente sind Programmierer dazu eingeladen, spezifische Aufgaben zu erfüllen. Diese Aufgaben umfassen die Implementierung der Dropdown-Komponente in eine bestehende Webanwendung. Für den Erhalt eines möglichst realistischen Feedbacks sind die Teilnehmer gebeten, nach der Implementierung eine Google-Umfrage auszufüllen.

Insgesamt haben 9 Studenten an dem User-Test teilgenommen und die Aufgaben versucht zu lösen. Die Grafiken 4.20 und 4.21 zeigen, dass die Hintergründe der Probanden breit gefächert sind. Zwei der Testpersonen konnten die Aufgabe nicht korrekt lösen.

Nach der systematischen Erfassung der Umfrage-Rückmeldungen erfolgt die Analyse dieser. Programmierer bewerten die Komponente als benutzerfreundlich und ästhetisch ansprechend.

Personen mit nur geringen JavaScript-Kenntnissen fällt es schwer, die Komponente intuitiv zu verwenden. Die Testperson ohne jegliche JavaScript-Kenntnisse konnte die Aufgaben nicht korrekt lösen. Für einige Testnutzer ist die Verwendung von Callbacks als Service-Funktionen eine Stolperfalle.

Die Ergebnisse der Tests liefern wertvolle Erkenntnisse, welche zur Verbesserung der Dokumentation beitragen. Die Überarbeitung der Dokumentation wie auch die der Rückgabe der Komponente heben die Kritik auf. Die Erstellung des zweiten Konstruktors mit einer Tabelle von Werten ermöglicht das Umgehen des Stolpersteins der Callbacks.

Dokumentation & Return-Wert: Das JSDoc der SelectComponent benötigt eine detailliertere Beschreibung des Return-Arrays. Die Elemente erklären sich erst in den Anwendungsbeispielen. Tester mussten nach der Beschreibung suchen. Die Dokumentation erweist sich als verwirrend. Wenn sich die Komponente nicht im Projektordner befindet, erscheinen keine Typen-Informationen bzw. Dokumentationshinweise. numberOfColumns: Ein Tester versuchte den Parameter falsch anzuwenden, um Fehler aufzudecken. Ist selectAttributes ⇒ numberOfColumns nötig? selectAttributes: Der Parameter ist intuitiv anwendbar. Label, Name und numberOfColumns sind klar. Callback: Der Parameter ist nicht intuitiv anwendbar. Callbacks sind nicht allen Programmierern klar in der Anwendung bzw. bekannt. Es ist speziell, dass – im Gegensatz zum UI – das serviceCallbacks-Array in umgekehrter Reihenfolge einzugeben ist. Navigation: Die Tastaturnavigation ist nicht ideal. Die Verwendung der Tastatur zum Eingrenzen möglicher Kategorien/Werte – unscharfe Suche [11] – wäre eine Möglichkeit. Sonst dauert die Suche länger als in den existierenden Komponenten. Automatisches Schliessen: Automatisches Schliessen der Komponente nach der Auswahl wäre praktisch. Performance: Die Performance ist zu langsam. Beim Implementieren von Task 2.2 benötigt die Webseite ca. 5 Sekunden zum Laden. Dies liegt – soweit ersichtlich – am HTML-Rendering. Leere Spalten: Wenn zwei Kolonnen sichtbar sind, aber rechts nichts selektierbar ist. Das ist ein zu erwartender Fall, aber nicht ideal für die Demo.

4.7.3.2 Endanwender

Im Rahmen der Usability-Tests erfolgt eine Untersuchung der Benutzerfreundlichkeit der neuen Dropdown-Komponente. Die Komponente nutzt eine mehrstufige Filterung. Dies erleichtert die Navigation innerhalb langer Listen. Die Probanden durchlaufen zwei Aufgaben. Diese zielen auf die Evaluation der Effizienz und Anwenderfreundlichkeit dieser Dropdown-Funktion ab.

Aufgabenbeschreibung :

1. Jahresauswahl: Testpersonen wählen das gewünschte Jahr aus einer Liste aus. Der Prozess beinhaltet die Vorauswahl eines Jahrzehnts, gefolgt von der Auswahl des spezifischen Jahres. Diese Aufgabe dient der Bewertung der Benutzerfreundlichkeit und Effizienz der Filteroption.

2. Stadtauswahl: Die Testpersonen wählen eine spezifische Stadt aus einer dreispaltigen Dropdown-Liste. Die Auswahl erfolgt schrittweise: Beginnend mit dem Kontinent, gefolgt vom Land, und schliesslich der Stadt. Der Fokus liegt hierbei auf der Bedienbarkeit und der Wirksamkeit der Filterfunktion.

Feedback der Testpersonen:

• Allgemeine Benutzerfreundlichkeit:

  • Robert (Junger Alltagsbenutzer, Digital Native): Empfindet die Dropdown-Menüführung als intuitiv und zügig bedienbar. Sowohl das Jahr als auch die Stadt lassen sich mühelos finden.

  • Luca (Junger Alltagsbenutzer): Wenn das Resultat bereits sichtbar ist, kann die Filterfunktion ausgelassen werden. Die Vorauswahl ist optional und kann ignoriert werden, wenn es nicht notwendig ist.

  • Sara (Semi-aufmerksam, nicht so schnell auf der Tastatur): Beginnt mit Schwierigkeiten in der Dreispaltenansicht. Nach kurzer Einarbeitung findet sie die Filteroptionen jedoch nützlich.

  • Nick (Alltagsbenutzer/Student): Zeigt sich zufrieden mit der Handha- bung. Er hebt hervor, dass die Filterfunktion das Auffinden des Jahres beschleunigt.

  • Reto (Unternehmer, über 60 Jahre alt): Erlebt die Menüführung als etwas komplex, besonders die dreispaltige Filterung. Nach einer Eingewöhnungszeit erkennt er jedoch die Vorteile gegenüber einer langen Liste.

  • Regula (Lehrerin, über 60 Jahre alt): Findet die Navigation schneller, braucht jedoch Zeit, um sich daran zu gewöhnen.

• Funktionalität der Filteroptionen:

  • Robert: Schätzt die Filteroptionen als sehr nützlich ein. Das Finden spezifischer Jahre und Städte gelingt schneller als erwartet.

  • Luca: Die optionale Vorselektion hat bei Nichtverwendung dieser die Auswahl nicht erschwert. Bei der Nutzung des Filters hat es die Auswahl erleichtert.

  • Sara: Nutzt zuerst nicht alle Filter bei der Stadtauswahl. Somit scrollt sie ein bisschen mehr.

  • Nick: Die Möglichkeit, zuerst das Jahrzehnt und anschliessend das spezifische Jahr auszuwählen, beschleunigt den Prozess erheblich.

  • Reto: Ist unsicher bei der Nutzung der Filter. Nach einiger Zeit erkennt er jedoch dessen Vorteil.

  • Regula: Findet die Navigation schneller, braucht jedoch Zeit, um sich daran zu gewöhnen.

Visuelle Gestaltung und Übersichtlichkeit:

• Robert: Beurteilt das Design als klar und ansprechend. Die Struktur erscheint ihm logisch und nachvollziehbar.

• Luca: Design ist unaufgeregt. Es ist nicht zu aufdringlich, aber klar.

• Sara: Findet die visuelle Gestaltung in Ordnung. Sie vermisst jedoch eine deutlichere Hervorhebung aktiver Filteroptionen.

• Nick: Ist zufrieden mit der Übersichtlichkeit und der klaren Struktur des Dropdown-Menüs.

• Reto: Besonders in der Dreispaltenansicht findet er das Design zunächst verwirrend. Er gewöhnt sich jedoch daran.

• Regula: Empfindet das Design klar gestaltet.

Intuitivität der Bedienung:

• Robert: Erlebt die Bedienung als sehr intuitiv und benötigt keine weiteren Erklärungen.

• Luca: Findet es intuitiv.

• Sara: Muss sich an die Bedienung gewöhnen. Jedoch nach kurzer Zeit findet sie die Handhabung einfach.

• Nick: Empfindet die Bedienung als leicht nachvollziehbar und intuitiv.

• Reto: Hat anfänglich Schwierigkeiten und wünscht sich eine einfache Einführung.

• Regula: Verwendet die Navigation zu Beginn wie bei herkömmlichen Jahresauswahlmenüs.

Gesamtzufriedenheit:

• Robert: 10/10 – Sehr zufrieden, bewertet die Filteroptionen als hervorragend.

• Luca: 9/10 – Zufrieden, lediglich bei den Jahreszahlen wäre Weiterscrollen bei einer Falschauswahl praktisch.

• Sara: 7/10 – Zufrieden, dreispaltige Navigation ist ihr jedoch nicht so gängig.

• Nick: 9/10 – Zufrieden, bevorzugt diese Art der Auswahl.

• Reto: 8/10 – Zufrieden, jedoch mit anfänglichen Schwierigkeiten. Er mag speziell die schnelle Jahresauswahl.

• Regula: 8/10 – Brauchte zwar einen Bedienungshinweis, findet es jedoch super. Das Scrollen bei ihrem Jahrgang ist in anderen Dropdown Menüs nervenaufreibend.

Verbesserungsvorschläge:

• Robert: Hat keine weiteren Vorschläge.

• Luca: Es wäre praktisch, wenn die Jahreszahlen nach der Selektion der Dekade nicht verschwinden. Das Weiterscrollen sollte bei der Selektion des falschen Jahrzehnts noch möglich bleiben.

• Sara: Findet die dreispaltige Version nützlich. Aber leider müssen mehrere Spalten bearbeitet werden.

• Nick: Schlägt eine kurze Anleitung oder Hinweistext für Erstnutzer vor.

• Reto: Eventuell eine vereinfachte Variante mit weniger Informationen bei der Länderauswahl.

• Regula: Eventuell eine vereinfachte Variante mit weniger Informationen bei der Länderauswahl.

Der Usability-Test zeigt, dass die neue Dropdown-Komponente insgesamt beliebt ist. Besonders die Filteroptionen nach Jahrzehnten und Kontinenten erweisen sich als hilfreich. Einige Nutzer benötigen jedoch eine Eingewöhnungszeit, um sich an die Bedienung der mehrstufigen Auswahl zu gewöhnen.

4.7.3.3 Fazit

Die Entwicklung und die Implementierung der neuen Auswahlkomponente stellen eine Herausforderung dar. Dies ist durch eine strukturierte Vorgehensweise und kontinuierliche Verbesserungen erfolgreich umsetzbar. Die Usability-Tests mit Programmierern und Endanwendern liefern Einblicke in die Benutzerfreundlichkeit und Funktionalität der Komponente.

Wichtige Erkenntnisse und Erfolge: Design und Konsistenz: Die Nutzung des Kolibri-Designsystems ermöglicht eine konsistente und ansprechende Benutzererfahrung. Es ist wichtig, die Farbauswahl und den Kontrast anzupassen. Damit sind eine hohe Lesbarkeit sowie auch die Benutzerfreundlichkeit gewährleistet. Interaktion und Benutzerfreundlichkeit: Die neue Komponente bietet eine intuitive Bedienung sowohl für Maus- als auch für Tastaturbenutzer. Die Rückmeldungen aus den Tests zeigen, dass die Komponente nach einer kurzen Einarbeitungszeit gut verständlich und benutzerfreundlich ist. Die neue Dropdown-Komponente ermöglicht eine intuitive Bedienung. Diese findet sowohl bei Digital Natives als auch bei weniger geübten Nutzern Akzeptanz. Die mehrspaltigen Filteroptionen sind als besonders hilfreich hervorgehoben. Sie erleichtern die Navigation in umfangreichen Listen erheblich. Performance-Optimierungen: Durch gezielte Performance-Optimierungen – wie die Verwendung des Shadow-DOMs – reduziert sich die Ladezeit bei grossen Datenmengen erheblich. Dies trägt zu einer flüssigeren Benutzererfahrung bei. Design und Klarheit: Die visuelle Gestaltung der neuen Dropdown-Komponente bewerten die Testpersonen als klar und ansprechend. Besonders die logische Struktur und die unaufdringliche Präsentation tragen zu einer positiven Benutzererfahrung bei. Effizienzsteigerung: Die Möglichkeit, gezielt nach Jahrzehnten und Kontinenten zu filtern, beschleunigt den Auswahlprozess signifikant. Dies erkennen die Testpersonen als wesentlicher Vorteil gegenüber herkömmlichen, nicht gefilterten Dropdown-Menüs. Tastatur-Shortcuts nutzen nur zwei der Testpersonen. Eine breitere Nutzung dieser Funktion steigert die Effizienz der Bedienung weiter.

Verbesserungspotenziale: Dokumentation: Eine detailliertere Dokumentation der Rückgabewerte und der Verwendung der Komponente ist notwendig. Die Ausarbeitung des JSDoc vermeidet Missverständnisse und erleichtert die Einarbeitung. Dazu unterstützt eine Umgestaltung des Return-Werts die Verständlichkeit der Elemente. Interaktion: Die Implementierung einer automatischen Schliessfunktion nach der Auswahl eines Wertes ist als wünschenswert identifiziert. Eine verbesserte Tastaturnavigation ist ebenfalls erwünscht und findet in der verbesserten Implementation ihren Platz. Code-Komplexität: Die Reduzierung der Komplexität der Parameter vereinfacht die Komponente in der Verwendung. Die daraus resultierende Version der Komponente erhöht durch einen alternativen Konstruktor die Entwicklerfreundlichkeit. Einarbeitungszeit: Die meisten Nutzer empfinden die Komponente als benutzerfreundlich. Bei älteren Nutzern ist ein Bedarf nach einer kurzen Einführung in die Bedienung vorhanden. Weiterentwicklung: Die Tests zeigen, dass es sinnvoll sein könnte, eine Funktion zu integrieren, die eine flexiblere Navigation innerhalb der Dropdown-Menüs ermöglicht. Beispielsweise kann durch das Fortsetzen des Scrollens in Kategorien oder eine vereinfachte Variante für spezifische Nutzergruppen Abhilfe schaffen.

Die neue Auswahlkomponente erfüllt die Anforderungen an Konsistenz, Benutzerfreundlichkeit und Performance. Sie bietet gleichzeitig Raum für weitere Optimierungen. Gewisse Kritiken finden ihre Lösung in der neuen Version der Komponente. Die SelectComponent erfüllt durch die kontinuierliche Weiterentwicklung und Verbesserung die hohen Ansprüche moderner Webanwendungen.

[10] Gewisse Tastaturen besitzen die genannten Tasten doppelt – einmal im Nummernpad und einmal in der obersten Zeile [11] Elemente durch das Übereinstimmen von Zeichen oder einer Zeichenkette finden.

4.4 Patterns

In diesem Projekt finden sich einige Code-Patterns wieder. Die wichtigsten Patterns wie Null-Object, Projector und Decorator sind in den nachfolgenden Unterkapiteln genauer erläutert. Eine weitere Rolle spielt unter anderem die Master-Detail-View, welche bereits im Kapitel erläutert ist.. Zudem ist die Anwendung nicht typisch bzw. genau abgegrenzt. Die Implementation erhält durch die verwendeten Patterns eine Struktur und läuft stabiler.

4.4.1 Null-Object Pattern

Ein Pattern, welches im Verlauf der Arbeit eine wichtige Rolle eingenommen hat, ist das Null-Object-Pattern [2]. Null hat den Nachteil, dass alle Funktionsaufrufe zu Fehlern führen. Das Null-Object besteht aus vordefinierten Werten und besitzt für alle Funktionen eine \emph{Do-Nothing}-Implementation. Durch die Verwendung dieses speziellen Objekts entfällt eine ansonsten notwendige Nullwertprüfung. Zudem ist jedes erstellte Null-Object wertegleich.

Eine Null-Option ist notwendig, um eine Selektion zurücksetzen zu können. Die Verwendung des Null-Objects findet sich an mehreren Stellen des Codes wieder. Die Definition der angewendeten Null-Option zeigt der nachfolgende Code 4.6.

Mit dem Erhalt des Typs Option bietet die Konstante dieselbe Funktionalität wie die gewünschten Objekte. Der Codeausschnitt 4.6 befindet sich in der Datei optionsModel.js. Mehr zur Dateiaufteilung ist in den nächsten zwei Unterkapiteln zu lesen.

4.4.2 Projector Pattern

Das Projector-Pattern [3] basiert auf dem verbreiteten Model-View-Control-Pattern. Das Model verwaltet die dargestellten Daten. Zudem enthält die Komponente des Patterns die Geschäftslogik und verarbeitet die Regeln und Anfragen für die Daten. Ein Controller generiert privat gehaltene Modelle. Dabei stellt dieser nur die notwendigen Funktionen zur Verfügung. Diese Funktionen können Getter, Setter und Listener der observierten Modelle und Werte sein. Der Projektor bindet Datenmodelle über den Controller an die View. Auf der anderen Seite bindet sich die View an die Models. Aus den Bindings und den Daten generiert ein Projector die passende View. Die View ist passiv und hat keine Kenntnis der anderen Komponenten.

Diese Version zeigt noch viel Komplexität und duplizierenden Code in den einzelnen Funktionen. Eine genaue Analyse der Komponente zeigt, dass sich das Pattern zwei Mal anwenden lässt. Die neue Aufteilung ergibt die zwei folgenden Abbildungen 4.12 und 4.13. Die Implementation der dargestellten Diagramme resultiert aus einem Refactoring im grösseren Rahmen.

Die Anwendungskomponente einer Column findet sich als Bestandteil des zweiten Projector-Patterns wieder. Ein SelectController verwaltet eine bis mehrere ColumnOptionsComponents sowie ein Element für die Tastaturnavigation. Die sogenannte Cursor-Position verwendet im Hintergrund ebenfalls einen SelectedOptionController. Dieser ist derselbe wie in der Abbildung 4.12 und findet hier eine Wiederverwendung. Für die Definition der Bindings greifen die einzelnen Projektoren auf denselben Controller zu. Der Master-Detail-Aufbau der neuen Komponente findet sich in der Aufteilung der Projektoren wieder. Der Detail-Baustein kümmert sich um die aktuelle Auswahl und das Eingabefeld. Die Master-Komponente verwaltet alle Spalten mit den Kategorie- und Werte-Optionen sowie dessen Bindings. Eine weitere Funktion ist die Einbettung der beiden Projektoren in eine gemeinsame View. Auch diese Projector-Pattern-Anwendung schliesst mit einer Component – der SelectComponent – ab. Mehr zu dieser und der ColumnOptionsComponent steht im nächsten Kapitel.

4.4.3 Decorator Pattern

Ein Decorator [4] bietet zusätzliches Verhalten, ohne das originale Objekt zu verändern. Dabei lassen sich verschiedene Funktionen kombinieren. Dieses Pattern ermöglicht die Erstellung eines modularen und anpassbaren Codes. In diesem Projekt unterstützt es die Gestaltung und Erweiterung der Auswahlkomponente.

Wie im vorherigen Kapitel erwähnt, besteht die neue Komponente unter anderem aus zwei sogenannten Component-Bausteinen. Die Decorator sind in den Abbildungen 4.12 und 4.13 als Puzzle dargestellt. Diese Bestandteile kombinieren die Funktionalität des Controllers mit der Erstellung der View. Dadurch lässt sich die neue Komponente einfacher anwenden.

Ein weiterer Einsatzort ist in der Abbildung 4.13 zu sehen. Der SelectComponentByTableValues in Code 4.7 dekoriert die SelectComponentByCallbacks. Damit bietet die neue Komponente zwei verschiedene Möglichkeiten der Anwendung. Das nächste Kapitel geht genauer auf den Master-View-Bereich des SelectProjectors – Abbildung 4.13 – ein.

Datalist

P

Code

Select