# 3.1 Recherche

## 3.1 Recherche

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.&#x20;



### 3.1.1 Prototyping

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:

1. Fokus
2. Szenario
3. Konzipieren und Erstellen
4. 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.&#x20;

Ü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.&#x20;

Hierbei unterscheiden sich Lo-Fi- und Hi-Fi-Prototypen, welche in den folgenden Unterkapiteln weiter beschrieben sind.



#### _3.1.1.1 Lo-Fi Prototyp_

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.&#x20;

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.&#x20;

([Figma, 2024](../verzeichnisse/quellenverzeichnis)) 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.



#### _3.1.1.2 Hi-Fi Prototyp_

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.&#x20;

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. &#x20;

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](../verzeichnisse/quellenverzeichnis)) 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):&#x20;

<figure><img src="https://1522838658-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNvo6hdRzjxG7GD0plKny%2Fuploads%2F6yfAHq1GQTRIVvH5wo2t%2Fimage.png?alt=media&#x26;token=3344485b-8de2-4271-b2ad-4d651980c3f4" alt="" width="375"><figcaption><p>Abbildung 3.1 - Farb-Harmonien (<a href="../appendix/g-unterrichtslides-zu-farben">Appendix G</a>) </p></figcaption></figure>

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.&#x20;

<figure><img src="https://1522838658-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNvo6hdRzjxG7GD0plKny%2Fuploads%2Fuv0UYDLTh45phvqdcZxf%2Fimage.png?alt=media&#x26;token=4abd0e1d-a31d-4935-a6b1-12258261d611" alt=""><figcaption><p>Abbildung 3.2 - Tabelle der Farb-Psychologien (<a href="../appendix/g-unterrichtslides-zu-farben">Appendix G</a>) </p></figcaption></figure>

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_.&#x20;



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.&#x20;

Zeitpunkte Micro Interactions einfliessen zu lassen sind:&#x20;

* Daten-Eingabe
* Anzeige einer kommenden Aktion&#x20;
* Aktueller Systemstatus
* Animierte Buttons



### 3.1.2 Refactoring

([Gillis, 2024](../verzeichnisse/quellenverzeichnis)) 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.



### 3.1.3 JSDoc

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](../verzeichnisse/quellenverzeichnis)[)](../verzeichnisse/quellenverzeichnis).

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.

{% code title="Code Snippet 3.1" lineNumbers="true" %}
```javascript
/**
 * This function writes the string of the parameter defaultValue repete times in an {@link Array}.
 * 
 * @param { !String } defaultValue - a mandatory string to define the string to insert
 * @param { Number } repeat        - an optional number to define the number of entries in the array, default 1
 * @return { Array<String> } a list of repeat number of entries with the defaultValue
 * @throws { NumberOutOfRangeException } - happens if repeat is negative
 *
 * @example 
 *       const myList = createArray("foo", 5);
 */
const createArray = (defaultValue, repeat = 1) => { doWork };
```
{% endcode %}

_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.&#x20;

{% code title="Code Snippet 3.2" lineNumbers="true" %}
```javascript
/**
 * This function creates a default person with the name from arg val.
 * 
 * @private
 * @constructor
 * @template _T_
 * @param { _T_ } val - value to save in the name property
 * @return { Person } a default person
 */
const Person = (val) => { name: val };
```
{% endcode %}

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.&#x20;

JSDoc erweitert JavaScript mit der Möglichkeit Variablen und Konstanten Typen zuzuweisen oder gar eigene Typen zu erstellen.&#x20;

{% code title="Code Snippet 3.3" lineNumbers="true" %}
```javascript
/**
 * @typedef { "January" | "February" | "March" | "April" } Month
 */
 
/**
 * @typedef { object } Date
 * @property { Number } day
 * @property { Month } month
 * @property { Number } year
 */
 
 /**
 * @type { Date }
 */
let currentMonth = { day: 8, month: "March", year: 2020 };
```
{% endcode %}

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



### 3.1.4 Projector Pattern

([König, 2024](../verzeichnisse/quellenverzeichnis)) 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.&#x20;

<figure><img src="https://1522838658-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNvo6hdRzjxG7GD0plKny%2Fuploads%2Fvt2CiQNzKx3QQorGdgVB%2Fimage.png?alt=media&#x26;token=61f887f4-2529-4f36-b1fc-fa00d0ac61a4" alt="" width="563"><figcaption><p>Abbildung 3.3 - Schema der Projector Pattern (<a href="../verzeichnisse/quellenverzeichnis">König, 2024</a>)</p></figcaption></figure>

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.



### 3.1.5 Master-Detail View

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.&#x20;

