# UX-Guidelines für weitere Entwicklung der GOLDi Website

## Einführung

### Produkt Ziel

Das Remote-Labor GOLDi dient als digitale Unterstützung in der Lehrveranstaltung mit digitalen Lernobjekten. Dazu können die Experimente flexibel gestaltet werden und neben virtuellen auch reale Experimente durchgeführt werden. Hierdurch können Studenten selbständig Experimente durchführen, wodurch die Vor- & Nachbereitung der Vorlesungen unterstützt wird.

Im Rahmen dieses Projektes soll die User Experience des Remote-Labs GOLDi optimiert werden, damit die Nutzung intuitiver wird und auch Nutzer ohne Vorerfahrung und ohne ausführliche Einweisung von beispielsweise dem Lehrenden genutzt werden kann.

### Inhalte des Handbuchs

Dieses UX-Handbuch beschreibt, wie die Website GOLDi aufgebaut werden muss, damit die Usability verbessert wird.

Dazu werden folgende Themen behandelt:

- **Usability:** Analyse der Nutzergruppen, um deren Bedarf besser zu verstehen. Hierdurch kann die Bedienung für die jeweiligen Nutzungskontexte effektiver und effizienter gestaltet werden.
- **Informationsarchitektur:** Informationen wurden strukturiert und organisiert, um die Benutzerführung zu verbessern und damit die Informationen schnell gefunden werden können.
- **Interaktionsdesign:** Beim Interaktionsdesign wird der Fokus auf die Interaktionen zwischen den Nutzern und der Website GOLDi gelegt.
- **Wireframes:** Grobes Interface Design im Form von Wireframes. Die Darstellung basiert auf den vorher erarbeiteten Ergebnissen.

Die einzelnen Erkenntnisse aus der Analyse werden hier jedoch nicht dokumentiert. Diese können bei Bedarf vom GOLDi Team zur Verfügung gestellt werden.

## Nutzergruppen

### User Journey - Student Bob

Bob ist Master-Student an der TU Ilmenau und studiert Informatik im 2. Semester. Bob besucht das Modul Entwicklung eingebetteter Systeme, in dem die Webanwendung GOLDi erstmals genutzt wird. Der Dozent zeigt in der Vorlesung ein Beispiel, wie ein Experiment auf der Webseite durchgeführt werden kann, was für Bob sehr interessant ist. Am nächsten Tag möchte Bob selbst ein Experiment ausprobieren und begibt sich auf die Webseite.

Als Bob die Webseite sieht, merkt er, dass nirgendwo auf der Homepage erkennbar ist, wie ein Experiment gestartet wird. Bob Klickt sich durch die Webseite und erwartet, dass beim Menüpunkt Steuereinheit oder Physisches System ein Experiment gestartet werden kann. Die anderen Menüpunkte helfen Bob nicht weiter, da ihm Kontextwissen fehlt. Durch Zufall findet Bob nun doch eine Anleitung, die offenbar genau erklärt, wie ein Experiment begonnen werden kann.

Als Bob sich mit seinem TU-Account auf der Webseite anmeldet sieht er, dass die Navigationsbar mehrere Menüpunkte dazu erhalten hat.

Nach dem Klicken des Menüpunktes Experiment ist Bob zunächst durch die Ansicht der Experiment-Standorte verwirrt und klickt affektiv auf den Standort TU-Ilmenau, um somit endlich zur Experimentauswahl zu gelangen.

Da Bob nur einen groben Überblick in der Vorlesung erhalten hat, erkennt er ein paar der physischen Systeme und der Steuereinheiten. Was Bob allerdings nicht weiß, ist, wie er die beiden Komponenten kombinieren soll und hat von manchen der Komponenten noch nie vorher gehört.

Probehalber klickt er die Steuereinheit BEAST an und merkt, dass alle anderen Steuereinheiten und ein paar der physischen Systeme ausgegraut sind.
Ungünstiger weise wollte er als physisches System das digitale Demo-Board benutzen, was unter den ausgegrauten Komponenten ist. Stattdessen wählt er Aufzug C (4 Etagen) aus und startet schlussendlich das Experiment.


---

### User Journey - Student Alex

Alex ist Bachelor-Student an der TU-Ilmenau und studiert Ingenieurs-Informatik im 6. Semester. Alex kennt GOLDi schon seit Beginn des Studiums und hat es bereits öfters verwendet. Alex arbeitet aktuell an seiner Bachelorarbeit, in der er ein paar Experimente als Feldversuch angeben möchte. Dabei möchte er zunächst ein paar Beispiele ausprobieren, um sich mit dem Automaten-Modellierung-Tool vertraut zu machen.

Alex weiß bereits, dass er eingeloggt sein muss, um ein Experiment starten zu können. Was Alex allerdings nicht weiß, ist, welches Tool für die Modellierung von Automaten geeignet ist. Kurzerhand sucht er auf der Webseite nach Informationen und nach längerem Suchen findet er einen Hinweis, dass das Tool GIFT für die Modellierung von Automaten geeignet ist. Da Alex nun weiß, welches Werkzeug er nutzen muss, klickt er auf den Link in der Navbar. Alex kennt sich mit der Bedienung noch nicht aus und hat in der Vergangenheit auch noch keine Automaten in diesem Tool modelliert. Alex erinnert sich, dass es Beispiele auf der Webseite gab und möchte vorab ein paar ausprobieren.

Als Alex auf die Seite gelangt, stellt er fest, dass die Beispiele nicht sehr gut zu verstehen sind. Erst nach 15 Minuten ist Alex fertig, eines der Beispiele in Gift nachzubauen. Dazu stellt Alex fest, dass er mit GIFT nicht sofort ein Experiment starten kann, sondern erst das Beispiel Exportieren muss, um es dann beim Experiment wieder zu importieren. Als Alex nun endlich das Experiment startet passiert nichts. Alex kann sich nicht erklären, warum das Experiment fehlgeschlagen ist. Er schaut sich erneut seinen modellierten Graphen an und merkt, dass er einen kleinen Fehler begangen hat. Nach weiteren 5 Minuten hat Alex endlich das Experiment starten können.

Da Alex nun weiß, wie man das Tool nutzt, modelliert er seinen Automaten in GIFT nach. Als Alex seinen Prototypen jedoch wie zuvor im Beispiel testen möchte, tritt wiederum ein Fehler auf. Selbst nach wiederholtem testen und prüfen, kann er das System nicht zum Laufen bringen. Frustriert, gibt Alex auf.


---

### User Journey - Dozent Angela

Angela ist Dozentin an der TU Ilmenau. Sie möchte für das Modul "Sichere und zuverlässige Systeme", dass sie ab nächster Woche hält, das Remote Labor GOLDi nutzen. Angela hat bereits öfter mit dem Remote Labor gearbeitet und einen großen Mehrwert für die Veranstaltung bemerkt.

Angela möchte sichergehen, dass zu ihrer Vorlesung auch das gewünschte Experiment real verfügbar ist und möchte gerne das relevante Experiment reservieren. Sie loggt sich auf der Website ein und denkt, dass der Punkt Reservierung vermutlich unter dem Menüpunkt Experiment zu finden sein wird. Dort findet sie den Unterpunkt Reservierungen. Auf dieser Seite wird ihr jedoch lediglich eine leere Liste angezeigt. Angela ärgert sich, dass an dieser Stelle keine neue Reservierung hinzugefügt werden kann, sondern nur die existierenden Reservierungen angezeigt werden.

Angela überlegt, dass dann vermutlich bei der Auswahl der Experimente eine Reservierung durchgeführt werden kann. Sie wählt also den einzig aktiven Standort IUT (Germany) aus und das gewünschte Experiment. Dann entdeckt sie einen zusätzlichen Button Experiment reservieren, als ein reales Experiment ausgewählt wurde.

Angela ist erleichtert, dass sie endlich die gewünschte Seite gefunden hat. Auf den zweiten Blick hingegen fragt sie sich, wieso die Seite, um eine Reservierung zu spezifizieren, so kompliziert aufgebaut ist. Sie findet recht schnell heraus, wie die Dauer und das Datum der Reservierung ausgewählt werden. Dann versucht sie jedoch die Uhrzeit zu definieren. Sie klickt vergeblich auf die Zeitachse, bis sie entdeckt, dass die Zeitachse gescrollt werden kann. Sie wählt die gewünschte Uhrzeit aus und sucht, ob es eine Möglichkeit gibt, einen Serientermin aus der Reservierung zu machen, da sie das gewählte Experiment regelmäßig für die Vorlesung benötigt. Diese Funktion findet sie jedoch nicht, weshalb sie die Reservierung bestätigt und anschließend denselben Prozess für die nächsten 3 Vorlesungswochen durchführt. Als sie damit fertigt ist denkt sie: Warum ist die Reservierungsseite nicht einfach so aufgebaut wie bei Outlook? Das würde doch reichlich Zeit ersparen.


---

### User Journey - Dozent Gerhart

Gerhart ist Dozent an der Nordakademie. Die Universität kann seit kurzem das Remote Labor GOLDi nutzen. Gerhart hat Interesse, GOLDi für die Vorlesung "Technische Grundlagen der Informatik" zur Veranschaulichung zu nutzen. Dafür möchte sich Gerhard zunächst über die verschiedenen Funktionen von GOLDi Informieren.

Gerhart ruf die Website auf und weiß bereits von seinen Kollegen, dass er sich anmelden muss, um Experimente nutzen zu können. Er öffnet den Menüpunkt Experiment, wählt einen der Standorte aus und findet eine Vielzahl an verschiedenen Steuereinheiten und physischen Systemen vor. Für seine Vorlesung benötigt er den Automatengraph mit Drei Achs Portal, also wählt er diese aus und startet das Experiment.

Er weiß jetzt jedoch nicht, wie das Experiment ausgeführt wird. Er vermutet zwar, das die einzelnen Gleichungen die verschiedenen Pins darstellen, aber er weiß nicht welcher Pin wofür steht. Er trägt einfach mal bei einem der Pins eine 1 ein und sucht den Start Button. Diesen findet er erst nach längerem Suchen in der Fußzeile. Er denkt sich, dass eine Anleitung an dieser Stelle und ein Beispiel sehr hilfreich wären. Er schaut sich etwas weiter auf der Seite um und entdeckt einen Reiter Beispiele. Er lädt das Beispiel "Kreisen".

Als er sich anschließend die Formel anschaut, ist er jedoch verwirrt. Warum sind hier manchmal \& Verknüpfungen und manchmal nicht? Er wünscht sich eine Erklärung der Syntax, da er das Tool mit seinem jetzigen Wissensstand nicht nutzen kann.

Er ist enttäuscht, dass er das Tool nicht intuitiv bedienen kann und nimmt sich vor, morgen einmal mit einem Kollegen zu sprechen, der das Tool schon etwas länger kennt, damit dieser ihm dieses zeigen und erklären kann.


## Content

### Content Anforderung

#### Kategorie: Allgemeine Informationen

| Content | Content Typen / Format | Ziel | Pflegebedarf |
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------ |
| Willkommen auf GOLDi Webseite | **TEASER:** <br />kurzer Willkommens-Text mit einem kleinen Absatz (nicht zu technisch oder zu lang) | Nutzer <u>**soll**</u> wissen, worum es auf der Website geht | niedrig |
| Auflistung von Kern-Funktionalitäten (z.B. Standalone Tools, Reale Versuchsobjekte Live ansehen, etc.) | **TEASER:** <br />aussagekräftige, knackige Headline bei Bedarf auch kurzer Text <br /><br />**IMAGE:** <br />jeweils ein entsprechendes Bild dazu <br /><br />**CTA:** <br />direkte Weiterleitung auf entsprechender Seite / Tool | Nutzer <u>**muss**</u> verstehen, was er auf der Webseite machen kann. | mittel |
| Datenschutzerklärung | **ARTIKEL:** <br />detaillierte Datenschutzerklärung (bestehender Text kann übernommen werden). Aber auch hier bitte die Textstrukturen nochmal überprüfen. | Product Owner **<u>muss</u>** Datenschutzerklärung bekannt geben. | niedrig |
| GOLDi Team Auflistung (Über Uns) | **IMAGE:** <br />Fotos der aktuellen Mitarbeiter<br /><br />**TEASER:** <br />Kurzer Text zu jeder Person => Name, Rollen, Verantwortung, Kontaktmöglichkeit und eine kleine Danksagung an ehemalige Mitarbeiter => als Liste und kein Foto dazu, sondern nur Name (ggf. E-Kontaktmöglichkeit, wird als nicht notwendig angesehen) | Nutzer **<u>kann</u>** das GOLDi Team besser kennenlernen. | niedrig |
| GOLDi Remote Labor Vorstellung | **ARTIKEL:** <br />detaillierte Beschreibung von: Was ist ein Remote Labor und was macht das GOLDi System (Dieser Teil kann auch ein bisschen technischer sein) <br /><br /> **IMAGE:** <br/> Image, um Aufbau von Remote Labor / GOLDi zu veranschaulichen. | Nutzer **<u>kann</u>** das Remote Labor und GOLDi System besser verstehen. | mittel |
| Working Features Vorstellung | **TEASER:** <br />kleine Auflistung von aktuellen in Working Features | Product Owner **<u>kann</u>** mit den neuen Funktionen Nutzer-Interesse aufwecken | niedrig |

#### Kategorie: Dokumentation / Anleitung & Technische Information

| Content | Content Typen / Format | Ziel | Pflegebedarf |
| ------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ---------------------------------------------- |
| Anleitung von Experiment | **ARTIKEL:** <br />detaillierte Anleitung der Experiment-Ausführung. Dieser Text soll sinnvoll strukturiert werden und durch Zwischenüberschriften gegliedert werden. Um die Lesbarkeit zu verbessern, gerne Liste verwenden (aber bitte einheitlich, einer zu sehr verschachtelte Liste kann auch kein Nutzer folgen). Wenn der Artikel zu lang wird, ist ein Inhaltsverzeichnis dazu hilfreich.<br /><br />**IMAGE:** <br />Image mit Beschriftung (Figcaption ist gewünscht, aber wenn es nicht entsprechend referenziert wird, muss nicht unbedingt nummeriert werden) | Nutzer <u>**muss**</u> wissen, wie er auf GOLDi ein Experiment ausführen kann. | mittel |
| Auflistung Q&A zum Experiment Ausführung | **ACCORDION:** <br />Troubleshooting / häufig gestellte Fragen, die erst nach Wunsch von Nutzer auf- oder zugeklappt werden. (platzsparend für voneinander unabhängige Detailinformationen) | Nutzer <u>**soll**</u> die Möglichkeit haben, die bereits existierenden Probleme und Lösungen selbst zu finden. Aber nicht jeder Nutzer hat die gleichen Fragen, daher als Accordion. | mittel |
| Vorstellung der jeweiligen Versuchsobjekte (CU & PS) | **ARTIKEL:** <br />detaillierte Beschreibung des Versuchsobjekts: Was ist das? Was kann man damit machen? Mit welchen anderen Versuchsobjekten kann es kombiniert werden (mit **VERLINKUNG** als Cross Reference)<br /><br />**IMAGE:** <br />Bilder von Versuchsobjekten <br /><br /> **CTA:** <br />Weiterleitung auf Experiment-Auswahl (Starten) DOWNLOAD: Technische Spezifikation (z.B. von Hersteller, oder besonderen Modellen) & Beispiele <br /><br />**ACCORDION:** <br />häufigsten gestellten Fragen | Nutzer <u>**muss**</u> wissen, was er mit Versuchsobjekten machen kann. | hoch |
| Vorstellung BEAST | **TEASER:** <br />Kurze Vorstellung von BEAST: Was ist das? Was kann das? Wie funktioniert es? <br /><br />**IMAGE:** <br />entsprechende Bilder dazu (GUI, Funktionen, etc.) <br /><br />**VIDEO:** <br />optionale Videoanleitung<br /><br />**CTA:** <br />direkte Weiterleitung auf BEAST | Nutzer <u>**muss**</u> wissen, was er mit diesem Tool machen kann und er muss auf die Seite weitergeleitet werden. | [ohne Video]: mittel <br />[mit Video]: hoch |
| Vorstellung GIFT | **TEASER:** <br />Kurze Vorstellung von GIFT: Was ist das? Was kann das? Wie funktioniert es? <br /><br />**IMAGE:** <br />entsprechende Bilder dazu (GUI, Funktionen, etc.) <br /><br />**VIDEO:** <br />optionale Videoanleitung<br /><br />**CTA:** <br />direkte Weiterleitung auf GIFT | Nutzer <u>**muss**</u> wissen, was er mit diesem Tool machen kann und er muss auf die Seite weitergeleitet werden. | [ohne Video]: mittel<br /> [mit Video]: hoch |
| Vorstellung SANE | **TEASER:** <br />Kurze Vorstellung von SANE: Was ist das? Was kann das? Wie funktioniert es? <br /><br />**IMAGE:** <br />entsprechende Bilder dazu (GUI, Funktionen, etc.) <br /><br />**VIDEO:** <br />optionale Videoanleitung<br /><br />**CTA:** <br />direkte Weiterleitung auf SANE | Nutzer <u>**muss**</u> wissen, was er mit diesem Tool machen kann und er muss auf die Seite weitergeleitet werden. | [ohne Video]: mittel <br />[mit Video]: hoch |
| Vorstellung WIDE | **TEASER:** <br />Kurze Vorstellung von WIDE: Was ist das? Was kann das? Wie funktioniert es? <br /><br />**IMAGE:** <br />entsprechende Bilder dazu (GUI, Funktionen, etc.) <br /><br />**VIDEO:** <br />optionale Videoanleitung<br /><br />**CTA:** <br />direkte Weiterleitung auf WIDE | Nutzer <u>**muss**</u> wissen, was er mit diesem Tool machen kann und er muss auf die Seite weitergeleitet werden. | [ohne Video]: mittel [mit Video]: hoch |
| Beispiele von jeweiligem Tool | **ARTIKEL:** <br />Vorstellung vom Beispiel: Worum geht das Beispiel? Und ggf. Syntax erklären<br /><br />**DOWNLOAD:** <br />als Datei Import | Nutzer <u>**muss**</u> verstehen, was das Beispiel zeigt und was er damit machen kann. Nutzer soll die Beispiele als Datei zur Verfügung gestellt bekommen. | hoch (evtl. hohe Anzahl von Beispielen) |

### Basic Anforderung

* Eindeutige Seitentitel
* Aussagekräftige, knackige Headline
* Überschriften sollten auf Code-Ebene entsprechend als Überschrift `<h1>, <h2>, <h3>` usw. ausgezeichnet werden und Überschriftenhierarchie beachten
* Einfache, leicht verständliche Sprache
* Abkürzungen & Akronyme ausschreiben
* Listen mit Aufzählungszeichen bzw. mit Nummerierung (Liste nicht durch die Eingabe von Bindestrichen erzeugen)
* Alternativtexte für Bilder pflegen (Ausnahme: Schmuckbildern)
* Externe Links als solche kennzeichnen

## Funktionale Spezifikation

### Existierende Funktionalitäten

#### Login & Registerung

| Existierende Aktivitäten / Funktionalitäten, <br>die behalten und optimiert werden sollen |  Pros |  Optimierungsbedarf |
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| Registrierung | Voraussetzung für weitere Aktivitäten.<br><br>Sehr leicht zu finden.<br><br>Direkte Fehlermeldung als Response für Nutzer Aktion. | Kein Validator direkt bei der Eingabe von Daten => Es wird alles bei Submit gemacht, aber kann optimiert werden, Nutzer muss nicht erst am Ende wissen, dass er etwas Falsches eingegeben hat.<br><br>Datenschutzerklärung Validierung kommt nicht erst, wenn alle anderen Felder korrekt ausgefüllt sind. |
| Login | Voraussetzung für weitere Aktivitäten.<br><br>Login Formular ist direkt auf Header => kann immer gesehen werden und Nutzer spart einen Schritt.<br><br>Direkte Fehlermeldung als Response für Nutzer Aktion. | Login Formular im Header verwendet Placeholder anstatt Label => Nutzer weiß nicht mehr, wofür das Input-Feld ist.<br><br>Nutzername ist verlangt, aber nicht jeder Nutzer hat einen Nutzername (nur die von TU-Ilmenau haben generierte Nutzernamen). Es verwirrt die externen Nutzer.<br><br>Auf Login Seite wird noch die Option “Registrieren“ ohne weitere Beschriftung angezeigt. (Tab Bedienung funktioniert korrekt, aber es entspricht nicht der optischen Reihenfolge). |
| Logout | Sieht gut aus, wird statt “Einloggen” und “Registrieren” bei eingeloggtem Zustand angezeigt. | |
| Passwort zurücksetzen | Nützliche Funktion & ist immer auf Login Seite.<br><br>Direkte Fehlermeldung als Response für Nutzer Aktion. | Nutzername wird verlangt, aber nicht jeder Nutzer hat einen Nutzernamen (nur die von der TU-Ilmenau haben generierte Nutzernamen). Es verwirrt die externen Nutzer. |
| Passwort ändern | Nützliche Funktion.<br><br>Direkte Fehlermeldung als Response für Nutzer Aktion. | Der Weg ist nicht intuitiv. Nutzer muss auf seinen Name klicken (wenn überhaupt erkannt wird, dass dieser Button klickbar ist).<br><br>Entspricht nicht dem bereits erlernten Nutzerverhalten. |

#### Experiment Ausführung & Reservierung

| Existierende Aktivitäten / Funktionalitäten, <br>die behalten und optimiert werden sollen |  Pros |  Optimierungsbedarf |
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| Experiment Standort auswählen | Zeigt einen Überblick von Kooperationen mit anderen Universitäten. | Sehr häufig sind alle Optionen ausgegraut.<br><br>Auflistung von Bildern (mit Verlinkung) ist viel zu lang und nimmt viel Platz weg. (Nutzer verliert das Interesse).<br><br>IUT kann trotz des ausgegrauten Status verwendet werden, während weitere Standorte nur Server Error bekommen.<br><br>Der Nutzer hat eigentlich kein Interesse am Standort, an dem das Experiment ausgeführt wird. Hauptsache das Experiment wird ausgeführt. |
| CU und PS für das Experiment auswählen | Dass der Nutzer gewisse Versuchsobjekte nicht kombinieren kann (durch Ausgrauen von Elementen), ist gut dargestellt. | Fehlende Begründung => wieso gewisse Versuchsobjekte nicht kombiniert werden dürfen. (Vielleicht können virtuelle Versuchobjekte trotzdem ausgewählt werden?)<br><br>Ungewöhnliche Farbauswahl (Orange zeigt den Status “ausgewählt”, dabei ist ein rötliche Farbe eher als Vorboten suggeriert).<br><br>Fehlende Informationen von jeweiligen Versuchsobjekten. |
| Auswahl zwischen realen oder virtuellen Versuchsobjekten | Viele Nutzer finden es super / interssant, dass auf GOLDi auch reale Versuchsobjekte zu sehen sind. | Switch zwischen real oder virtuell ist nicht wirklich auf ersten Blick zu erkennen.<br><br>Ungewöhnliche Farbauswahl. |
| Experiment starten | Hauptfunktion der Webseite. | Kann nicht direkt gefunden werden (Nutzer muss sich zuerst einloggen, um den Navigationspunkt überhaupt zu sehen)<br><br>Button “Experiment Starten” kann auch vor Auswahl von Versuchsobjekten angezeigt werden (aber als disabled). Sonst erkennt der Nutzer nicht sofort, was hier gemacht werden kann. |
| Experiment reservieren | Bietet Nutzer die Möglichkeit, Termin und Dauer für Experimente mit gewünschten Versuchsobjekten zu reservieren.<br><br>Hilfe als Interaktionsmöglichkeit (Button) bereits angelegt. | Wieso lassen sich einige Versuchsobjekte nicht reservieren?<br><br>Button “Experiment Reservieren” kann auch vor der Auswahl von Versuchsobjekten angezeigt werden (aber als disabled). Sonst erkennt der Nutzer nicht sofort, was hier gemacht werden kann.<br><br>Nutzer erkennt nicht sofort, wo er eine Reservierung machen kann (Es existiert bereits ein Navigationspunkt “Reservierung“, bei dem allerdings nur die reservierten Termine vom Nutzer angezeigt werden).<br><br>Zeitdauer für Reservierung kann auch direkt per input eingegeben werden.<br><br>Zeitpunkt (Startzeit) von Reservierung durch Drag & Drop auszuwählen ist sehr ineffizient.<br><br>Kalender Input soll validiert werden (Eingabe nur als Datum).<br><br>Ausgewähltes Datum im Kalender hat sehr schlechten Kontrast (1.16 ist nicht ausreichend), Nutzer kann es sehr schlecht erkennen.<br><br>Noch nicht reservierter Termin sieht auf der Zeitleiste wie bereits reserviert aus. Schwierig zu erkennen, dass Nutzer erfolgreich reserviert hat. (Fehlende Response).<br><br>Reservierung wird in einem Dropdown angezeigt, welches die meisten Nutzer übersehen. |
| An reserviertes Experiment erinnern, sodass der Nutzer das Experiment startet | Nützliche Funktion. | Nutzer klickt auf “Cancel“, wird dieses Popup nochmal auftauchen nach Reload. |

#### Allgemeine Funktionen auf der Seite

| Existierende Aktivitäten / Funktionalitäten, <br>die behalten und optimiert werden sollen |  Pros |  Optimierungsbedarf |
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| Sprache auswählen | Bietet dem Nutzer die Möglichkeit, zwischen 6 Sprachenoptionen auszuwählen. | Zu viel Sprachen, die aber nicht konsistent umgesetzt sind (vieles noch auf Englisch).<br><br>Icon “Flagge“ gibt Nutzer keinen Hinweis, dass man hier die Sprache wechseln kann.<br><br>Aktuelle Sprache ist nicht direkt angezeigt, muss man erst auf das Flaggen Icon klicken, um es zu sehen.<br><br>Cursor bei Hover ist komisch. |
| Experiment zuschauen | Bietet dem Nutzer die Möglichkeit, aktuell laufenden Experimenten zuzuschauen. | Einige Nutzer möchten nicht unbedingt, dass ihnen bei der Experiment-Ausführung zugeschaut wird. |

#### Allgemeine Funktionen bei Werkzuegen

| Existierende Aktivitäten / Funktionalitäten, <br>die behalten und optimiert werden sollen |  Pros |  Optimierungsbedarf |
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| Import & Export von Projekten | Bietet dem Nutzer die Möglichkeit, eigene Projekte zu in- und exportieren. | Unterschiedliche Darstellung im jeweiligen Werkzeug.<br><br>Keine einheitliche Platzierung. |
| Bedienung (Projekte und Komponenten erzeugen und etc.) | Hauptaufgaben von Werkzeugen. | Unterschiedliche Darstellung im jeweiligen Werkzeug.<br><br>Keine einheitliche Platzierung. |
| Local Storage | Bietet Nutzer die Möglichkeit, direkt den Arbeitsstand wieder aufzurufen (ohne noch eine extra Aktion ausführen zu müssen). | |
| Sprache welchseln | Bietet Nutzer die Möglichkeit, zwischen Englisch und Deustch auszuwählen. | Unterschiedliche Darstellung im jeweiligen Werkzeug.<br><br>Keine einheitliche Platzierung. |
| Einstellung | Bietet Nutzer die Möglichkeit, einige Einstellung zu setzen. | Unterschiedliche Darstellung im jeweiligen Werkzeug.<br><br>Keine einheitliche Platzierung.<br><br>Allgemeine Einstellungen und technische Einstellungen sind noch nicht getrennt. |
| Beispiel laden | Bietet Nutzer die Möglichkeit, vorbereitete Beispiele zu verwenden. | Es soll mehr Beispiele geben. |

### Geplante neue Funktionalität

| **Geplante Aktivität / Funktionalität** |  **Hypothetische Pros** |  Hypothetische Cons |
| :-------------------------------------- | :----------------------------------------------------------- | ------------------------------------------------------------ |
| Nutzer Profil / Bereich | Zusammenfassung von Nutzer Aktivitäten (Passwort anpassen, Reservierung, etc.) => besser zu finden. | |
| Regel- / Gruppen-Termin erstellen | Ist in der Vorlesung immer direkt reserviert.<br><br>Termin Teilen mit einer Gruppe / Zenturie. | Aufwendige Entwicklung + Pflegeaufwand. |
| Notifikation für Events | Benachrichtigung von aktuellen / zukünftigen / verpassten Events (z.B. Reservierung)<br><br>Kann Termin an eine Gruppen schicken | |
| Kontakt Formular / Möglichkeit | Möglichkeit für Problem / Fehlermeldung Meldung.<br><br>Besser zu pflegen / antworten (durch allgemeinen Kommunikationskanal) | Aufwendige Entwicklung + Pflegeaufwand. |

## Informationsarchitektur & Navigationsstruktur

Für die Informationsarchitektur haben wir uns, aufgrund einer vereinfachten Navigation für den Nutzer, für eine flache Hierarchie entschieden.

- **Benutzeraccount**
- **Nebeninformationen**
- **Hauptfunktionalität**


Der **Benutzeraccount** bereich wurde dabei vollständig überarbeitet und um mehrere Seiten ergänzt, die eigene Informationen und Funktionalität aufweisen. Diese können folgendermaßen aufgegliedert werden:

- Login
- Mein Account
- Passwort ändern
- Email ändern
- Account löschen
- Registrieren
- Login
- Passwort / Benutzername vergessen

Der **Nebeninformationsbereich** umfasst alle Funktionalitäten und Informationen, die nicht direkt für das Erstellen eines Experimentes von Bedeutung sind, oder aufgrund von Richtlinien vorhanden sein müssen.

- Kontakt
- Datenschutz
- Impressum
- About Us
- FAQ

Die **Hauptfunktionalität**, welche die Anwendung zur Verfügung stellt, wird unter folgenden Punkten aufgegliedert:

- Dokumentation
- Guide Werkzeuge
- BEAST
- GIFT
- SANE
- WIDE
- Guide Experiment
- Erklärung Physisches System
- Manuelle Steuerung
- Digitales Demo-Board
- PLD (Programmable Logic Device)
- Automatengraph
- Microcontroller
- Experiment
- Experiment Start / Reservierung
- Experiment Control Panel
- Meine Reservierung
- Reservierung Überarbeiten
- Werkzeuge
- BEAST
- GIFT
- SANE
- WIDE

### Globale Navigationsstruktur - Auf jeder Seite

### Lokale Navigationsstruktur mit Verlinkung miteinander

## Szenarien

### Landing

#### Aufgabenstellung

Dem Nutzer sollen auf den ersten Blick die Marken- und Funktionsangebote der GOLDi Webseite aufgezeigt werden, um von den Funktionsangeboten überzeugt zu werden. Gleichzeitig soll der Nutzer die Möglichkeit haben, direkt über die Kern-Funktionalitäten mehr zu erfahren.

#### Konzeptbeschreibung
* Über die Startseite sollen alle globale Navigationsknoten erreichbar sein
* Die allgemeinen Funktionen wie z.B. Login oder Sprachumschaltung sollen immer verfügbar sein
* Willkommentext als kleine Einleitung
* Kern-Funktionalitäten als Teaserliste zeigen

#### Workflow

----

##### Szenario - Sprache umschalten

<u>**Userflow:**</u>

- Nutzer ist auf der Werkzeug-Seite (Default Sprache: Englisch)
- Nutzer möchte gerne auf Deutsch wechseln
- **Nutzer klickt auf Sprache Button**

<u>**Ergebnisse:**</u>

- Nutzer hat die Seite auf Deutsch eingestellt

<u>**Error Prevention & Handling:**</u>

- Sprache Button soll entsprechendes Icon haben → Icon "Globe”, oder sogar ohne Icon, nur mit Standard Switch → DE | EN
- Die aktuell ausgewählte Sprache ist als aktiv angezeigt

----

##### Szenario - Kontaktaufnahme / Problem melden

<u>**Userflow:**</u>

- Nutzer hat einen Bug auf der GOLDi Seite gefunden und möchtet diesen Bug berichten
- Nutzer klickt auf den Button "Kontakt"
- Nutzer wird auf eine Seite mit Kontakt Formular weitergeleitet
- **Nutzer gibt die angeforderten Daten ein (Name, E-Mail, Nachricht)**
- **Nutzer akzeptiert die Datenschutzbestimmung der Webseite**
- **Nutzer klickt auf Button "Formular abschicken"**

<u>**Ergebnisse:**</u>

- Nachricht wird an GOLDi geschickt

<u>**Error Prevention & Handling:**</u>

- Nutzer bekommt eine E-Mail Bestätigung, dass GOLDi diese Nachricht erhalten hat
- Formular soll wie immer mit Input und Label versehen und während Eingabe validiert werden
- Pflichtfeld soll gekennzeichnet werden

---

#### Wireframe

---


---

### Login & Registrierung

#### Aufgabenstellung
Die Ausführung und Reservierung des Experiments können nur eingeloggte Nutzer bedienen. Die TU-Nutzer müssen sich nicht registrieren, sie bekommen einen generierten Benutzernamen von der TU-Ilmenau und können sich damit einloggen. Andere Nutzer müssen sich einen Account dafür einrichten, diese Art von Accounts haben keinen Benutzernamen. Eingeloggte Nutzer können auf den Profil-Bereich gehen und dort die Aktionen, wie z.B. Passwort ändern oder Account löschen, ausführen.

#### Konzeptbeschreibung
* Die Formulare sollen entsprechend Label, Input und Placeholder haben
* Während der Eingabe findet eine Validierung statt
* Bei einigen Vorgängen soll der Nutzer eine E-Mail z.B. als Bestätigung erhalten
* Datenschutzbestimmung muss beachtet werden

#### Workflow

----

##### Szenario - Registrierung

<u>**Userflow:**</u>

- Nutzer ist auf Startseite
- Nutzer möchte sich Registrieren (kein Uni Account)
- **Nutzer klickt auf Registrieren und gibt seine Daten ein**
- **Nutzer gibt angeforderte Daten ein**
- **Nutzer bestätigt die Datenschutzbestimmung**
- **Nutzer submittet das Registrierungsformular**
- Nuzter bekommt eine E-Mail als Bestätigung
- **Nutzer klickt auf den Bestätigungslink**

<u>**Ergebnisse:**</u>

- Nutzer hat sich Registriert

<u>**Error Prevention & Handling:**</u>

- Invalide Daten werden direkt hervorgehoben → E-Mail, Passwort, Datenschutz
- Nutzer soll direkt nach dem Registrieren eingeloggt werden

---

##### Szenario - Passwort vergessen

<u>**Userflow:**</u>

- Der Nutzer gibt seine Login Daten ein und klickt auf einloggen
- **Nutzer klickt auf Passwort vergessen**
- **Nutzer gibt Nutzernamen / E-Mail ein**
- **Nutzer bekommt E-Mail mit Link um neues Passwort zu setzen**
- **Nutzer gibt neues Passwort ein und wiederholt dieses**
- **Nutzer klickt auf "Passwort bestätigen"**

<u>**Ergebnisse:**</u>

- Passwort ist erfolgreich zurückgesetzt

<u>**Error Prevention & Handling:**</u>

- Benutzername / E-Mail Label → Nutzer weiß, was der Nutzername ist (bei externen Nutzern)
- "Zurück" Button um Vorgang abzubrechen
- Nutzer soll nach Zurücksetzen vom Passwort direkt eingeloggt werden

----

##### Szenario - Login

<u>**Userflow:**</u>

- **Nutzer gibt seine Login Daten ein**
- **Nutzer bestätigt die Datenschutzbestimmung**
- **Nutzer drückt "Login"**

<u>**Ergebnisse:**</u>

- Nutzer hat sich eingeloggt
- Aktuell angemeldeter Nutzer wird angezeigt

<u>**Error Prevention & Handling:**</u>

- Benutzername / E-Mail Label → Nutzer weiß, was der Nutzername ist (bei externen Nutzern)
- Wenn der Nutzer nach einer bestimmten Zeit ausgeloggt werden soll, bietet es sich an, dass ein Session-Timeout Modal mit entsprechenden Informationen, z.B. "Für ihre Login-Zeit verbleiben noch 10 Minuten" und die Handlungsmöglichkeit Login Status zu verlängern
- Nach Login soll Nutzer auf die vorherige Seite weitergeleitet werden

---

##### Szenario - Passwort ändern

<u>**Userflow:**</u>

- **Nutzer klickt auf Nutzer Profil**
- **Nutzer klickt auf Option "Passwort ändern"**
- **Nutzer gibt neues Passwort ein und wiederholt dieses**
- **Nutzer klickt auf "Passwort ändern"**

<u>**Ergebnisse:**</u>

- Nutzer hat sein Passwort geändert

<u>**Error Prevention & Handling:**</u>

- Invalide Daten werden direkt angezeigt → unzulässiges Passwort / fehlerhafte Eingabe
- Nach erfolgreicher Passwort-Änderung soll Nutzer eine Push-Notification und E-Mail als Bestätigung erhalten

----

#### Wireframe


### Experiment Ausführung

#### Aufgabenstellung

Experimente mit unterschiedlichen Versuchsobjekten ist die wichtigste Funktion auf GOLDi. Der Nutzer kann hier beliebig Experimente konfigurieren und möglichst schnell verwandte Inhalte finden. Wenn das Experiment gestartet ist, wird das Experiment Control Panel angezeigt. Nutzer kann dort Experimente ausführen.

#### Konzeptbeschreibung
* Experimente dürfen nur durch eingeloggte Nutzer konfiguriert werden, nicht eingeloggte Nutzer sollen einen Hinweis dazu bekommen
* Experiment Konfiguration sollte schrittweise stattfinden
* Experiment kann per Link oder Einladung geteilt werden
* Nutzer soll die Beschreibung / Anleitung vom Experiment und Versuchsobjekte im Experiment Control Panel zur Verfügung stehen

#### Workflow

----

##### Szenario - Experiment starten

<u>**Userflow:**</u>

- Nutzer ist auf der Oberfläche von Experiment starten
- **Nutzer wählt den verfügbaren Standort vom Versuchsobjekt aus**
- Standort ist ausgewählt
- **Nutzer wählt die Steuereinheit für das Experiment aus**
- Steuereinheit ist ausgewählt
- **Nutzer wählt das physische System für das Experiment aus**
- Physisches System ist ausgewählt
- Nutzer möchte ein reales physisches System auswählen
- **Nutzer wechselt von "virtuell" auf "real"**
- Physisches System ist auf "real" eingestellt
- **Nutzer klickt auf "Experiment starten" Button**
- <u>*Wenn der Nutzer das Experiment mit weiteren Personen teilen möchtet:*</u>
- **Nutzer hat hier zwei Möglichkeiten**
- **Link-Einladung kopieren und teilt diesen direkt an die Personen**
- **Nutzer gibt die E-Mail-Adressen von eingeladenen Personen ein und klickt den "Bestätigung" Button**

<u>**Ergebnisse:**</u>

- Nutzer hat Experiment mit ausgewählten Versuchsobjekten gestartet (und wird weitergeleitet)
- Nutzer hat Experiment mit weiteren Personen geteilt

<u>**Error Prevention & Handling:**</u>

- Auswahl von Standorten soll es nur geben, wenn mehr als ein Experiment Standort verfügbar ist
- Informationen von jeweiligen Versuchsobjekten sollen verfügbar sein (entweder durch Verlinkung Pop-Overs oder aufklappbares Accordion)
- Nicht ausgewählte Versuchsobjekte sollen als disabled (ausgegraut) angezeigt werden
- Nicht kombinierbare Paare sollen gekennzeichnet werden (sieht anders aus als ausgegraut)
- Prozess von Experiment starten soll veranschaulicht werden
- Noch nicht betretende Prozesse ausgrauen
- Prozesse sollen nummeriert werden (Alternativ: Progress-Bar)
- "Experiment starten" Button soll immer vorhanden sein, je nach Status aber disablen
- Switch für "virtuell" und "real" bei Versuchsobjekten soll sichtbarer sein (durch entsprechende Elemente wie "Select / Combobox" oder "Radio Button Groups")
- Wenn keine "realen" Versuchobjekte verfügbar sind, darf keine Auswahlmöglichkeit angezeigt werden

---

#### Wireframe

### Termin Reservierung

#### Aufgabenstellung
Da auch reale Versuchsobjekte vorhanden sind, gibt es die Möglichkeit, konfigurierte Experimente zu reservieren. Es gibt drei verschiedene Arten von Termin-Reservierungen:
* Standard Reservierung
* Gruppen Reservierung - ideal für Gruppenarbeit
* Wiederholte Reservierung - ideal für Vorlesung

#### Konzeptbeschreibung
- Die Reservierung lässt sich bearbeiten und löschen
- Gruppen Termin kann auch nachträglich angepasst werden
- Teilen des reservierten Experiments kann über eine Einladung oder generierten Link erfolgen
- Reservierungen sollen übersichtlich dargestellt werden, evtl. mit Kalender
- Möglichkeit für Erinnerung des reservierten Termins

#### Workflow

----

##### Szenario - Experiment reservieren

<u>**Userflow:**</u>

- Nutzer ist auf der Oberfläche der Experiment Reservierung
- **Nutzer wählt den verfügbaren Standort vom Versuchsobjekt aus**
- Standort ist ausgewählt
- **Nutzer wählt die Steuereinheit für das Experiment aus**
- Steuereinheit ist ausgewählt
- **Nutzer wählt das physische System für das Experiment aus**
- Physisches System ist ausgewählt
- **Nutzer klickt auf den Button "Experiment reservieren"**
- Nutzer wird auf die Terminvereinbarungsseite weitergeleitet
- **Nutzer wählt das Datum aus**
- **Nutzer gibt den Startzeitpunkt ein**
- **Nutzer gibt die Reservierungsdauer ein**
- *<u>Wenn der Nutzer nur einen Termin für sich reservieren möchte:</u>*
- **Nutzer passt die entsprechende Einstellungen für Regeltermin an**
- **Nutzer klickt auf den Button "Reservieren"**
- *<u>Wenn der Nutzer einen Gruppentermin reservieren möchte:</u>*
- **Nutzer passt die entsprechende Einstellungen für Gruppentermin an**
- **Nutzer gibt die E-Mail-Adressen von den Teilnehmern an**
- **Nutzer klickt auf den Button "Reservieren"**

<u>**Ergebnisse:**</u>

- Nutzer hat den Termin mit gewünschten Versuchsobjekten reserviert
- Nutzer bekommt diesen Termin auf seinem Kalender im "Meine Reservierung" Bereich angezeigt
- Nutzer kann diesen Termin als .ics herunterladen
- Eingeladene Nutzer bekommt eine E-Mail für den Termin (auch mit .ics) und kann den Termin zusagen

<u>**Error Prevention & Handling:**</u>

- Auswahl von Versuchsobjekten soll analog obigen Punkten sein
- Die Versuchsobjekte, die sich nicht reservieren lassen, sollen ein Pop-over mit der Begründung haben (oder ausblenden)
- Aktuelles Datum und ausgewähltes Datum sollen auf Kalender Input sichtbar und unterscheidbar sein
- Auswahl von Startzeit durch Input und die Reservierungsdauer durch Dropdown mit vorgegebenem Zeitintervall (z.B. 15 min, 30 min, 45 min)
- Inputfelder sollen immer ein Label haben, ggf. können sie auch ein Tooltip neben dem Label als zusätzliche Hilfe anbieten
- Input soll während der Eingabe validiert werden
- Nach erfolgreicher Reservierung soll es eine Push-Notification geben
- Die reservierten Termine sollen im Kalender angezeigt werden und entsprechend soll der Nutzer Event Benachrichtigungen erhalten

---

##### Szenario - Reservierung anpassen

<u>**Userflow:**</u>

- Nutzer hat einen eigenen Termin reserviert und ist auf der Seite "Meine Reservierung"
- **Nutzer klickt auf den "Bearbeiten" Button neben der Reservierung**
- **Nutzer passt die Einstellungen an**
- **Nutzer klickt auf den "Speichern" Button**

<u>**Ergebnisse:**</u>

- Angepasste Reservierung ist gespeichert

<u>**Error Prevention & Handling:**</u>

- Wenn der Button nur mit Icon versehen ist, soll es einen passenden Mouseover Text geben (title attribute)
- Wenn die Reservierung erfolgreich angepasst ist, soll es eine Push-Notification geben (Nutzer soll Push-Notification ein- und ausschalten können)

---

##### Szenario - Reservierung löschen

<u>**Userflow:**</u>

- Nutzer hat einen eigenen Termin reserviert und ist auf der Seite "Meine Reservierung"
- **Nutzer klickt auf den "Löschen" Button neben der Reservierung**
- Nutzer wird nach Bestätigung gefragt, ob er wirklich den Termin löschen möchte
- **Nutzer klickt auf den "Termin löschen" Button**

<u>**Ergebnisse:**</u>

- Termin ist gelöscht

<u>**Error Prevention & Handling:**</u>

- Bei Löschen eines Termins soll es immer ein Bestätigungsmodal mit Optionen "Abbrechen" und "Termin löschen" geben
- Wenn der Termin erfolgreich gelöscht ist, soll es eine Push-Notification geben (Nutzer soll Push-Notification ein- und ausschalten können)

---

##### Szenario - Termin Benachrichtigung

<u>**Userflow:**</u>

- Nutzer ist auf GOLDi Seite und hat bereits einen Termin in 30 Minuten
- Nutzer bekommt auf der Seite ein Push-Notification Modal mit Optionen "Alles klar" und "5 Minuten vor den Termin nochmal erinnern"
- **Nutzer klickt auf Button "5 Minuten vor den Termin nochmal erinnern"**
- Nutzer bekommt 5 Minuten vor seinem Termin erneut den Modal mit Option "Alles klar"
- **Nutzer klickt auf "Alles klar"**

<u>**Ergebnisse:**</u>

- Nutzer bekommt nicht nochmal das Push-Notification Modal

<u>**Error Prevention & Handling:**</u>

- Nutzer soll Push-Notification ein- und ausschalten können
- Wenn möglich, soll die Zeit für Erinnerung einstellbar sein (1 min vor Termin, 5 min vor Termin, etc.)
- Wenn Nutzer auf "Alles klar" geklickt hat, die Seite verlässt und in ein paar Minuten wieder die Seite besucht, soll die Push-Notification nicht nochmals auftauchen.

----

#### Wireframe

### Werkzeugverwendung

#### Aufgabenstellung
Standalone Werkzeuge können vielfältig verwendet werden. Studierende oder Lehrkräfte müssen sich dafür nicht anmelden, sondern die Werkzeuge können direkt verwendet werden. Daher sollte es die Möglichkeit zum Im- und Export vom Projekten geben.

#### Konzeptbeschreibung
* Alle Werzeug GUIs sollen ähnlich aufgebaut werden (d.h. ähnliche oder selbe Funktionen an gleicher Stelle)
* Die Bedienung soll gelerntem Nutzerverhalten entsprechen

#### Workflow

---

##### Szenario - Werkzeug verwenden (allgemein)

<u>**Userflow:**</u>

- Nutzer möchte das Werkzeug verwenden
- Nutzer findet die Bedienungsleiste mit verschiedenen Aktionen
- **Nutzer klickt auf den Button und führt gewünschte Aktion aus**

<u>**Ergebnisse:**</u>

- Gewünschte Aktion ist ausgeführt

<u>**Error Prevention & Handling:**</u>

- Buttons, die nur aus einem Icon bestehen, sollen einen Mouseover Text als zusätzliche Beschriftung haben
- Wenn eine Aktion nicht ausgeführt werden kann, soll der Button disabled sein
- Wenn ein Button disabled ist, soll eine Begründung angezeigt werden
- Während der Verwendung vom Werkzeug wird das bearbeitete Projekt / Inhalt in Local Storage gespeichert

---

##### Szenario - Exportieren

<u>**Userflow:**</u>

- Nutzer verwendet das Werkzeug
- Nutzer möchtet den aktuellen Zustand vom Projekt exportieren
- **Nutzer klickt auf Menüpunkt "Datei"**
- Menüpunkt "Datei" ist geöffnet
- **Nutzer klickt auf Menüunterpunkt "Exportieren"**
- Modal von "Exportieren" mit weiteren Einstellungsmöglichkeit ist geöffnet
- **Nutzer passt die gewünschten Einstellungen an (z.B. Dateiname)**
- **Nutzer klickt auf Button "Exportieren"**

<u>**Ergebnisse:**</u>

- Nutzer hat das Projekt mit gewünschten Einstellungen exportiert

<u>**Error Prevention & Handling:**</u>

- Es soll einen "Abbrechen" Button geben, für den Fall, dass der Nutzer den Export-Vorgang abbrechen möchte
- Nach erfolgreichem Export des Projekts soll eine Push Notification angezeigt werden

---

##### Szenario - Importieren

<u>**Userflow:**</u>

- Nutzer verwendet das Werkzeug
- Nutzer möchte den Projektzustand von letzter Bearbeitung wiederherstellen
- **Nutzer klickt auf Menüpunkt "Datei"**
- Menüpunkt "Datei" ist geöffnet
- **Nutzer klickt aud Menüunterpunkt "Importieren"**
- File-Upload ist geöffnet
- **Nutzer wählt das zu importierende Projekt aus**
- **Nutzer klickt auf Button "Importieren"**

<u>**Ergebnisse:**</u>

- Nutzer hat den Projektzustand wiederherstellt

<u>**Error Prevention & Handling:**</u>

- Es soll einen "Abbrechen" Button geben, für den Fall, dass der Nutzer den Import-Vorgang abbrechen möchte
- File-Upload soll direkt validiert werden (z.B. Datei-Format, Datei-Größe)
- Nach erfolgreichem Import des Projekts soll eine Push Notification angezeigt werden

---

##### Szenario - Beispiel laden

<u>**Userflow:**</u>

- Nutzer möchte gerne ein vorhandenes Beispiel im Werkzeug laden
- **Nutzer klickt auf Menüpunkt "Beispiel laden"**
- Modal ist geöffnet und dort sind mehrere Beispiele vorhanden
- **Nutzer wählt auf Option "Beispiel XXX" aus**
- **Nutzer klickt auf Button "Laden"**

<u>**Ergebnisse:**</u>

- Beispiel wird geladen

<u>**Error Prevention & Handling:**</u>

- Wenn der Nutzer bereits etwas in Arbeit hat, soll gefragt werden, ob Nutzer das aktuelle Projekt speichern möchte
- Die Beispiele sollen eine Anleitung haben (ggf. als README)

---

#### Wireframe


## Generische Stile

### Layout
Die GOLDi Website folgt einem flexiblen Layoutsystem mit 2 Viewports (Responsive Web Design), da die Remote-Labor Funktionen hauptsächlich auf einem Desktop-PC verwendbar sind:
* Tablet (sm-md) < 992px
* Desktop (lg) >= 992px

Für die Entwicklung gilt
#### Desktop Dartellung

#### Tablet Darstellung

### Farben (TODO)
Ziel: Farben von der GOLDi Webseite (unter Berücksichtigung der Branding)

<u>**Checkliste**</u>
- [ ] **Primärfarben** zur Gestaltung von graphischen Elementen wie Hintergrundflächen (z.B. Header, Footer, Button)
- [ ] **Textfarben** (z.B. Dunkelgrau, Schwarz)
- [ ] **Signalfarben** für die Kennzeichnung von Zuständen oder für Hinweise verwenden
- [ ] Erfolg / Positiv
- [ ] Warnung
- [ ] Fehler / Negativ

### Typographie (TODO)
Ziel: Übersichtliche Texthierachie

<u>**Checkliste**</u>
- [ ] Schriftarten (z.B. Arial)
- [ ] Schriftgröße, Zeilenabstände und Schriftschnitt
- [ ] Headline H1
- [ ] Headline H2
- [ ] Headline H3
- [ ] Headline H4
- [ ] Copy-/Lesetext

### Basiselemente (TODO)
Ziel: Einheitliches und wiederverwendbares Design

<u>**Checkliste**</u>
- [ ] Häufig verwendete Elemente sollen wiederverwendbar sein (Einheitliches Design und Funktionsweise)
- [ ] Links
- [ ] Buttons
- [ ] Formular (Input, Label, etc.)
- [ ] Push-Notifications (z.B. Toasts)
- [ ] Modal
- [ ] Icons (immer gleiche Icon Library benutzen, wie z.B. Material Design Icons oder Font Awesome)
- [ ] Layout Elemente müssen überall stimmig sein (Design, Größe, Position, etc.)
- [ ] Logo
- [ ] Header
- [ ] Footer
- [ ] Breadcrumb

### Barrierefreiheit

#### Ausreichende Kontraste
Zwischen Vorder- und Hintergrund sollte ein Mindestkontrast von 3:1 für große Schrift und 4,5:1 für kleine Schrift eingehalten werden. Steuerelemente und informationstragende grafische Elemente müssen sich von angrenzenden Oberflächenkomponenten auch so abgrenzen, dass sie von sehbeeinträchtigten Benutzern gut erkannt und nicht übersehen werden. Der Kontrastabstand zwischen Oberflächenkomponenten muss mindestens 3:1 betragen. Eingabefelder oder Buttons können sich bspw. durch einen zusätzlichen Rahmen deutlich vom Hintergrund abheben.

Zur Überprüfung des Kontrastverhältnisses eignen sich Online-Kontrast-Analyseprogramme oder die Browser-Extension "[WCAG - Contrast checker](https://webaim.org/resources/contrastchecker/)".

#### Tastaturbedienung
* Tastaturnutzer können eine Anwendung nur bedienen, wenn sie erkennen, welches Element den Tastaturfokus hat. Fokussierte Elemente müssen sich deshalb deutlich von nicht fokussierten unterscheiden.
* Interaktive Elemente müssen über die Tastatur oder Tastaturschnittstelle bedient werden können, da nicht alle Benutzer Eingabegeräte (wie die Maus) verwenden können, für die die Hand-Augen-Koordination erforderlich ist. Die Zeit für die Tasteneingabe darf nicht beschränkt sein. Ausgenommen sind hierbei pfadgebundene Eingaben, für z. B. Unterschriften.
* Beispiel von interaktive Elemente: `<button>, <input>, <a>`
* Für Benutzer, die linear durch den Inhalt navigieren, müssen Bedienelemente so gestaltet sein, dass sie in einer aufgabenangemessenen Reihenfolge erreicht werden können. Nur so können die Benutzer ein konsistentes mentales Modell des Inhalts entwickeln und effizient im Inhalt navigieren.
* Der Fokus sollte z.B. bei der Bedienung einer Auswahlliste auch auf dieser verbleiben, sodass diese im geöffneten Modus bedienbar ist.
* Beim Aufruf einer neuen Seite sollte der Fokus am Anfang des Content-Bereiches liegen.
* Die Fokusreihenfolge sollte über die Elemente im Quellcode gesetzet der Lesereihenfolge entsprechen.

#### Weitere Tipps
* Motorisch beeinträchtigte Benutzer bedienen die Anwendung ggf. per Sprachsteuerung. Sie müssen sich darauf verlassen können, dass die sichtbare Beschriftung von Bedienelementen in dem programmatisch ermittelbaren Namen enthalten ist.
* Die Auswahlliste sollte um ein sichtbares und auf Code-Ebene mit dem Element verknüpftes Label besitzen (Da kein sichtbares Label bei der Auswahlliste vorhanden ist, können Nutzer einer Sprachsteuerung das Element nicht direkt ansprechen).
* Alle Nicht-Text-Inhalte, wie Bilder, informationstragende Grafiken und akustische oder sensorische Signale, benötigen eine Textalternative, die die enthaltene Information äquivalent beschreibt. Eine solche Textalternative erlaubt die Aufbereitung der Information durch verschiedene Benutzeragenten und Ausgabearten (z. B. visuell, akustisch oder taktil). Dadurch können Benutzer mit verschiedenen Beeinträchtigungen die Information wahrnehmen.
* Überschriften sollen als h-elemente (h1, h2, h3, h4) vorhanden sein.
* Mehr über barrierefreies Webdesign: https://www.barrierefreies-webdesign.de/