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.
(Figma, 2024) 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.
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.
Der Hi-Fi-Prototyp arbeitet bestenfalls mit einem Designsystem. (Interaction Design Foundation, 2024) 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.
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
(Gillis, 2024) 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 rstacruz (2024).
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).
(König, 2024) 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 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.
