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.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.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.

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.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.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 Master-Detail-Ansicht 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.

/** @private @returns { OptionType } */
const reset = () => {
    return Option(null, null);
};

/** @public @type { OptionType } */
const nullOption = reset();

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.

Dieses Pattern zeigte sich als eines der Wichtigsten für die Erstellung der neuen Komponente. In den folgenden Grafiken sind Models als Zylinder, Controller als Parallelogramm und Projectors als Oval dargestellt. Die Raute mit Option ist ein Datentyp, der über das gesamte Projekt seine Anwendung findet. Das starter.js beinhaltet alle Bestandteile, welche für eine Anwendung notwendig sind. Eine genauere Beschreibung des Puzzles folgt im Unterkapitel Decorator Pattern. Die erste Implementation, welche dieses Pattern verwendet, ist auf Abbildung 4.11 ersichtlich.

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.

Zum einen findet sich das Projector-Pattern in einer einzelnen Spalte in der Options-Liste wieder. Pro Kolonne existieren eine Auswahl und eine Menge von Optionen. Diese beiden Bestandteile besitzen je ein eigenes Model und einen eigenen Controller. Der Projektor generiert eine gemeinsame View und bindet diese an die beiden Controller. Bei einer Anwendung übernimmt die ColumnOptionsComponent die Verwaltung gewisser Bausteine. Mehr zu dem Baustein folgt im Kapitel Decorator Pattern.

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.

const SelectComponentByTableValues = (
    selectAttributes,
    optionsTable,
    sortColumnOptionsAlphabetical = false
) => {
    /* code for mapping between table and callbacks */
    const component = SelectComponentByCallbacks(selectAttributes, callbacks);
    return {
        ...component,
    };
};

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.

[2] (GeeksforGeeks, 2024) [3] (König, 2024) [4] (Kumar, 2024)

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

4.6 Performance

Mit der Kenntnis des Rendering-Prozesses einer Webseite lässt sich eine gute Performance umsetzen. Dieser Ablauf ist im Kapitel unter 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.

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.

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.

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.

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.