Dieses Kapitel bietet einen Einblick in die verwendeten Methoden, welche in der technischen Recherche auf dem Weg zur Auswahlkomponente Verwendung finden. Es beschreibt die im Konzept verwendeten LoFi- und HiFi-Prototypen, sowie das Refactoring, Dokumentieren des Codes sowie die angewendeten Patterns.
Ein Hilfsmittel, Ideen und Konzepte zu visualisieren, ist das Prototyping. Dies setzt sich aus Prototyp und Testing zusammen, welche gleichwertige Anwendung in dieser Methode finden. Die erarbeiteten Ansätze durch Nutzertests zu analysieren, ist ein wichtiger Bestandteil. Prototypen unterstützen die Entwicklung, um Anforderungen bildlich darzustellen. Alternative Entwürfe vermeiden eine frühzeitige Festlegung auf eine spezifische Idee. Usability-Tests bieten die Möglichkeit verschiedene Gestaltungsformen vor der Implementation zu prüfen. Der Prozess ist in Iterationen mit folgenden Schritten gegliedert:
Fokus
Szenario
Konzipieren und Erstellen
Evaluieren
Die erste Phase dient zur Klarstellung, welches Ziel mit dem Prototyp erreicht werden soll. Zudem klärt sich der Umfang und die Darstellungstreue des Durchgangs. Im nächsten Schritt formt sich die Benutzergruppe des zu gestaltenden Bausteins. Dadurch bestimmen sich die Hintergrundkenntnisse des Users. Das Konzipieren und Erstellen beinhaltet die Entwicklung des bzw. der Prototypen und Lösungsvarianten im aktuell definierten Rahmen. Um die Iteration abzuschliessen, gilt es, eine Evaluation vorzubereiten und durchzuführen.
Über die Zeit entstehen mehrere Versionen der Komponente, welche helfen, die Anforderungen zu spezifizieren. Jeder Prototyp zeigt eigene Vor- und Nachteile, welche es zu analysieren und priorisieren gilt. Das Durchspielen der Varianten zeigt auf, an welchen Stellen weitere Anpassungen nötig sind.
Hierbei unterscheiden sich Lo-Fi- und Hi-Fi-Prototypen, welche in den folgenden Unterkapiteln weiter beschrieben sind.
Die Entwicklung einer UI-Komponente startet gewöhnlich mit diversen Lo-Fi-Prototypen. Lo-Fi steht für Low Fidelity und beinhaltet im Allgemeinen das Interaktions- und das Informationsdesign. Mit der Architektur der Informationen entsteht der Grundstein, wobei Inhalte einfach zugänglich sein sollten. Die Visualisierungen können von Skizzen bis Wireframes gehen.
Methoden von Lo-Fi-Prototypen sind Papierprototypen, Mockups oder Story Boards. Erstere gelten als schnellste Methode und sind grobe Skizzen des UI, um die Usability zu prüfen. Der Fokus liegt auf dem Konzept und ist durch minimalste Technologie möglich. Es eignet sich, Abläufe, Funktionalität, Layout und Inhalte festzulegen. Wireframes dienen zur schematischen Darstellung des UI und sind reine Schwarz-Weiss Skizzen. Als Grundlage für ein Usability Walkthrough zeigt diese Methode nur die Konzeption der Benutzeroberfläche. Ein häufig verwendetes Tool ist Balsamiq. Werden die Skizzen in eine logische Abfolge gesetzt, entsteht ein Story Board. Der Ablauf entsteht durch Benutzerfeedbacks oder in Zusammenarbeit mit den Usern. Hierbei zeigen sich die Interaktionsschnittstellen. Simulationen helfen bei der Klärung von Anforderungen und zeigen sehr früh Usability-Probleme auf.
Dieser Schritt im Designprozess startet mit ein bis zwei Resultaten der Lo-Fi Prototypen und entwickelt daraus diverse Hi-Fi-Varianten. Hi-Fi steht für High Fidelity und kümmert sich um die Details des Designs. Der Level reicht von detailreichen Skizzen bis voll interaktiven Prototypen. Diese Modelle können auf Papier, in HTML/CSS/JS oder in einem Tool wie Figma umgesetzt sein. Sie zeigen anhand statischer Screens die realen Oberflächen und Interaktionen auf.
Der Fokus kann auf dem Visual Design oder der Interaktion liegen. Wenn das Visuelle eine grössere Rolle spielt, ist der Detailgrad sehr nahe an der künftigen Umsetzung. Im anderen Fall liegt die Interaktion im Mittelpunkt und der visuelle Detailgrad kann niedrig oder hoch sein.
Um das reale Erscheinungsbild zu simulieren, sind bereits Inhalte des Endprodukts im Einsatz. User-Tests unterstützen hier bei der Entwicklung des UI-Designs und der Abstimmung des Benutzerflusses. Dieser Schritt vermeidet nicht nur kostspielige Produktfehler in der Umsetzung.
Ein möglicher Standard kann der Weissraum sein. Hierbei ist der Unterschied zwischen dem Makro-Leerraum für die Wertigkeit und dem Mikro-Weissraum für die Lesbarkeit zu bedenken. Wird nur eine einzelne Web-Komponente entwickelt, spielt hauptsächlich die Mikro-Ebene eine Rolle. Die Abstände geben dem Baustein eine Struktur. Ein Raster hilft bei der Definition der Abstände, als auch der Grösse von einzelnen Objekten. Weiter definiert das System die Typografie, welche die Schriftart, -grösse, -schnitt und -familie beinhaltet. Proportionen sind weitere Elemente eines Designs, welche standardisiert sein können. In den richtigen Verhältnissen geben diese dem Nutzer ein angenehmes Gefühl.
Farben spielen bei der Gestaltung eine zentrale Rolle. Sie ergeben in der richtigen Kombination folgende Harmonien (Abbildung 3.1):
Die Kolorierung kann in verschiedenen Tönungen und Sättigungen auftreten. Zudem gilt es, die Farbpsychologie (Abbildung 3.2) zu beachten, damit der Nutzer das gewünschte Gefühl übermittelt erhält.
Sind die Farben gewählt, folgt die Prüfung, dass die Accessibility gegeben ist. Diese gliedert sich in die Hauptgebiete Seheinschränkung, Höreinschränkung und Einschränkungen im Text- und Informationsverständnis. Für Sehbehinderte hat die Farbe eine wichtige Bedeutung.
Um die Icons einheitlich zu halten, sollten diese im System als Library angeboten werden. Darin ist zu achten, dass alle dem selben Schema folgen – sei es stroke oder filled.
Mikro-Interaktionen unterstützen den Nutzer bei einer Aktion. Der Trigger löst eine Aktion aus, welche vom Benutzer oder System stammen. Sobald die Aktion startet, liegen Regeln vor, was passieren soll. Ein visuelles, auditives oder haptisches Feedback teilt dem Benutzer mit, was geschehen ist. Im letzten Schritt ist definiert, welche Auswirkungen eine Änderung der Bedingungen zur Folge hat. Diese Designaspekte beeinflussen den User – in manchen Situationen sogar unbewusst.
Zeitpunkte Micro Interactions einfliessen zu lassen sind:
Daten-Eingabe
Anzeige einer kommenden Aktion
Aktueller Systemstatus
Animierte Buttons
Um Funktionen zu erklären und den Anwender zu unterstützen, kann folgendes Code Snippet 3.1 mit angepasstem Inhalt über der Code-Komponente platziert werden.
Zeile 2 des Code Snippet 3.1 gibt eine zusammenfassende Beschreibung, welchen Zweck die Funktion hat. Optional kann in einem weiteren Absatz mehr Details zu der Funktion gegeben werden. Das @link referenziert bereits existierende Typen, um in den IDEs einfacher navigieren zu können. Die Zeilen 4 und 5 listen die Parameter @param und deren Zweck auf. Zugleich legen sie den erlaubten Typ der Argumente in den geschweiften Klammern fest. Zeile 6 definiert den Rückgabetyp @return, welcher im Erfolgsfall erstellt wird. Fehler, die von der Funktion geworfen werden (Zeile 7), erhalten eine Beschreibung startend mit dem @throws. Als weitere Unterstützung stellt @example (Zeile 9) ein Beispiel bereit.
Wenn die Funktion ein neues Objekt wie in Code Snippet 3.2 erstellt, erhält diese die Markierung @constructor (Zeile 5). Um generische Funktionen zu dokumentieren, wird @template (Zeile 6) zu Hilfe genommen und als Typ in der weiteren Beschreibung verwendet. Die Sichtbarkeit der Funktion oder Variable beschränkt sich mit @private (Zeile 4) auf das aktuelle File.
JSDoc erweitert JavaScript mit der Möglichkeit Variablen und Konstanten Typen zuzuweisen oder gar eigene Typen zu erstellen.
Zeile 2 des Code Snippet 3.3 definiert durch @typdef einen neuen, einfachen Typ, welcher die Monate Januar bis April als Werte zulässt. Es ist sogar möglich verschiedene Typen wie Zahlen und Texte zu kombinieren. Der neue Typ mit @typedef auf Zeile 6 definiert ein Objekt, welches aus einem Tag, einem Monat und einem Jahr besteht. Hierbei stammt der Monat (Zeile 8) aus dem zuvor erstellten Typ von Zeile 2 und die anderen Felder mit @property identifizieren sich als Zahlen (Zeilen 7 und 9). Die eigenen Typen können wie die vordefinierten verwendet werden (Zeile 13).
Die Projectors binden durch die Controller das Model bzw. PresentationModel an die View. Die Art der Bindung hängt von den Eigenschaften der View und dem Zweck des Projectors ab. Controller können mehrere Presentationsmodelle generieren, behalten diese aber privat. Dafür veröffentlichen sie Methoden, die von den Projectors verwendet werden. Da die Zugriffe auf Modelle alle über die Controller laufen, setzt dieser alle Geschäftsregeln durch. Ein PresentationModel generiert Attribute. Diese wiederum generieren benötigte Observables, welche mehr Informationen als nur den Wert enthalten. Wichtig ist, dass der View keine Kenntnis von den anderen Komponenten erlangt.
Eine Master-Detail View kommt zur Anwendung, wenn eine Liste von Elementen angezeigt wird. Zugleich ist ein spezifisches Element davon mit allen Informationen in der View sichtbar. Der Master View (auch Explorer genannt) enthält die Liste. In dieser sind nur wenige Informationen oder nur ein Wert pro Eintrag ersichtlich.
Um Designvarianten zu bewerten, ist die Durchführung von User-Tests unerlässlich. Ein Teil der Nutzerbefragungen basiert auf Papierprototypen. Die Tests zielen darauf ab, die Benutzerfreundlichkeit, Effizienz und intuitive Bedienbarkeit der verschiedenen Prototypen zu ermitteln. Die Evaluation der drei Prototypen – L (Abbildung 3.14), M (Abbildung 3.15) und R (Abbildung 3.16) – findet mit unterschiedlichen Testpersonen statt.
Um die Prototypen zu testen, sind die oben erwähnten Testpersonen mit abweichenden Profilen – Robert (junger Alltagsbenutzer, Digital-Native), Sara (semi aufmerksam, nicht schnell auf der Tastatur) und Nick (Alltagsbenutzer/ Student) – ausgewählt. Jeder der drei Nutzer führt eine Reihe von Aktionen durch, wie etwa das Auswählen eines Landes. Daraus resultiert jeweils Feedback mit ihren Erfahrungen.
Folgende Rückmeldungen unterstützen die weitere Entwicklung der Komponente enorm. Die unterschiedlichen Sichtweisen beheben den eigenen schwarzen Fleck.
Prototyp L: Als effizienteste Lösung bewertet, da dieser verschiedene Auswahlmöglichkeiten bietet und eine schnelle Navigation ermöglicht.
Prototyp M: Verwirrung über die Notwendigkeit, Kontinente zuerst auszuwählen; unklar, ob Länderkürzel eingegeben werden können.
Prototyp R: Vorauswahl nicht intuitiv; Anwender wollte ursprüngliche Auswahl bestätigen, nicht ändern.
Prototyp L: Klare und einfache Bedienung, Tastaturbedienung nicht notwendig.
Prototyp M: Einfache Bedienung, aber Tastaturbedienung nicht erforderlich.
Prototyp R: Klar und einfach zu bedienen, keine Tastaturbedienung erforderlich.
Prototyp L: Klare und direkte Auswahlmöglichkeit, schnelle und intuitive Bedienung.
Prototyp M: Negatives Feedback wegen zu vieler Zwischenschritte und aufgezwungener Auswahl.
Prototyp R: Anfängliche Verwirrung, Vorauswahl sollte klarer sein.
Das allgemeine Feedback betont die Wichtigkeit einer effizienten und benutzerfreundlichen Gestaltung der Dropdown-Komponente. Die Testpersonen bevorzugen Ansätze, die eine direkte und schnelle Auswahl ermöglichen, ohne unnötige Zwischenschritte oder Verwirrung. Prototyp L erhält insgesamt als auch einzeln die beste Bewertung in der Effizienz und Benutzerfreundlichkeit.
Die Ergebnisse zeigen, dass eine optimale Dropdown-Komponente eine Balance zwischen Effizienz, Einfachheit und intuitiver Bedienung bieten muss. Die Möglichkeit, direkt und ohne Umwege ein Land auszuwählen, löst ein positives Gefühl aus. Dies unterstreicht die Bedeutung einer gut durchdachten Benutzeroberfläche, die die Bedürfnisse der Endnutzer in den Vordergrund stellt. Das Finale Design muss diese Erkenntnisse berücksichtigen, um eine optimale Benutzererfahrung zu gewährleisten.
Die Kunden testen die gleichen Papierprototypen wie die Testpersonen aus Kapitel 3.3.1. Sie bewerten die Benutzerinteraktion und die technische Umsetzung, um spezifisches Feedback zur Weiterentwicklung der Komponente zu geben. Erfahrungen und Fachkenntnisse sind in die Bewertung mit eingeflossen.
Autovervollständigung: Die Dropdown-Komponente soll nicht sofort bei Fokussierung öffnen, sondern erst bei der Eingabe von Buchstaben. Indem das spätere Öffnen die Übersichtlichkeit erhöht und gleichzeitig die Auswahl zu treffen beschleunigt, könnte sich die Benutzererfahrung verbessern.
Tastaturinteraktion: Die Pfeiltasten zur Navigation in der Dropdown-Liste nutzen. Beispielsweise könnte die Pfeil-nach-unten-Taste die Liste öffnen, um eine flüssigere Bedienung zu ermöglichen.
Browser-Autocomplete-Standard: Standards wie die Browser-Autocomplete-Funktion können genutzt werden, um die Bedienung intuitiver zu gestalten.
Leertaste als Öffnungsmechanismus: Die Integration der Leertaste als zusätzliche Option zum Öffnen der Komponente, um die Bedienbarkeit zu erleichtern.
Fokus- und Schliessverhalten: Den Fokus innerhalb der Komponente auch bei Mouse-Out zu behalten, aber bei einem Klick ausserhalb zu schliessen, um eine konsistente Benutzererfahrung zu gewährleisten.
Backspace für Korrekturen: Die Möglichkeit, mit Backspace eine Auswahl rückgängig zu machen.
Weitere technische Empfehlungen:
Wo möglich const verwenden und die Implementierung des vorhandenen DebounceInput für die Sucheingaben nutzen.
Die folgenden Kapitel beschreiben das Vorgehen in der Prototyping-Phase. Angefangen von der Suche eines geeigneten Beispiels über diverse Lo-Fi bis hin zu den Hi-Fi Prototypen entwickeln sich mehrere Strukturen und Varianten. Mit dem Voranschreiten der Prototypen zeichnen sich immer mehr Details aus und beantwortete Fragen fliessen ein.
Eine Möglichkeit, die Aufgabenstellung zu visualisieren, ist Anwendungsbeispiele für die Auswahl-Komponente zu finden. Die verschiedenen Ideen helfen die Problematik des Standard-Dropdown aufzuzeigen. Sobald die Fragestellung geklärt ist, folgt das Analysieren aller Beispiele. Die Fokussierung auf ein gemeinsames Beispiel erleichtert das weitere Vorgehen. Die Arbeit mit konkreten Daten ist einfacher. Dadurch sind die Prototypen bzw. Varianten nicht nur analysierbar sonder auch vergleichbar.
Die Liste "alle Länder der Welt" bietet sich als passendes Beispiel an. Dieser Datensatz enthält eine grosse Datenmenge von ca. 250 Werten. Das konkrete Beispiel findet sich auf vielen Formularen wieder. Zudem deckt es die in Kapitel 1.1 erwähnte Problematik ab.
Um schnell eine Vielzahl von Ideen zu entwickeln und zu visualisieren, ist das aktive Verwenden des Lo-Fi Prototyping die beste Möglichkeit. Dadurch entstehen zwischen 7 und 10 Konzepte mit jeweils 2 bis 5 Varianten. Wegen den Feinheiten des Designs nicht vom Weg abzukommen, ist das oberste Ziel.
Die Konzentration liegt auf der grundlegenden Anordnung und den erforderlichen Elementen der Komponente. Effizient klären sich hierbei entscheidende Fragen zur Funktionalität und zum Nutzererlebnis. Die unbedingt benötigten Elemente als auch deren Anordnung innerhalb der Benutzeroberfläche stehen im Fokus. Ideen schnell zu Papier gebracht (Abbildung 3.4) helfen verschiedene Lösungsansätze unmittelbar zu visualisieren und zu bewerten.
Die Verwendung von Lo-Fi Prototyping erweist sich als besonders vorteilhaft für die Förderung der Kreativität. Diese Methode erleichtert das frühzeitige Einholen von Feedback. Dadurch minimiert sich der Zeitaufwand und die Kosten für Änderungen.
Als Teil der Lo-Fi Prototypen entstehen HTML-Skizzen (Abbildung 3.5 und 3.6). Hierbei liegt – wie auf Papier – die Anordnung der Elemente im Mittelpunkt. Schnell fällt auf, welcher Prototype eher unübersichtlich wirkt (Abbildung 3.6) und welcher viel Platz einnimmt (Abbildung 3.5). Die Code-Ordnung ist nicht relevant.
Um die Interaktionen und das Benutzererlebnis der Entwürfe zu verfeinern, kommen im UX/UI-Design-Prozess Papierprototypen zum Einsatz. Durch die Erstellung von drei Lo-Fi Prototypen aus Papier gelingt die detaillierte Darstellung der geplanten Interaktionen. Dies hilft die Bedienung Schritt für Schritt nachzuvollziehen.
Dieser Ansatz ermöglicht, die Handlungen der User präzise zu durchdenken und darzustellen. Erst wenn die Abläufe geklärt sind, ist der Übergang zur digitalen Umsetzung sinnvoll. Durch die Dokumentation der Interaktionen auf Papier zeigen sich verschiedene Benutzerpfade. Hierbei ermöglichen sich Simulationen als auch das Ausprobieren der Benutzeroberfläche. Dies begünstigt frühzeitig mögliche Probleme und Herausforderungen in der Benutzerführung zu erkennen und anzugehen.
In User-Tests erweist sich das Papier-Prototyping als besonders wertvoll. Die direkten Benutzerfeedbacks sind eine einfache und kostengünstige Möglichkeit Korrekturen früh einzubringen. Zugleich testet dieser Schritt die grundlegenden Designkonzepte. Das analoge Durchlaufen der Papiermodelle bietet einen grossen Gewinn an Erkenntnissen über die Benutzererfahrung. Zusätzlich stellt der Vorgang sicher, dass Designentscheidungen auf den Bedürfnissen und Erwartungen der künftigen Benutzer basiert.
Insgesamt ist das Papier-Prototyping ein entscheidender Schritt im Designprozess. Dabei unterstützt der analoge Lo-Fi Prototyp die Entwicklung einer nutzerzentrierten und intuitiven Benutzeroberfläche. Daraus entsteht eine solide Grundlage für den Hi-Fi Designansatz.
Bei der Übernahme des Papierprototypen ins Figma entstehen zwei Varianten. Von Anfang an liegt der Fokus darauf in Komponenten zu arbeiten. Dadurch lassen sich Anpassungen einfach ergänzen und umsetzen. Das im Figma bereits enthaltene Designsystem hilft bei der Entwicklung der Hi-Fi Prototypen. Das monochrome Grau bzw. Violett stellt sich im ersten Farbkonzept in den Mittelpunkt. Ziel der Grautöne ist es, dezent und elegant zu wirken. Das Violett greift die Primärfarbe des Kolibri auf und arbeitet mit dessen Schattierungen.
Die erste Variante bildet grösstenteils den Papier-Prototypen strukturell ab. Die violetten Stylings stellen die Status der Elemente dar. Der geschlossene Zustand der Auswahlkomponente erscheint in einem einfachen Aufbau (Abbildung 3.8). Dabei zeigt sie den Platzhalter oder das selektierte Land mit einem rechtsbündigen "X" an, als auch einen Pfeil für das Öffnen der Komponente.
Die Ausarbeitung des Dropdown-Inhalts gestaltet sich aufwendiger. Die möglichen Zustände stellen sich bei der Analyse der Komponente heraus. Beim Designen teilen sich die Status in normal, selektiert, fokussiert und selektiert-fokussiert auf. Für eine Unterscheidung dessen erhält jeder ein eigenes Aussehen (Abbildung 3.9).
Die Selektion muss auf den ersten Blick gut sichtbar sein, daher erscheint eine dezente Hintergrundfarbe logisch. Denn diese sticht, ohne aufdringlich zu wirken, gut heraus. Der Fokus erhält ein dezenteres Erscheinungsbild, muss aber zugleich mit der Selektion kombinierbar sein. Daraus resultiert die Entscheidung das Element durch einen Rahmen umzugestalten. Da dieser nicht so viel Fläche abdeckt und einen Kontrast zur Selektion bieten soll, ist die Violett-Schattierung kräftiger.
Die geöffnete Auswahlkomponente setzt sich aus vorbereiteten Elementen zusammen (Abbildung 3.10). Die Kopfzeile enthält dabei nur noch oben einen Border-Radius, um die Listenbox zu ergänzen. Dadurch zeigen sich die beiden Teil-Komponenten als Einheit. Um dem Benutzer den Zustand der Listenbox anzuzeigen, dreht sich der Pfeil in der Kopfzeile.
Parallel zu der ersten Version (Abbildung 3.10) entfaltet sich eine zweite kompaktere Variante (Abbildung 3.11). In dieser ist dieselbe Kopfzeile ersichtlich, jedoch mit anders gerichteten Pfeilen. Im geschlossenen Dropdown zeigt der Pfeil nach links und im offenen nach unten. Um die Auswahlkomponente (Abbildung 3.11) kompakter darstellen zu können, sind die Kontinente als Kürzel in Lesezeichen orientierten Reitern angeordnet. Der aktive Kontinent erhält einen dunkleren Hintergrund, um den selektierten Zustand anzuzeigen.
Beim Vergleich der beiden Varianten zeigt sich der erste Hi-Fi Prototyp als geeigneter. Bei der späteren Generalisierung findet sich nicht für jede Kategorie eine Abkürzung. Die erste Variante der unterschiedlichen Pfeile ist den meisten Usern geläufiger.
Eine intensivere Auseinandersetzung mit der Bedienbarkeit zeigt auf, dass die Accessibility der Komponente eine Überarbeitung benötigt. Der Rahmen für den Fokus und die Ähnlichkeit der Schattierungen sind in dieser Hinsicht eher ungeeignet (Abbildung 3.9). Für Personen mit einer Sehbeeinträchtigung bietet das gewählte monochrome Farbkonzept einen zu schwachen Kontrast. Die Namen der Status geben den Hinweis auf die neuen Farben. Im Kolibri existieren bereits die Selektionsfarbe Gelb und die Akzentfarbe Rosa, welche einen guten Kontrast bieten. Zusätzlich wird Gelb in der Farbpsychologie (Abbildung 3.2) für eine energetische Stimmung genutzt. Diese beiden Farben bilden das zweite Farbkonzept. Für eine bessere Erkennung des Fokus-Elements löst sich der Rahmen zu Gunsten der Schriftfarbe auf. Daraus entstehen die Elemente der Abbildung 3.12. Diese wiederum sind in der Abbildung 3.13 im Einsatz zu sehen.
In der Lo-Fi und Hi-Fi Prototyping Phasen sammeln sich verschiedene Interaktionsmöglichkeiten und -abläufe. Dabei spielt der Hintergrund der befragten Nutzer eine tragende Rolle.
Ein typischer Alltagsnutzer verwendet in der Interaktion grösstenteils die Maus. Diese ermöglicht unter anderem die Aktionen Klick, Hover und Scrollen. Der Klick auf ein Element – Kontinent oder Land – setzt den Status dessen auf selektiert. Dadurch erhält jener Bestandteil das dazu passende Design. Das zuvor in der selben Spalte selektierte Element wechselt den Status auf normal. Bei dem Klick auf ein Land wird dessen Wert in der Kopfzeile eingesetzt. Wenn sich die Maus über einem Kontinenten oder Land bewegt oder befindet, steht dieses mit dem dafür definierten Stil im Fokus. In der ganzen Listenbox besitzt nur ein Eintrag den Status fokussiert. Ein Klick auf den Pfeil auf der rechten Seite der Kopfzeile öffnet bzw. schliesst das Dropdown, je nach Zustand vor der Aktion. Bei einem Klick auf das "X" neben dem ausgefüllten Wert leert sich das Feld in der Kopfzeile. Zusätzlich hebt sich die Selektion in der Länderspalte auf. Das Scrollen innerhalb der Länderspalte bewegt diese Liste nach oben oder unten.
Auch Tastatur-User kommen bei dieser Komponente auf ihre Kosten. Aktionen mit der Tastatur sind ein weiterer Bestandteil des Interaktion-Designs. Im geschlossenen Zustand des Dropdown bewirkt die Enter-, Leer- oder Pfeiltaste nach unten das Öffnen des Dropdown. Ist die Listenbox einmal sichtbar, dienen die Pfeiltasten zur Navigation zwischen den Elementen. Springt der Fokus auf ein Land ausserhalb des sichtbaren Bereichs, verschiebt sich die Liste um einen Eintrag in dessen Richtung. Enter oder Space selektieren den im Fokus stehenden Wert. Bei einer Länder-Selektion füllt sich die Kopfzeile aus, anderenfalls wechselt der Fokus vom Kontinenten-Eintrag in die Länder-Spalte. Die Escape-Taste schliesst die Listenbox, ohne eine Änderung am eingetragenen Wert vorzunehmen. Backspace und Delete entfernen den Wert aus der Kopfzeile. Tab behält die typische Funktion in Formularen bei und wechselt zum nachfolgenden Input. Zusätzlich schliesst die Aktion die Listenbox. Bei der Verwendung der einzelnen Symbole – wie z.B. Buchstaben – beginnt eine Suche in der Länderliste. In der Liste wird zum ersten mit der Eingabe übereinstimmenden Eintrag gescrollt. Bei der Eingabe der Suche kommt die nachfolgende Strategie zum Einsatz.
Auf dem Weg der Auswahlkomponente kommen diverse Methoden zum Einsatz. Der beschreibt die theoretischen Errungenschaften. Die bis zeigen die Anwendung der recherchierten Methoden, sowie die Entscheidungsprozesse im Detail. Hierbei bezieht sich das Prototyping auf die Gestaltungsvorgänge der Komponente. Auf den wichtigen Zwischenschritt des repetitiven Testing folgen die implementativen Vorgehensweisen.
Dieses Kapitel behandelt das Vorgehen während des Implementations-Prozesses. In der Prototyping-Phase entsteht der erste HTML Prototyp. Durch das Anwenden des Refactoring löst sich dieser chaotische Code auf. Im iterativen Prozess entstehen sechs aufgeräumte und dokumentierte Files.
Parallel zur Ausarbeitung der Details des Figma Prototypen entsteht ein Lo-Fi HTML-Prototyp (). Ziel des Codes ist eine erste, rudimentäre Implementation zu erstellen. Damit zeigt sich ein erster Beweis für die Umsetzbarkeit der konzeptionell geplanten Komponente.
Die Navigation (Code Snippet 3.7) mit den Pfeiltasten, sowie weiteren typischen Aktionstasten ist über ein Key Event geregelt. Diese Umsetzung kümmert sich nur im die grundlegenden Tasten, welche von den meisten anderen Elementen ebenfalls unterstützt werden.
Auf der anderen Seite vereinfacht die Modularisierung (Code Snippet 3.8 & 3.9) des erstellten JS-Files die weitere Überarbeitung des Codes. Der zweite Refactoring-Durchlauf löst die Komplexität aus dem Prototypen ein wenig auf. Dies geschieht indem die Variablen eine saubere Benennung erhalten. Zudem entstehen Funktionen mit einem klaren Ziel, welche an den ursprünglichen Stellen aufgerufen werden. Im gleichen Schritt entwickelt sich der erste Prototyp der Suche. Während dieses Durchgangs entsteht parallel der erste Teil des JSDoc. Die Umsetzung des Projector Pattern als auch der Debounce Suche folgt im Zusammenhang mit weiteren Iterationen des Refactoring.
Die Analyse des SimpleInput offenbart, dass bereits ein Debounce-Input existiert. In der folgenden Passage ist beschrieben, wie diese zum Einsatz kommt.
Bei einer weiteren Analysierung der soweit entstandenen Komponente zeigt sich ein Master-Detail Aufbau. Dieses Muster lässt sich in einer nächsten Iteration des Refactoring umsetzen.
Jede dieser JS-Dateien erhält bei der Umsetzung des Master-Detail Pattern Änderungen. Eine sinnvolle Reihenfolge für die Überarbeitungen der Pattern-Komponenten startet beim Model (Code Snippet 3.11), gefolgt vom Controller (Code Snippet 3.12) und zum Schluss der Projector (Code Snippet 3.13).
Die ersten zwei Files trennen ihren Inhalt in einen Master und einen Detail (Code Snippet 3.11 & 3.12) Teil auf. Dadurch entstehen jeweils zwei getrennte Models und zwei unabhängige Controller. Der Projector (Code Snippet 3.13) erwartet durch angepasste Parameter nun je einen Master- und einen Detail-Controller. Im Starter Code ist es nun notwendig die Models als auch die Controller separat zu erstellen und gemeinsam dem Projector zu übergeben.
Der Detail View erhält die Daten der Kopfzeile der Komponente. Die Informationen sind sowohl im geschlossenen als auch im offenen Zustand sichtbar. Die Master Ansicht ist nur in letzterem Status im UI sichtbar. Zugleich verwaltet es den Zustand als auch den Debounce-Text der Komponente. Folgende detaillierte Aufteilung entwickelt sich während des Refactoring und der Umsetzung des Patterns.
Detail:
Selektiertes Element aus Werte-Liste (Value)
Platzhalter
Label
Name (für Formulare)
Master:
Liste aller Elemente
Selektionsobjekt aus Kategorie und Value
Fokusobjekt aus aktiver Spalte und Element (Kategorie oder Value)
Das Prototyping im HTML zeigt schnelle Erfolge, ohne sich sehr lange mit den Details aufzuhalten. Der schrittweise Ausbau unterstützt die Entwicklung. Mit dessen wiederholten Beschäftigung wird der Code immer klarer. Anfangs komplex erscheinende Stellen der Codebasis oder eigener Dateien, erscheinen verständlicher. Die erhaltene Klarheit des Codes hilft bei der Dokumentation. Das Refactoring unterstützt die Entwicklung insofern, dass sich Fehler durch das Umschreiben offenbaren. Hierbei grenzen sich die Stellen ein und die Bugs lassen sich schneller beheben.
() Vorteile der Low Fidelity Prototypen sind das schnelle Sammeln von Benutzerfeedbacks und das Reduzieren des Entwicklungsrisiko. Noch während des laufenden Betriebs fliessen Änderungen und Korrekturen ein. Mit der Zeit sind die Mockups weitestgehend ausgearbeitet. Im nächsten Entwicklungsschritt entstehen Hi-Fi-Prototypen.
Der Hi-Fi-Prototyp arbeitet bestenfalls mit einem Designsystem. () Darin sind Standards definiert, welche in der aktuellen Gestaltung immer wieder auftreten. Die Konventionen enthalten wiederverwendbare Komponenten und bieten eine Konsistenz über das Design. Die diversen Richtlinien dienen zur Vereinheitlichung der Prototypen.
() Refactoring zielt darauf ab, den Code übersichtlicher und lesbarer zu gestalten. Eine Schritt für Schritt Umstrukturierung ermöglicht es, komplexe Passagen ohne Funktionalitätsänderung, die Verständlichkeit zu erhöhen. Diese Methode hilft Fehlerquellen zu finden, welche zuvor in der Komplexität versteckt waren. Teilweise werden gewisse Schwachstellen sogar gelöst. Zweck ist es Abhängigkeiten aufzulösen und bestenfalls unabhängige Komponenten zu erstellen. Die bessere Lesbarkeit unterstützt eine spätere Wartung und erhöht die Widerstandsfähigkeit. Der Prozess ist iterativ. Am Ende ist der Code idealerweise möglichst komprimiert und besteht aus extrahierten Komponenten, welche klar in ihrem Verwendungszweck sind. Die Verschachtelungen sind grösstenteils aufgelöst oder umgeschrieben. Wichtig ist, nach einem Refactoring alle Funktionen erneut zu testen.
Dieser Teil geht nur auf die wichtigsten Eckpunkte von JSDoc ein. Es beschreibt nur die verwendete Komponente und nicht das volle Potenzial. Die folgenden Passagen referenzieren das Thema JSDoc von .
() Das Projector Pattern (Abbildung 3.3) ist eine Erweiterung des MVC Pattern. Zu Model, View und Control kommen Projectors, welche mit den Controllern verschiedene Views generieren.
Die Debounce-Technik als Schlüsselelement trägt wesentlich zur Effizienz und Benutzerfreundlichkeit bei. Um die Benutzerinteraktionen zu optimieren, bietet es sich an, diese Technologie bei einer umfangreichen Liste strategisch einzusetzen. Die Eingabe hält sich jedoch nur eine kurze Zeit – weniger als eine Sekunde – im Speicher. Nach dem Ablauf dieser Zeitspanne, ab dem ersten Symbol gemessen, fängt die Suche neu an. Genauere Implementationsdetails folgen im .
Dieser Prototyp (Code Snippet 3.4) bestehend aus einer Datei enthält den gesamten HTML, CSS (Zeile 5) und JavaScript (Zeile 12) Code. Wegen der grossen Datenmenge (Zeile 10) resultiert die Entscheidung diesen Code als einzigen in eine externe Datei (Zeile 10, ) auszulagern. Dies vereinfacht die Verwendung in weiteren Prototypen. Ein Auszug aus der Datenmenge von ist in Code Snippet 3.5 ersichtlich.
Wenn sich das Konzept im Lo-Fi Prototyp als gut erweist, entwickelt sich der Ansatz zu einem Hi-Fi Prototyp () weiter. Dabei kommt der erste tiefere Kontakt mit der Codebasis zustande.
Als wichtige CSS Dateien erweisen sich , und des Kolibri-Repository () . Diese finden sich in den Importen im <style>-Tag wieder (Code Snippet 3.6).
Bei den JS-Dateien stechen die Dateien aus dem Ordner heraus. Die drei Files des SimpleInput zeigen den Aufbau einer vorhandenen Formularkomponente. Diese Struktur dient beim späteren Refactoring () als Vorlage bzw. Beispiel.
Der Hi-Fi Prototyp von beinhaltet eine Bedienung mit der Tastatur (Code Snippet 3.7) und bietet eine Möglichkeit zur Suche.
In der weiteren Entwicklung des HTML Hi-Fi Prototypen aus dem kommt das Refactoring in iterativen Schritten zum Zuge. Bei der ersten Überarbeitung liegt der Fokus auf dem Aufteilen des gesamten Codes in mehrere Dateien. Die Zerlegung schafft eine bessere Struktur. Es entsteht pro Technologie ein File. In der weiteren Entwicklung geschieht das unabhängige, repetitive Refactoring der drei Dateien.
Das CSS teilt sich in zwei Dateien (CSS-Dateien im ). Eine Datei dient der Verwaltung der Variablen, welche für die Komponente zuständig sind. Das Design der einzelnen Selektoren steht im zweiten File. Da dieser Teil noch sehr viel Code enthält, hilft eine weitere Iteration der Überarbeitung. Diese prüft die einzelnen Properties auf ihre Notwendigkeit und erstellt eine Ordnung bzw. Gruppierung der Selektoren. In Kombination zum Refactoring wird das Design optimiert und entdeckte Fehler korrigiert.
Das Projector Pattern teilt den komplexen JS-Code in drei modulare Komponenten (JS-Dateien im ). Um das UI testbar zu implementieren, gesellt sich zu diesen Files noch ein weiteres mit dem JS-Starter Code dazu. Die klare Trennung der Verantwortlichkeiten unterstützt die Wartung als auch die Weiterentwicklung des Codes. Die Wiederverwendbarkeit wird dadurch gesteigert. Da diese Struktur bereits beim SimpleInput umgesetzt ist, dient diese Komponente als gute Vorlage. Die Abhängigkeiten zwischen den einzelnen Dateien minimiert sich. Bei der Umsetzung des Patterns reduziert sich der Code im HTML-File auf wenige Zeilen (Code Snippet 3.10).
Im Refactoring- und Optimierungsprozess der Suche bietet sich eine Debounce-Funktion an. Diese kommt ohne ein sichtbares UI-Feld aus. Der default case des Key Events (Code Snippet 3.7) für die Auswahlkomponente definiert die Aktion von Tasteneingaben einzelner Symbole wie z.B. Buchstaben. Das Debounce fügt alle Eingaben innerhalb einer Zeitspanne zu einem Suchbegriff zusammen. Dieser wiederum kommt bei der Suche zum Zuge. Die vorhandene Debounce-Komponente bietet sich an, um den Suchbegriff zu verwalten (, Datei choiceInputProjector.js). Zusätzlich löst die Eingabe einen Trigger für die Suche in der Länder-Liste aus. Das dafür notwendige Input-Feld dient rein zur Verwaltung der Daten und zum Triggern der Suche. Das UI hat keine Kenntnisse von diesem Input und ist dadurch vor Manipulationen geschützt.
